Hi Wolfram, Thanks for testing. On Tue, Feb 15, 2011 at 06:29:48PM +0100, Wolfram Sang wrote: > On Tue, Feb 15, 2011 at 05:19:17PM +0000, Russell King - ARM Linux wrote: > > On Tue, Feb 15, 2011 at 06:13:41PM +0100, Wolfram Sang wrote: > > > > > > > Ah, yes. I can also see the problem here after turning on > > > > DEBUG_SPINLOCK. > > > > > > Ah, okay. After turning it off, it works a lot better :) > > > > That doesn't mean the problem is fixed. [...] > > Yes, I know that. I should have put the 'works' above in quotes, sorry. > It's caused by spinlock recursion introduced by mxs-dma functions mxs_dma_tx_submit and mxs_dma_tasklet. We have mmc_request_done invoked in the dma callback tasklet. At the meantime, mmc_request_done will issue retries in some case, which will call in mxs_dma_tx_submit. I added the lock by referring to other dma driver implementation, but now I'm considering to remove the lock completely, as I do not see any global data needs to be protected there. Comments? > > > MMC fails for me (note: the card works fine with an mx35-based board) > > > > > > mmc0: new high speed MMC card at address 0001 > > > mmcblk0: mmc0:0001 AF HMP 247 MiB > > > mmcblk0: retrying using single block read > > > mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900 > > > end_request: I/O error, dev mmcblk0, sector 0 > > > > EILSEQ means CRC failure. Probably unrelated. > > Even if it works in another setup? As a result of the above, I can't read the > partition table of that MMC. The mx35 can do so. > First of all, it's not a problem that partition table of the card can not be read. For example, I have every card giving unknown partition table message after performing mmc host driver test on the cards, but they are working good. I guess you will also get the unknown partition table message if you test this card on mx35 right now. I just tested 7 mmc cards in total. 6 cards work fine, and 1 card (Transcend MMC plus 1GB) has the exactly same problem as yours. And if I remove the 8 bit cap, this card also works fine. So I would agree with Russell that it's unrelated to the driver. mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 MMC 3.75 GiB mmcblk1: unknown partition table mmc1: card 0001 removed mmc1: new MMC card at address 0001 mmcblk1: mmc1:0001 SMIMMC 122 MiB mmcblk1: unknown partition table mmc1: card 0001 removed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 NCard 967 MiB mmcblk1: p1 mmc1: card 0001 removed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 MMC512 483 MiB mmcblk1: p1 < p5 > mmc1: card 0001 removed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 000000 980 MiB mmcblk1: unknown partition table mmc1: card 0001 removed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 AF HMP 490 MiB mmcblk1: p1 < p5 > mmc1: card 0001 removed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 MMC 967 MiB mmcblk1: retrying using single block read mmcblk1: error -84 transferring data, sector 0, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 0 mmcblk1: error -84 transferring data, sector 1, nr 7, card status 0x900 end_request: I/O error, dev mmcblk1, sector 1 mmcblk1: error -84 transferring data, sector 2, nr 6, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2 ... > > > SDIO card locks the machine. Is it supposed to work already? > > > > Guess it's the spinlock causing that problem. > > Yeah, that could be. In addition, I was just generally interested if SDIO has > been tested by Shawn. > I tested the SDIO, but probably in different way from yours. I had two card slots on my board, rootfs on mmc0 and SDIO card on mmc1. It seems working fine in this way. However, when I use nfs and test SDIO on mmc0, my systems hangs too. I will look into it. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
