[PATCH 0/3] RFC: fix bug http://docs.openmoko.org/trac/ticket/1884

Andy Green andy at openmoko.com
Sun Nov 16 10:46:50 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Somebody in the thread at some point said:
| | I wrote:
| |> Yup, that's exactly what I have in mind for my scope :-)
| |>
| |> Already the first interrupt should actually give a clue. And the
| |> logic can be reversed as well: trigger on the ISR and see what
| |> happened in its vicinity.
| |
| | Things are getting more interesting: in a single-bit configuration,
| | there's one pulse on DAT1, about 80ms (!) before an interrupt.
| It's pretty much that the interrupts are unrelated to DAT1 action, or is
| the 80ms consistent?  It might be interesting to physically force D1

One more idea, SDIO stack has a interrupt polling option concept.  If
that is falsely enabled it can be part of this business about seeing
"interrupts" with no status (it was just time to poll so it maybe called
the ISR) and the long latencies (you don't even look until it decides to
poll next time).

There's a flag you can set in the host controller definition to say you
need poll... it might be interesting to do a WARN_ON(1) every 100th
interrupt or something and look at the backtrace.

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


More information about the openmoko-kernel mailing list