View source for Kernel/Upstreaming
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Kernel/Upstreaming.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Kernel/Upstreaming.
Random notes on SHR kernel patches (v2.6.39.4..shr-2.6.39-nodrm).
lindi: bugfix/feature. sounds sensible. s3c specific
lindi: bugfix. s3c specific
lindi: feature. simple. I personally can live without nand.
lindi: openmoko specific. only for gta01: to have serial console and GSM on the same port.
lindi: feature. tricky! Used by battery hdq queries (temperature, current, capacity etc.) and vibrator. Should just rewrite them in assembler?
lindi: feature. tricky!! This does not include the DRM/3D bits but it is enough for me.
lindi: feature. openmoko specific. simple.
lindi: openmoko specific. nand. simple.
lindi: openmoko specific. cleanup.
lindi: openmoko specific.
lindi: openmoko specific. simple.
lindi: openmoko specific. feature.
lindi: openmoko specific. simple. is this the right API to use? could we abuse rfkill? what do the androids/n900/N9 use?
lindi: openmoko specific. simple.
lindi: openmoko specific. simple.
lindi: openmoko specific. simple.
lindi: openmoko specific. relatively simple, real trouble is in the glamo driver itself
lindi: openmoko specific. LCD control?
lindi: openmoko specific. depends on the tricky fiq support above.
lindi: openmoko specific. depends on the tricky fiq support above.
lindi: openmoko specific. simple.
lindi: trivial. why does AR6003 define this in drivers/net/wireless/ath/ath6kl/hif.h and not this common file?
lindi: tricky! probably can never be mainlined. Maybe we can build it as a separate module package in debian?
From #ath6kl on freenode: <pabs3> kvalo: does ath6kl support AR6001/AR6002? <kvalo> pabs3: no <pabs3> kvalo: do you think it is feasible to add support for them, or are they completely different? <kvalo> pabs3: I haven't even seen either of them so I'm not qualified to answer :) <pabs3> ok
lindi: feature. quite essential. does not look too tricky.
lindi: feature. not sure how easy this is to mainline
lindi: safe cleanup?
lindi: feature. has some useless whitespace changes. gpio stuff which I don't really understand
lindi: just moves a file
lindi: cleanup? No idea how tricky this really is
lindi: has again extra whitespace changes. I guess genirq is some more abstract way to handle IRQs? Can not really judge how tricky this is.
lindi: feature. we can live without this if bq27x00 is mainlined or vice versa.
lindi: trivial
lindi: glamo stuff, no idea
lindi: bugfix. trivial. lindi: it seems this was broken in 2.6.36 and fixed again in 3.0.0 but differently: 26d9be11485ea8c1102c3e8eaa7667412eef4950
lindi: feature. I personally need this a lot so that I can differentiate between RTC and GSM wakeups
lindi: openmoko specific. glamo hack. Who said 2-4-2 timings have no drawbacks? ;-) gena2x: This is not original name for patch! And not true. I do not know why radek maned it with this way, but actually it JUST fixes WSOD with all kind of timings. Please rename it.
lindi: openmoko specific. feature. simple. I personally don't really like this much however this should be easy to upstream.
lindi: openmoko specific feature. looks quite simple.
lindi: atheros wifi hack
lindi: openmoko specific. gta01-only?
lindi: openmoko specific. bugfix. simple. this should be a good candidate for upstreaming first?
lindi: openmoko specific. Is this needed at all with qi? (My guess is no, its resume path does not touch serial ports)
lindi: openmoko specific. feature. hard to say how tricky this is. I can personally live without accelerometers. Paul: upstream has a different driver for the hardware: http://lwn.net/Articles/304326/
lindi: openmoko specific. bugfix to accelerometer support.
lindi: openmoko specific. bugfix to accelerometer support.
lindi: openmoko specific. trivial bugfix to accelerometer support. Why not rebase this to the patch?
lindi: s3c specific. hack? I personally can live with evdev if this really only affects tslib. Paul: hm, worth investigating more: is not returning pressure at all a valid thing to do for a TS driver?
lindi: s3c specific. bugfix? hard to say how ready this is for mainlining.
lindi: openmoko specific. quite essential. hack: read ts during vblank? gena2x: it slows down pixclock to read jitterless data. it does that while blank so screen has no artefacts. may be it is possible to do that while blank without slowing pixclock, even that we have no VSYNC-like interrupt we should be able to calculate exact time of VSYNC because pixclock is constant and we always know current position. But this doesn't solve only major concern of this patch - it introduces link (via callbacks) between glamo and ts.
lindi: bugfix. should be easy to mainline. This basically fixes a bug introduced in 338ee25393a5627e8ded5819147f98b919656ce9 that was mainlined to 2.6.39 lindi: is there some other driver that needs a similar fix? tlv320dac33.c seems to have a similar if (dac33->fifo_mode == ucontrol->value.integer.value[0]) return 0; lindi: why does this return 1? lindi/TODO: rebase on top of dev branch of git://opensource.wolfsonmicro.com/linux-2.6-asoc lindi/TODO: git send-email to http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
lindi: trivial. Occurs with gcc 4.4 but not 4.6 anymore. No need to mainline :-)
lindi: openmoko specific. bugfix. not yet ready. See http://docs.openmoko.org/trac/ticket/2478