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?
