[PATCH 0/3] RFC: fix bug http://docs.openmoko.org/trac/ticket/1884
andy at openmoko.com
Sun Nov 16 19:16:24 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Andy Green wrote:
|> Maybe the problem is that we somehow see
|> the entirely wrong even undriven signal as SDIO interrupt source.
| Hmm, DAT1 is weird indeed. Observing it over a longer interval,
| it's undriven for a while, then goes low, then jumps to high for
| a few hundred ns, and then gets undriven again.
How did you determine that it is "undriven"? It's pulled up somewhere,
right? What does the rise and fall times look like?
Since in 4-bit mode that signal is overloaded for bulk data, it must be
that it only contains the interrupt logical state for some of the time,
it can still be legal that this is still true in 1-bit mode explaining
the behaviour you're seeing. If the transition between levels is slow
at these slots where it is being the interrupt, (hence the interest in
rise and fall time) it could falsely feel it had seen an interrupt request.
What happens if you force it always be the deasserted interrupt level,
by physically overriding it, do we still work or do we break? Do we
still get fake interrupts allegedly from D1?
| The many interrupts case was with the host controller indicating SDIO
| interrupts. The controller shares one interrupt for all events, tx/rx,
| and SDIO interrupt.
So if I understood it, it is really telling you specifically that it
believes the "fake" interrupts are coming from these D1 signalling
actions... if they still come when D1 is forced "off" is pretty interesting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel