[PATCH] fix-lid302dl-bitbang-all-the-way-baby.patch

[Sean McNeil]

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.