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

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAki1djEACgkQOjLpvpq7dMo1iACfW4n5/Z9OKgNn1mqFZdhK9gLO
dWQAn0C53JmDAPye/VvD+d+rLpPohwZK
=/G3J
-----END PGP SIGNATURE-----