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
