sean at mcneil.com
Wed Aug 27 17:04:23 CEST 2008
Andy Green wrote:
> Somebody in the thread at some point said:
> | Somebody in the thread at some point said:
> | | Somebody in the thread at some point said:
> | |
> | | | I merged this into the stable 2.6.26 git and it breaks battery
> again :(
> | | |
> | | | It also didn't solve my lockup. It took a little longer, but first
> | | | input3 stopped then input2 just as before.
> | | |
> | | | There is something odd with the gpio stuff as battery was broken
> | | | by some old cfgpin calls in the led driver. Perhaps all gpio
> | | | should be made atomic if they are not already.
> | |
> | | You are right about that, it is read-modify-write action. But I can't
> | | see how it trashes HDQ or somehow HDQ pin cfg stuff could trash motion
> | | sensor poll.
> | It is very suspicious that the ersatz chip selects for the motion
> | sensors are on D12 and D13, and HDQ pin is on D14...
> When battery gets broken, what does that look like? What's the first
> indication of trouble?
The HDQ traffic ends up always reporting a timeout error on read (herr = 1).
> I noticed problems with it on 2.6.27 (only) and changed the timer we use
> for FIQ, that seemed to solve it. The HDQ traffic was wrong duration, I
> guessed it was something to do with tickless stuff changing the shared
> prescaler on timer 3 and 4 that we use for FIQ.
I've done some investigation into it and I've seen some odd delays of
the timer interrupt but nothing conclusive. It still seems like the
timer is running. Maybe I can try forcing the prescaler each interrupt?
More information about the openmoko-kernel