[PATCH] gta02-accel-isr-fix-more.patch

[Sean McNeil]

Andy Green wrote:
> Somebody in the thread at some point said:
> | Andy Green wrote:
> |> Somebody in the thread at some point said:
> |> | Even better, but I still can get lockups. It might have something
> to do
> |> | with writing to
> |> |
> |> |     /sys/devices/platform/spi_s3c24xx_gpio.1/spi0.0/full_scale -> 9.2
> |> |     /sys/devices/platform/spi_s3c24xx_gpio.1/spi0.1/full_scale -> 9.2
> |> |
> |> | while the device is already open.
> |>
> |> Guh... yes they are protecting against themselves but not against the
> |> interrupt traffic which is bitbanged in the ISR.  Linux SPI won't work
> |> with interrupts off either IIRC.  So it needs bitbang all the way,
> baby.
> |
> | Plus it looks like both are hanging off the same spi? The comment in
> | close is incorrect then as access is only serialized for a particular
> | input, not both. So, open(1), open(2), close(2) will cause (1) to stop
> | working.
>
> I don't see that... everything in there is contextualized through lis
> pointer.  So we don't quench both devices as you suggest if we see a
> close() through input layer for one device.  We just tell *that* device
> to stop making the interrupts and the other guy (on different lis
> context) continues doing his thing.


Well this is really quite bazaar. I haven't tracked down what is
interfering with them, but at some point 1 and then the other stops
producing. I have verified that it isn't getting closed, so I'm inclined
to believe it is another device that causes the problem. audio?
touchscreen? fiq?