Hi Chris, On 3 October 2012 23:03, Chris Ball <cjb@xxxxxxxxxx> wrote: > Hi Ulf, > > On Thu, Sep 13 2012, Ulf Hansson wrote: >> From: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >> >> This patch fixup the broken suspend sequence for eMMC >> with sleep support. Additionally it reworks the eMMC4.5 >> Power Off Notification feature so it fits together with >> the existing sleep feature. >> >> The CMD0 based re-initialization of the eMMC at resume >> is re-introduced to maintain compatiblity for devices >> using sleep. >> >> A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the >> Power Off Notification feature. We might be able to >> remove this cap later on, if we think that Power Off >> Notification always is preferred over sleep, even if the >> host is not able to cut the eMMC VCCQ power. >> >> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >> Signed-off-by: Saugata Das <saugata.das@xxxxxxxxxx> >> CC: Girish K S <girish.shivananjappa@xxxxxxxxxx> >> CC: Asutosh Das <asutoshd@xxxxxxxxxxxxxx> > > I gave this patch a try on a board with an eMMC 4.41, but it didn't > resolve the crash that I see. After applying the patch, I still see: > > [ 25.191917] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. > [ 25.319299] mmc1: Got data interrupt 0x00000002 even though no data operation was in progress. > [ 25.335054] PM: Device d4281000.sdhci failed to suspend: error -110 > [ 25.341461] PM: Some devices failed to suspend > > and the suspend aborts. If I modify mmc_card_can_sleep() to always > return false, the suspend completes without errors, so I know that > something in the sleep code is responsible for my crash. This patch restores the sequence for how the sleep sequence is executed, before the poweroff notify patches was merged at all. So in principle I guess the problem for sdhci has been there for quite a while, unless some patch in the sdhci driver has screwed something up recently. > > Any suggestions? Perhaps it's a different bug in the eMMC sleep code. Well, actually there is not so much that can be wrong in the sleep code in the protocol layer. I believe we need to debug the sdhci driver, to see what happens during the suspend operation instead. The sleep code from the protocol layer is requesting sdhci to run a request (sleep cmd and "deselect" cmd). This request is not data requests but cmd requests. Due to the prints from you log it indicates that sdhci believes that there are an ongoing data request to handle. This is not the case, so I think the sdhci has screwed up something. Although, I am not an sdhci expert, so just guessing. :-) Kind regards Ulf Hansson -- 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
