[PATCH 0/3] RFC: fix bug http://docs.openmoko.org/trac/ticket/1884
werner at openmoko.org
Sun Nov 16 00:46:24 CET 2008
> Yup, that's exactly what I have in mind for my scope :-)
> Already the first interrupt should actually give a clue. And the
> logic can be reversed as well: trigger on the ISR and see what
> happened in its vicinity.
Things are getting more interesting: in a single-bit configuration,
there's one pulse on DAT1, about 80ms (!) before an interrupt.
Yet the driver manages to hang in much the same way as in 4-bit
mode with plenty of SDIO interrupts.
This suggests that there's more than one problem. It may also mean
that single-bit mode will be a better basis for analysis than 4-bit
mode. More importantly, it changes the suspect from the SDIO
interrupt itself to the someone odd enable/disable logic in
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
receiver hung in one test run. That's the first time I ever saw
such a problem.
Wonder if this was just a freak accident ... well, I have a little
torture test set up for tonight that will tell.
More information about the openmoko-kernel