Re: [PATCH] mmc: sleep notification

Ulf Hansson
2015-04-08T09:49:08Z

On 6 April 2015 at 15:44, Alex Lemberg <Alex.Lemberg@sandisk.com> wrote:
> Hi Ulf,
>
>> -----Original Message-----
>> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
>> Sent: Wednesday, April 01, 2015 2:46 PM
>> To: Alex Lemberg
>> Cc: Avi Shchislowski; linux-mmc; Chris Ball
>> Subject: Re: [PATCH] mmc: sleep notification
>>
>> [...]
>>
>> >> Okay, so to me, I think the SLEEP notification needs to be sent as a
>> >> part of the system PM suspend phase. And more exactly from the
>> >> bus_ops->suspend() callback.
>> >>
>> >
>> > PM suspend phase is a right place for PON Sleep_Notification, but it
>> > also the critical one and need to be completed as fast as possible.
>> >
>> > If I'm not mistaken, during the PM Suspend, the user space is freezing.
>> > Is it OK to let PON Sleep_Notification to be called at that stage?
>>
>> Of course we shall strive in minimizing the system PM suspend time.
>> Though to me, I think the system PM _resume_ time is of more importance.
>>
>> In this case we don't have any option. We need to issue the sleep notification as
>> part of the the system PM suspend phase and that will unfortunate and likely
>> increase the total system PM suspend time.
>>
>> >
>> > Calling from the notifier_call (mmc_pm_notify()) will allow to
>> > complete Sleep_Notification process before entering to the critical part - the
>> Suspend.
>> > Isn't it?
>>
>> Why is mmc_pm_notify() a less critical part?
>>
>> More importantly as stated several times, we can still get I/O requests after
>> the mmc_pm_notify() phase and then the sleep notification needs to be
>> interrupted and re-issued anyway.
>
> You are right - the sleep_notification might be re-issued several times,
> but in case of mmc_pm_notify() the user space is not frozen yet, and
> system will not stuck until sleep_notification completion, like in case of
> PM suspend.
>
>>
>> >
>> >> In addition to that, we should be able improve the situation by also
>> >> sending the SLEEP notification as part of an "idle operation". With
>> >> "idle operation" I mean the mmc block layer hasn’t received any new
>> >> request for a while (the framework for this is already implemented by using
>> runtime PM).
>> >
>> > OK, sounds like a good approach.
>> > In case runtime PM is supported, we can call PON Sleep_Notification
>> > from
>> > mmc_runtime_suspend() during the "idle operation", and then call it
>> > again during PM Suspend.
>>
>> Yes.
>>
>> If you plan to send a new version of $subject patch, please split into at least two
>> patches. One which adds the system PM part and one which adds the "idle
>> operation" part.
>
> As far as I see, the same _mmc_suspend() function is used in both cases -
> PM Suspend and "idle operation".
> The _mmc_suspend() is called from both - mmc_suspend() and
> mmc_runtime_suspend().
> In case we decide to go with PM Suspend and "idle operation",
> should we just add the sleep_notification support to _mmc_suspend() for
> covering both cases?

That works as a start.

Though, it would mean MMC_CAP_AGGRESSIVE_PM is needed to enable "idle
operations" for this case. It might be good enough. If not, we need to
send the sleep notification from mmc_runtime_suspend() as well.

Kind regards
Uffe