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

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| I wrote:
|> 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.

It's pretty much that the interrupts are unrelated to DAT1 action, or is
the 80ms consistent?  It might be interesting to physically force D1
permanently deasserted and see if it still works on a spewing false
interrupt source basis alone.  Maybe the problem is that we somehow see
the entirely wrong even undriven signal as SDIO interrupt source.

What does the shape of D1 interrupt look like rise and fall-time wise.

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

| 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
| Christer's patch.

I dunno about that, if there is a storm then it doesn't matter that a
cleanly deasserted interupt request signal is enabled at the wrong time
does it?  There still should be no storm then.

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

| receiver hung in one test run. That's the first time I ever saw
| such a problem.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkf6R4ACgkQOjLpvpq7dMoevQCbBM3oEN/XXv8OSzTZla/IS6eq
OYoAnipVubYzb1Q1fukAwjPhZgIGHwhF
=dHV5
-----END PGP SIGNATURE-----