[PATCH 0/3] RFC: fix bug http://docs.openmoko.org/trac/ticket/1884
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
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.
More information about the openmoko-kernel