[...] >> 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. > >> 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. 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
