On 15 June 2012 16:56, Ulf Hansson <ulf.hansson@xxxxxxxxxxxxxx> wrote:
> Hi Saugata,
>
> snip.
>
>
>>>>>>
>>>>>> The problem in sending CMD0 without power OFF notify is possibility of
>>>>>> some data loss in MMC-4.5 devices.
>>>>>
>>>>>
>>>>>
>>>>> I don't see the problem here. You will be sending power OFF notify when
>>>>> you
>>>>> can. The only difference is when you "wake" the device from sleep mode.
>>>>> Instead of using CMD5, which may work is some cases and in some cases
>>>>> not
>>>>> (without restoring ios). So using CMD0 as common way of waking up from
>>>>> suspend should be fine. Unless I missed something of course. :-)
>>>>>
>>>>
>>>> CMD0 is a reset. I expect with power OFF notify enable, the eMMC
>>>> device will postpone some control information update to its internal
>>>> non-volatile memory (e.g. some data structures which are kept in the
>>>> controller buffers and not stored in NAND). If we do a CMD0, then the
>>>> eMMC device will be reset and we may lose some data. In addition to
>>>> that, doing complete card initialization will increase the wakeup time
>>>> (for 4.4 devices).
>
>
> When doing poweroff_notify at suspend you have _always_ cut both vcc and
> vccq, according to MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which means you
> must always use CMD0 to wake up. There is no present internal cache in the
> eMMC here.
>
> In sleep mode, you can use CMD5, but until the poweroff notify patches (the
> patch that broke suspend/resume, not this one), we have used CMD0 to wake
> up. Let's go back to that solution. Then we can address you concern about
> "data loss" for sleep mode in separate patch.
>
Yes, you will get back to the same code flow with the introduction of
the MMC_CAP2_NO_INIT_ON_RESUME. If some host drivers are capable of
executing the CMD5 resume then they enable this cap and go on the
optimized path. The rest go on CMD0 path.
>
>>>>
>>>> Till now, we have done complete card initialization during resume
>>>
>>> Yes, me and Ulf think we should still do a complete initialization, at
>>> least for now and in this patch.
>>>
>>
>> In my opinion, that's incorrect on MMC-4.5 device and unoptimized for
>> MMC-4.41 device.
>
>
> Unoptimized for 4.41 with sleep, might be correct. But, again, let's look
> into that in a second step.
>
> As stated for 4.5 devices with poweroff_notify, there are no issues.
>
>>
>> Let me propose a new cap, MMC_CAP2_NO_INIT_ON_RESUME and do something
>> like following in mmc_resume,
>>
>> mmc_claim_host(host);
>> - if (mmc_card_is_sleep(host->card)) {
>> + if (mmc_card_is_sleep(host->card)&&
>> + (host->caps2& MMC_CAP2_NO_INIT_ON_RESUME)) {
>> mmc_restore_ios(host,&host->saved_ios);
>>
>> err = mmc_card_awake(host);
>> } else
>> err = mmc_init_card(host, host->ocr, host->card);
>>
>> I hope it's OK for Ulf, Per, Subhash, Girish, Asutosh.
>>
>>
>>> A separate patch may deal with resume awake CMD5 and IOS save/restore.
>>>
>>> We may also discuss a clean up patch later on to reduce the number of
>>> bus_ops. Sleep, awake, and poweroff_notify are MMC specific.
>>> power_save/power_restore maps to suspend/resume. But let's not discuss
>>> this now :)
>>>
>>> BR
>>> Per
>
>
>
> 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
