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

Sean McNeil sean at
Sun Nov 16 11:08:46 CET 2008

Sean McNeil wrote:
> 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.

Sorry, I just realized the disconnect. When I said loop I didn't mean 
just loop checking the IRQ line. I meant while the IRQ line is low(?), 
then read a sample. Looping until the line toggles and reading samples 
the whole time.

I wasn't clear on that.
> 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
>> -----END PGP SIGNATURE-----

More information about the openmoko-kernel mailing list