> On Feb 7, 2017, at 10:24 AM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote:
>
>
>
> On 2017/2/7 15:54, Ulf Hansson wrote:
>> [...]
>>
>>>>
>>>> OK, I see the MMC_CAP_AGGRESSIVE_PM is already checked in the
>>>> mmc_runtime_suspend() function, so your approach, do not send
>>>> Sleep command on Runtime Suspend, is already supported.
>>>> In case the MMC_CAP_AGGRESSIVE_PM is not set, Sleep command
>>>> will not be sent, and the device will be able to perform its
>>>> AUTO_BKOPS (if needed).
>>>>
>>>> However, as far as I see in modern mobile hosts,
>>>> the Sleep is sent on every Suspend, so I assume the
>>>> MMC_CAP_AGGRESSIVE_PM is enabled in most of the cases?
>>>
>>>
>>> Only Intel platforms add this caps on upstreamed kernel tree and
>>> no, AOSP kernel tree didn't change that much either. But I guess
>>> some vendors want aggressive pm policy for their production?
>>>
>>> IMHO, the basic concept of mmc stack is that we could provide
>>> the solutions to support different perf & pm policy for folks but
>>> it's their call to decide it by adding these caps there.
>>>
>>
>> I assume you know the consequences of using MMC_CAP_AGGRESSIVE_PM,
>> still allow me to elaborate a bit on my view.
>>
>> So, MMC_CAP_AGGRESSIVE_PM tells runtime PM suspend of the card to put
>> it into sleep/power off, meaning saving power! However, it also means
>> preventing the eMMC from performing any background operations.
>>
>> The similar applies to the system PM suspend case, no matter if you
>> are using MMC_CAP_AGGRESSIVE_PM or not.
>>
>> To me it seems like we somehow need to start to consider the eMMC'ss
>> BKOPS status in these paths. Depending on the BKOPS state, we may
>> abort the sleep/power off things via returning -EBUSY etc, as
>> otherwise we could end up with poor performing eMMCs, couldn't we!?
>
> Nope, we could. But I just wonder how *aggressive* folks wanted.. Do
> they would rather sacrificing the performace to save more power when
> adding this caps before?
>
> To me, things like this didn't always exist the "best choice", but we
> could find a "better choice". :)
>
I think, by letting the BKOPS to be completed before sending Sleep Command,
we are not cancelling/changing the “aggressive” PM policy.
The Suspend still will be recalled and completed, after getting the right
BKOPS level.
Does the “aggressive” means immediate?
If yes, I think it has to be changed, because some modern eMMC devices need
BKOPS, and the performance impact also need to be considered.
��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
