Am Di 26. August 2008 schrieb Andy Green: > Somebody in the thread at some point said: > | It seems like the accelerometers have the following: > | > | sensitive to losing an edge trigger > > We just suspect it, nobody showed it yet... it would probably be a bug > in the driver handling or s3c stuff rather than accelerometer "feature". > > | occur at a periodic rate > | access conflicts with other drivers so should be done outside of irq > > I have a nice patch coming that just does it bitbang the whole way using > IRQs off as locking throughout. > > | Does it make sense to just turn off the irq and have the driver use a > | delayed work queue to poll at a given rate? > > Interrupts are at least somewhat synchronized to the source, I think it > will suffer from dropped samples otherwise. But, at some point we have > to take more radical measures if we don't solve it...
Like general switch from edge-triggered IRQ to level-triggered. Edge-triggered IRQs are *NOT* suitable for physical sharing of IRQ-line, ok we don't do this. Edge is more sensible to spikes and glitches, ok we don't see (really?). But I expect IRQs to be locked/disabled during execution of a IRQ-handler (usually that's even implicit in CPU's handling of IRQs), so only level-IRQ will be noticed after we exit handler. I consider usage of edge-trigger a major flaw in Openmoko-design at large. Edge is used only where you can't reset the interrupt-source - like pushbuttons etc. I.E. async. For "sync" interrupts level is method of choice. /jOERG
signature.asc
Description: This is a digitally signed message part.
