Kernel/Upstreaming
From Openmoko
(Difference between revisions)
(→wm8753: allow setting DAI mode even while pcm is active) |
(→wm8753: allow setting DAI mode even while pcm is active) |
||
Line 120: | Line 120: | ||
lindi: why does this return 1? | lindi: why does this return 1? | ||
lindi: this seems to be called from snd_ctl_elem_write. If we return 1 then it calls snd_ctl_notify, what does this mean? | lindi: this seems to be called from snd_ctl_elem_write. If we return 1 then it calls snd_ctl_notify, what does this mean? | ||
+ | lindi-_> gena2x_ptr: "return 1" is a bug in that patch, it needs to be "return 0" | ||
+ | lindi-_> gena2x_ptr: easy to see | ||
+ | lindi-_> gena2x_ptr: strace alsamixer | ||
+ | lindi-_> gena2x_ptr: then while true; do alsactl restore -f somestate; done | ||
+ | lindi-_> gena2x_ptr: alsamixer gets spammed by bogus DAI change events | ||
+ | lindi-_> gena2x_ptr: no other alsa control sends notifications ion this test | ||
lindi/TODO: rebase on top of dev branch of git://opensource.wolfsonmicro.com/linux-2.6-asoc | 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/TODO: git send-email to http://mailman.alsa-project.org/mailman/listinfo/alsa-devel |
Revision as of 18:40, 16 November 2011
Random notes on SHR kernel patches (v2.6.39.4..shr-2.6.39-nodrm).
ARM: s3c24xx: Set ARCH_NR_GPIOS according to the selected SoC types.
lindi: bugfix/feature. sounds sensible. s3c specific
s3c24xx: Fix level irqs on external interrupts.
lindi: bugfix. s3c specific
mtd: s3c2410_nand: Add config option to disable hw ecc at runtime
lindi: feature. simple. I personally can live without nand.
Add s3c24xx_serial_console_set_silence
lindi: openmoko specific. only for gta01: to have serial console and GSM on the same port.
Add c fiq handler.
lindi: feature. tricky! Used by battery hdq queries (temperature, current, capacity etc.) and vibrator. Should just rewrite them in assembler?
Add glamo driver.
lindi: feature. tricky!! This does not include the DRM/3D bits but it is enough for me.
ARM: gta02: Add LED support
lindi: feature. openmoko specific. simple.
gta02: Disable hardware ECC unless we get instructed to enable it
lindi: openmoko specific. nand. simple.
gta02: Remove usage of pcf50633 gpio api
lindi: openmoko specific. cleanup.
s3c2440: gta02: Configure pcf50633 gpios.
lindi: openmoko specific.
ARM: s3c2440: GTA02: Select SPARSE_IRQ
lindi: openmoko specific. simple.
gta02: Add notify handler to probe device children
lindi: openmoko specific. feature.
gta02: Add bt power management device
lindi: openmoko specific. simple. is this the right API to use? could we abuse rfkill? what do the androids/n900/N9 use?
gta02: Add gps power management device
lindi: openmoko specific. simple.
gta02: Add gsm power management device
lindi: openmoko specific. simple.
gta02: Add wlan power management device
lindi: openmoko specific. simple.
gta02: Add glamo device
lindi: openmoko specific. relatively simple, real trouble is in the glamo driver itself
Add jbt device.
lindi: openmoko specific. LCD control?
gta02: Add fiq handler
lindi: openmoko specific. depends on the tricky fiq support above.
gta02: Add battery driver
lindi: openmoko specific. depends on the tricky fiq support above.
gta02: add support for platform_battery
lindi: openmoko specific. simple.
Add atheros sdio ids.
lindi: trivial. why does AR6003 define this in drivers/net/wireless/ath/ath6kl/hif.h and not this common file?
Add ar6000 wireless driver.
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
Add jbt6k74 display driver.
lindi: feature. quite essential. does not look too tricky.
LEDS: leds-pwm: Add init, notfiy and exit callbacks
lindi: feature. not sure how easy this is to mainline
RTC: PCF50633: Don't request update IRQ
lindi: safe cleanup?
pcf50633-gpio: Add gpiolib support.
lindi: feature. has some useless whitespace changes. gpio stuff which I don't really understand
pcf50633: Move pcf50633-gpio driver to the gpio drivers folder
lindi: just moves a file
MFD: pcf50633: Use mfd cells to register
child devices MFD: pcf50633: Use mfd cells to register
child devices
lindi: cleanup? No idea how tricky this really is
MFD: pcf50633: Use the genirq for irq handling
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.
power: implement platform battery driver
lindi: feature. we can live without this if bq27x00 is mainlined or vice versa.
Define machine_is_neo1973_gta01()
lindi: trivial
glamo-mci: revert changes for Per's patchset
lindi: glamo stuff, no idea
nand/s3c2410: add mising badblocksbits value
lindi: bugfix. trivial. lindi: it seems this was broken in 2.6.36 and fixed again in 3.0.0 but differently: 26d9be11485ea8c1102c3e8eaa7667412eef4950
Openmoko resume reason sysfs node ported from 2.6.29
lindi: feature. I personally need this a lot so that I can differentiate between RTC and GSM wakeups
glamo-display: fix WSOD for 242 timming
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.
Enable powering off after 8s POWER press
lindi: openmoko specific. feature. simple. I personally don't really like this much however this should be easy to upstream.
gta02: add support for usb host mode
lindi: openmoko specific feature. looks quite simple.
ar6000_delay.patch
lindi: atheros wifi hack
wm8753: use snd_soc_jack on neo1973
lindi: openmoko specific. gta01-only?
Fix high power consumption in suspend
lindi: openmoko specific. bugfix. simple. this should be a good candidate for upstreaming first?
Force GPS power up on resume if it were powered up on suspend
lindi: openmoko specific. Is this needed at all with qi? (My guess is no, its resume path does not touch serial ports)
lis302dl accelerometer driver
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/
input: lis302dl: fix the resume path
lindi: openmoko specific. bugfix to accelerometer support.
lis302dl: use ABS events rather then REL events
lindi: openmoko specific. bugfix to accelerometer support.
Fix compile error for gta02 accelerometer.
lindi: openmoko specific. trivial bugfix to accelerometer support. Why not rebase this to the patch?
tslib relies on ts pressures events so this hack is needed to get tslib stuff working
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?
touchscreen: ignore unexpected interrupts
lindi: s3c specific. bugfix? hard to say how ready this is for mainlining.
s3c2410_ts: jitter less touchscreen for glamo, version 4
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.
wm8753: allow setting DAI mode even while pcm is active
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: this seems to be called from snd_ctl_elem_write. If we return 1 then it calls snd_ctl_notify, what does this mean? lindi-_> gena2x_ptr: "return 1" is a bug in that patch, it needs to be "return 0" lindi-_> gena2x_ptr: easy to see lindi-_> gena2x_ptr: strace alsamixer lindi-_> gena2x_ptr: then while true; do alsactl restore -f somestate; done lindi-_> gena2x_ptr: alsamixer gets spammed by bogus DAI change events lindi-_> gena2x_ptr: no other alsa control sends notifications ion this test 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
Workaround toolchain bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
lindi: trivial. Occurs with gcc 4.4 but not 4.6 anymore. No need to mainline :-)
First attempt at fixing openmoko bug #2478
lindi: openmoko specific. bugfix. not yet ready. See http://docs.openmoko.org/trac/ticket/2478