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

Sean McNeil sean at mcneil.com
Wed Aug 27 03:02:32 CEST 2008

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?

More information about the openmoko-kernel mailing list