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

Werner Almesberger werner at openmoko.org
Sun Nov 16 16:54:59 CET 2008


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.

Brrr. Doesn't make sense. I think I'll just map the whole session,
then I'll at least know what's supposed to be going on.

> | Yet the driver manages to hang in much the same way as in 4-bit
> | mode with plenty of SDIO interrupts.
>
> What is the status / source for this spew of interrupts shown in the
> host controller?  Nothing?  Are we sure we have the right interrupt
> number enabled for this subsystem on its probe?

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.

And the registers and the bits in them are correct as well. At least
I believe so after checking them in three different ways :)

> | One oddity: when I ran my performance tests to see how much of a
> | difference single-bit mode made (almost disappointingly, it's only
> | a bit slower, ~645kB/s host to neo, and ~665kB/s neo to host), the
>
> Suspicious!

Yes and no. It's basically the same performance I got with SPI.
I think it just means that we're wasting time elsewhere, and that
SD bus throughput is not the bottleneck. Haven't looked yet whether
the delays come from host or module.

- Werner



More information about the openmoko-kernel mailing list