On 4 October 2012 20:46, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> Hi Chris,
>
> On 3 October 2012 23:03, Chris Ball <c...@laptop.org> wrote:
>> Hi Ulf,
>>
>> On Thu, Sep 13 2012, Ulf Hansson wrote:
>>> From: Ulf Hansson <ulf.hans...@linaro.org>
>>>
>>> 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.hans...@linaro.org>
>>> Signed-off-by: Saugata Das <saugata....@linaro.org>
>>> CC: Girish K S <girish.shivananja...@linaro.org>
>>> CC: Asutosh Das <asuto...@codeaurora.org>
>>
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
