[...] >>>> >>>> I have also run some test on my ux500 board and enabling the blkmq >>>> path via the new MMC Kconfig option. My idea was to run some iozone >>>> comparisons between the legacy path and the new blkmq path, but I just >>>> couldn't get to that point because of the following errors. >>>> >>>> I am using a Kingston 4GB SDHC card, which is detected and mounted >>>> nicely. However, when I decide to do some writes to the card I get the >>>> following errors. >>>> >>>> root@ME:/mnt/sdcard dd if=/dev/zero of=testfile bs=8192 count=5000 conv=fsync >>>> [ 463.714294] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 464.722656] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 466.081481] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 467.111236] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 468.669647] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 469.685699] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 471.043334] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 472.052337] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 473.342651] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 474.323760] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 475.544769] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 476.539031] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 477.748474] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> [ 478.724182] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>>> >>>> I haven't yet got the point of investigating this any further, and >>>> unfortunate I have a busy schedule with traveling next week. I will do >>>> my best to look into this as soon as I can. >>>> >>>> Perhaps you have some ideas? >>> >>> The behaviour depends on whether you have MMC_CAP_WAIT_WHILE_BUSY. Try >>> changing that and see if it makes a difference. >> >> Yes, it does! I disabled MMC_CAP_WAIT_WHILE_BUSY (and its >> corresponding code in mmci.c) and the errors goes away. >> >> When I use MMC_CAP_WAIT_WHILE_BUSY I get these problems: >> >> [ 223.820983] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 224.815795] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 226.034881] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 227.112884] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 227.220275] mmc0: Card stuck in wrong state! mmcblk0 mmc_blk_card_stuck >> [ 228.686798] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 229.892150] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 231.031890] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> [ 232.239013] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >> 5000+0 records in >> 5000+0 records out >> root@ME:/mnt/sdcard >> >> I looked at the new blkmq code from patch v10 13/15. It seems like the >> MMC_CAP_WAIT_WHILE_BUSY is used to determine whether the async request >> mechanism should be used or not. Perhaps I didn't looked close enough, >> but maybe you could elaborate on why this seems to be the case!? > > MMC_CAP_WAIT_WHILE_BUSY is necessary because it means that a data transfer > request has finished when the host controller calls mmc_request_done(). i.e. > polling the card is not necessary. Well, that is a rather big change on its own. Earlier we polled with CMD13 to verify that the card has moved back to the transfer state, in case it was a write. And that was no matter of MMC_CAP_WAIT_WHILE_BUSY was set or not. Right!? I am not sure it's a good idea to bypass that validation, it seems fragile to rely only on the busy detection on DAT line for writes. > > Have you tried V9 or V10. There was a fix in V9 related to calling > ->post_req() which could mess up DMA. I have used V10. > > The other thing that could go wrong with DMA is if it cannot accept > ->post_req() being called from mmc_request_done(). I don't think mmci has a problem with that, however why do you want to do this? Wouldn't that defeat some of the benefits with the async request mechanism? Kind regards Uffe -- 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
