On 30 September 2015 at 18:10, Mirza Krak <mirza.krak@xxxxxxxxxxxxxxxx> wrote: > Hi again. > > Thank you for your response Ulf. > > I am going to start over though since I did not get everything right > the first time. > > As stated I am running the 4.1.5 Linux kernel and what I am actually > using is a SD card. The host driver is sdhci-esdhc-imx.c. > > And my initial issue was that on resume I get the following: > [ 31.848397] mmc0: card never left busy state > [ 31.848412] mmc0: error -110 during resume (card was removed?) Normally this should indicate that the card actually has been physically removed from the slot. As of course you wouldn't be able to re-initiate a non-existing card. :-) In your case it indicates that something else is wrong. > [ 31.848550] PM: resume of devices complete after 2062.936 msecs > [ 31.931086] PM: Finishing wakeup. > [ 31.931102] Restarting tasks ... done. > [ 31.954336] mmc0: card dade removed > [ 32.358711] mmc0: host does not support reading read-only switch, > assuming write-enable > [ 32.391857] mmc0: new SD card at address aaaa > [ 32.418228] mmcblk0: mmc0:aaaa SU02G 1.84 GiB > [ 32.446402] mmcblk0: p1 > [ 32.835907] EXT4-fs (mmcblk0p1): recovery complete > [ 32.840873] EXT4-fs (mmcblk0p1): mounted filesystem with ordered > data mode. Opts: (null) > > And that was the reason of my initial questions on what is supposed to > happen when suspending. > > The card IS actually "removed" when in suspended state since we cut > the power-rail completely to the SD card. Actually its struct device is not being "removed", until a new mmc_detect work is scheduled, which is when a resume has been completed. mmc_pm_notify() (PM_POST_SUSPEND). That detect work will find that the card isn't responding to commands, power cycle it and re-try an new initialization of it. Apparently that makes the card work again. > > I assume that this is a sdhci-esdhc-imx issue, but then I wonder what > would be a proper fix for this. sdhci and/or sdhci-esdhc-imx issue. > > As stated before I get around this problem by adding a HACK to force > removal of the SD card before suspending in mmc_pm_notify. > > Sorry if I am spamming but I am trying to learn :). > So, to give you some advise on where to start. 1. I would make sure that "suspending" the card by itself, without actually suspending the entire system works okay. You can for example do that by enabling MMC_CAP_AGGRESSIVE_PM, since that should then suspend the card at request inactivity point. Add some debug prints to make sure _mmc_sd_suspend()/_mmc_sd_resume() actually gets called. 2. If 1) work, it's probably an issue in sdhci/sdhci-esdhc-imx suspend/resume callbacks. Perhaps you might want to invoke these callbacks manually as those should also work separately. Good luck! 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
