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

Werner Almesberger werner at openmoko.org
Sun Nov 16 20:30:26 CET 2008


Andy Green wrote:
> How did you determine that it is "undriven"?  It's pulled up somewhere,
> right?  What does the rise and fall times look like?

Here's a transition from apparently undriven (~1V) to low:
http://people.openmoko.org/werner/dat1-falling.png

That's as good a picture as I can get with my equipment (100MHz
analog, 400MSa/s if single-channel).

By the way, do you know what rise/fall time is actually allowed ?
Whenever it comes to this kind of interesting detauls, the SDIO
spec only cheerfully proclaims "This section is not included in
the Simplified Specification." :-(

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

In 1-bit mode, DAT1 should act just like any old interrupt line,
according to the (woefully incomplete) SDIO spec.

Right now, the most promising scenario is 1-bit mode and the SDIO
interrupt patch in place. It seems that we then lose a transfer
completion interrupt, i.e., something completely unrelated to the
SDIO interrupt (of which there seem to be none at that point).

Once I've found out what's going on there, then I'll return to
the question of whether there are still anomalies with SDIO
interrupts, or if they were perhaps just caused by some other
problem. Thanks for your suggestions ! Forcing DAT1 low sounds
definitely like something that should yield interesting results.

- Werner



More information about the openmoko-kernel mailing list