Re: [PATCH] fix-lid302dl-bitbang-all-the-way-baby.patch

[Sean McNeil]

Sean McNeil wrote: Andy Green wrote: Somebody in the thread at some point said: | This large patch removes motion sensor from Linux SPI bitbang driver. | Previously, some access was done through Linux SPI protected | by a mutex, and the ISR access was done by platform bitbang code due | to inability of Linux SPI driver to work in the interrupt context. | | Now all access is done by bitbang callbacks in mach_gta02.c and are | protected by single scheme of interrupt lockout for the duration -- | I line-by-line'd the driver to confirm that best I could, adding | protection and taking more care on several /sys related paths. | | Because this is no longer a Linux SPI bus driver, the path for various | /sys things have changed. They can now be found down, eg, | | /sys/devices/platform/lis302dl.1/sample_rate | | lis302dl.1 is the top sensor and .2 the bottom. The names of the input | susbsytem paths remain the same as before. I tested this for some minutes in two ssh sessions hexdumping the same and both channels, it seems OK. But because of the change in /sys path, ~ it feels better to get some confirmation it improves the situation before putting people though that change on stable, so I stuck it on andy branch right now and would appreciate some testing... it should apply pretty well to 2.6.26 too. -Andy I merged this into the stable 2.6.26 git and it breaks battery again :( It also didn't solve my lockup. It took a little longer, but first input3 stopped then input2 just as before. There is something odd with the gpio stuff as battery was broken first by some old cfgpin calls in the led driver. Perhaps all gpio accesses should be made atomic if they are not already. I'm curious why setting the pin before the cfgpin is done. This seems counter-intuitive. If it was an input and I call set, then configure it as an output wouldn't it just latch to what it was before the config or is there a mux on a separate output register? Responding to myself... It must be multiplexed I guess or there would not be any way to guarantee an immediate level without a toggle when you switch from input to output.