Re: [PATCH v5] MMC-4.5 Power OFF Notify Rework

[Ulf Hansson <ulf.hansson@stericsson.com>]

On 06/15/2012 01:34 PM, Saugata Das wrote:
> On 15 June 2012 16:56, Ulf Hansson<ulf.hansson@stericsson.com>  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.

Please do that as a separate patch so we can get this merged asap. 
Moreover, I think we should try to prevent from adding another cap for this.

There are another option for a host driver tell whether CMD0 shall be 
used or not, by using the regulator supplies. See a patch by Guennadi 
Liakhovetski in: http://article.gmane.org/gmane.linux.kernel.mmc/14635, 
still being discussed though.

The MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, can likely soon be removed 
as well, when above patch is accepted and host driver is starting to use 
the new API.

Kind regards
Ulf Hansson