lindi: feature. simple. I personally can live without nand.
lindi: Lars tried to upstream but it was rejected:
> Lars-Peter Clausen <lars@metafoo.de> writes:
>> Not quite. I had for example a 5 liner rejected by a maintainer saying he can't
>> accept any code which adds new platform code to ARM.
lindi: however that appears to have been a misunderstanding and this can be resent

lindi: feature. openmoko specific. simple.
lindi: could this be the next candidate for upstreaming? Is there anything controversial here? has somebody already tried to upstream this?
lindi: there's a lot of extra whitespace changes, probably because the patch has been rebased many times?

lindi: tricky! probably can never be mainlined. Maybe we can build it as a separate module package in debian?
lindi: gcc seems to inline a lot and use a lot of stack here: ioctl.c:2531: warning: the frame size of 1888 bytes is larger than 1024 bytes

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: 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: 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?
Heiko Stübner <heiko@sntech.de>:
As I'm currently also working on a touchscreen driver I came upon a lot of
discussion and documentation about the handling of pressure values.
In the end a driver should not use the pressure property at all if it can't
provide meaningfull pressure data (i.e. more than 0 and 1) and tslib should be
"long fixed", if one does not use an ancient version.

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: 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: sent upstream: http://mailman.alsa-project.org/pipermail/alsa-devel/2011-November/046036.html
lindi: ACCEPTED UPSTREAM: http://mailman.alsa-project.org/pipermail/alsa-devel/2011-November/046059.html