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

Andy Green andy at openmoko.com
Sun Nov 16 19:16:24 CET 2008

Hash: SHA1

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.

- -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