On Tue, 15 Apr 2008 15:26:54 -0400
"hartleys" <[EMAIL PROTECTED]> wrote:
> I do get the IRQ on every card insertion and removal. Actually if I boot
> the system with the card removed I end up getting a:
>
> mmc0: error -22 whilst initialising SDIO card
This is a bit odd. It shouldn't have gone down that route unless it is
sure it's an SDIO card it is dealing with.
> If I then insert the card I get the IRQ and:
>
> mmc0: new MMC card on SPI
> mmcblk0: mmc0:0001 SDM064 62720KiB
> mmcblk0: p1 p2 p3 p4
>
> So it appears the initial card detect does work. But for some reason
> it's not seeing the removal of the card or the insertion of a new card.
>
> Any ideas?
Without debugging info it's impossible to tell if it's the driver or the core
that's doing something wrong. Have you checked that interrupts keep coming?
>
> New issue. All of my testing so far has been with MMC cards. All of them
> have worked so far. I just tried a couple of SD cards and none of them
> work with the driver, they do work fine on my host system.
>
> One of the cards actually produces a "Division by zero in kernel." error.
> It appears to happen in the mmc_set_data_timeout() function. I added a
> printk to the function and get the following when the card is inserted.
>
> mmc_set_data_timeout timeout_ns:0 timeout_clks:0 ios.clock:400000
> mmc_set_data_timeout timeout_ns:-589934592 timeout_clks:0 ios.clock:400000
> mmc0: new SD card on SPI
> mmcblk0: mmc0:0000 29888KiB
> mmcblk0:mmc_set_data_timeout timeout_ns:-589934592 timeout_clks:0
> ios.clock:0
> Division by zero in kernel.
Ouch.
>
> For some reason the card->host->ios.clock value is getting changed to 0 on
> the third call to the function. I haven't been able to trace down where/why
> this would happen. Any idea on that one?
>
Not the slightest. It should never be set to zero except when powering
down, which it only does when there is no card attached.
> I didn't think of checking dmesg before, here's the actual dump after I
> insert
> the SD card:
My guess would be transfer problems that causes the core to believe the
card cannot handle a higher speed. We should of course have a check
that we don't compute a too low speed, but that's not the root of the
problem.
Have you disabled the CRC checks?
I guess I'll have to warm up my old SPI test board and get it updated.
David, I don't suppose you've checked if you can reproduce this?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
