sean at mcneil.com
Sat Aug 23 21:52:18 CEST 2008
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,
> | 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?
More information about the openmoko-kernel