Andy Green wrote: > Somebody in the thread at some point said: > | 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 > |> first > |> | | | by some old cfgpin calls in the led driver. Perhaps all gpio > |> accesses > |> | | | 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? > > What I did was change the timer used in the resource for fiq on 2.6.27 > and it seemed to be OK then. We don't use the PWM for LEDs due to > having had other trouble with it so the timers are spare right now. > > I put the HDQ traffic on a scope and when it failed, the traffic was > wildly bloated out, several times as long as it should be, and the > protocol is sensitive to absolute bit-time. > > I dunno why it should suddenly start making trouble in 2.6.26+, I > randomly assumed it was tickless but Andrzej reckons not. I stared at > the GPIO code for a while earlier and I couldn't make any sense about it > making trouble in FIQ no matter what the foreground code was doing > with it.
I'm inclined to believe there is something messing up the timer. That would make a lot of sense. The vibrator, however, appears to be properly duty-cycled.
