On 6 April 2015 at 15:44, Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx> wrote: > Hi Ulf, > >> -----Original Message----- >> From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] >> 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 -- 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
