PATCH/RFC [0/3]: Fix suspend and other acceleromter issues
Sean McNeil
sean at mcneil.com
Sun Nov 16 11:08:46 CET 2008
Sean McNeil wrote:
> Andy Green wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Somebody in the thread at some point said:
>> | On Sun, 16 Nov 2008 16:22:46 +0700
>> | Sean McNeil <sean at mcneil.com> 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
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkkf6rYACgkQOjLpvpq7dMrP8wCdE5crzoLXD7B/pGGcmb5S1sGk
>> JbwAoIOZ4hInn4rQKgw2u+0LV/HAkYlg
>> =mn/Y
>> -----END PGP SIGNATURE-----
>
>
More information about the openmoko-kernel
mailing list