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? > > Kind regards > Uffe ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
