On 4 October 2012 20:46, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > 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. (Just a guess) for non-dt case just check in the machine fiile whether the correct platform device is passed. i mean for mmc0 channel devic0 and for mmc1 channel its device1. In my case i had duplicated device0 for both channels and had seen such log. >> [ 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
