Re: SDIO driver not receiving responses
Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 Farbod Nejati <[EMAIL PROTECTED]> wrote: > The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is > returning with a -110 (a timeout error). I traced this deeper and > noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I > verified this using a logic analyser, the host *is* transmitting a CMD5 > [IO_SEND_OP_COND] packet in the correct format). However, when the > client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does > not seem to be received by the host. Again, I verified using the logic > analyser that the response is as would be expected. An IRQ *is* > triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). > I'm not too familiar with Linux kernel programming but I suspect that > whatever is waiting for a valid response is giving up instead and > triggering the above-mentioned interrupt instead. That would be the hardware. We don't do any software timeout handling. Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec. > > Why would the output of the above code differ from the one produced by > lspci -xxx. Could this have something to do with this issue??? > lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;) > > I'm fresh out of ideas on this one and would greatly appreciate some > hints or assistance. I'm happy to provide any further information if needed. > I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SDIO driver not receiving responses
Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 Farbod Nejati [EMAIL PROTECTED] wrote: The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is returning with a -110 (a timeout error). I traced this deeper and noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I verified this using a logic analyser, the host *is* transmitting a CMD5 [IO_SEND_OP_COND] packet in the correct format). However, when the client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does not seem to be received by the host. Again, I verified using the logic analyser that the response is as would be expected. An IRQ *is* triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). I'm not too familiar with Linux kernel programming but I suspect that whatever is waiting for a valid response is giving up instead and triggering the above-mentioned interrupt instead. That would be the hardware. We don't do any software timeout handling. Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec. Why would the output of the above code differ from the one produced by lspci -xxx. Could this have something to do with this issue??? lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;) I'm fresh out of ideas on this one and would greatly appreciate some hints or assistance. I'm happy to provide any further information if needed. I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SDIO driver not receiving responses
Hi Pierre,
I'm having problems with the latest mmc_core.ko and sdhci.ko for 2.6.24.
I've used both my development SDIO client and an off-the-shelf SDIO WIFI
card. I have a Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter
(rev 21).
The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is
returning with a -110 (a timeout error). I traced this deeper and
noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I
verified this using a logic analyser, the host *is* transmitting a CMD5
[IO_SEND_OP_COND] packet in the correct format). However, when the
client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does
not seem to be received by the host. Again, I verified using the logic
analyser that the response is as would be expected. An IRQ *is*
triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR).
I'm not too familiar with Linux kernel programming but I suspect that
whatever is waiting for a valid response is giving up instead and
triggering the above-mentioned interrupt instead.
# lspci -v -s 15:00.2 -xxx
15:00.2 Generic system peripheral [0805]: Ricoh Co Ltd R5C822
SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
Subsystem: Lenovo Unknown device 20c8
Flags: medium devsel, IRQ 23
Memory at f8101800 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
00: 80 11 22 08 02 00 10 02 21 00 05 08 00 40 80 00
10: 00 18 10 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 c8 20
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 03 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 fe 00 40 00 48 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 c8 20
b0: 04 00 02 00 00 00 00 00 00 00 00 00 a0 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: a1 21 e0 01 00 00 00 00 40 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 d0 00 20 02 00 00 00 00
*** An interesting thing is, when I try to printk() values in the above
table through the driver, I don't get identical values. I do this using
the following code:
for (i = 0; i < 16; i++)
{
for (k = 0; k < 16; k++)
{
printk("%02x ", readb(host->ioaddr + (i*16) + k));
}
printk("\n");
}
Why would the output of the above code differ from the one produced by
lspci -xxx. Could this have something to do with this issue???
host->ioaddr is set to 0xF8A84800 (which is the output of
ioremap_nocache(0xF8101800, 256)
Sections of /var/log/messages:
sdhci: SDHCI controller found at :15:00.2 [1180:0822] (rev 21)
sdhci [sdhci_probe()]: found 1 slot(s)
ACPI: PCI Interrupt :15:00.2[C] -> GSI 18 (level, low) -> IRQ 22
sdhci [sdhci_probe_slot()]: slot 0 at 0xf8101800, irq 22
I'm fresh out of ideas on this one and would greatly appreciate some
hints or assistance. I'm happy to provide any further information if needed.
Regards
Farbod Nejati
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
