RE: [PATCH] mmc: sleep notification

Alex Lemberg
2015-04-06T13:44:30Z

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?

>
> Kind regards
> Uffe