PATCH/RFC [0/3]: Fix suspend and other acceleromter issues

Sean McNeil sean at
Sun Nov 16 10:52:10 CET 2008

Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> | On Sun, 16 Nov 2008 16:22:46 +0700
> | Sean McNeil <sean at> wrote:
> |
> |>> But if that's true and this window exists I can't see how we could
> |>> reduce the window to actually zero length by looping in the ISR,
> |>> whatever opens and closes that window (eg, "being in an ISR") is
> |>> not an atomic action.  The new sample interrupt can still happen
> |>> just after the last time we poll for it and get a negative response.
> |> But thats OK because if we loop until the line toggles then we will
> |> get another edge interrupt. The problem is that we aren't really
> |> clearing out the cause of the interrupt in the ISR.
> We have to loop for up to 10ms then in the ISR is what you mean?  Then
> we are really resynchronizing the ISR sample action to the source in an
> expensive way.

There is no magic number as far as I know. Most of the time, the cause 
is cleared out by reading the one sample. That is why we see data for a 
while before it suddenly hangs. What I'm saying is that reading the 
sample doesn't guarantee that you will clear the cause and toggle the 
interrupt line. If there is sufficient delay before the ISR runs, then 
reading the sample isn't good enough because there was another one ready 
immediately and the IRQ didn't toggle.

> | Well, stable-tracking uses your level-triggered interrupts anyway so I
> | don't think this should be a problem anymore (however the chip actually
> | work) :-)
> |
> | One difference I saw compared to the edge-triggered ones was that with
> | a very small threshold, interrupts get generated at a very high rate
> | which causes considerable slow-down (almost to a halt). With data-ready
> | interrupts it's not so. I therefore raised the lowest threshold to
> | avoid this particular problem - the lowest are not very useful anyway
> | since the device continuously generates data even being stationary on a
> | table.
> Hum this sounds rather like the other problems we have seen when we try
> to use level interrupts on 2442, somehow they are not acked properly and
> we re-enter the service routine shortly after we exit it.  It doesn't
> kill operation but makes it run very badly.  Maybe it's to do with this
> not really understood lower level configuration of the handler as being
> edge instead of level, Matt has seen the same when he tries to use level
> on pcf50633 as he tries to work around in his recent patches at resume 
> time.

Yes, that is what happens here now when too slow. We just get another 
interrupt immediately when level triggered.

> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkkf6rYACgkQOjLpvpq7dMrP8wCdE5crzoLXD7B/pGGcmb5S1sGk
> JbwAoIOZ4hInn4rQKgw2u+0LV/HAkYlg
> =mn/Y

More information about the openmoko-kernel mailing list