Hi Ulf, > -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > Sent: Friday, March 27, 2015 3:57 PM > To: Alex Lemberg > Cc: Avi Shchislowski; linux-mmc; Chris Ball > Subject: Re: [PATCH] mmc: sleep notification > > [...] > > >> > What if Sleep_Notification will take several seconds? > >> > >> Yes, that horrible! You should tell your colleagues designing FTLs to > >> make sure that _never_ happens. > > > > Agree, but we need to consider and take care of all such cases in the driver > side. > > Device might be busy with its internal garbage collection, and as spec > > allows, it will complete it in a great manner after host sends PON command. > > > > 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? 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? > 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. > > So if the SLEEP notification was sent during the "idle operation" and no new > request was needed during the system PM suspend phase we wouldn't have to > wake up the card again using HPI, but instead just leave it "sleeping" and send > CMD5. > > Still, there would be no guarantees that "idle operations" is executed before a > system PM suspend phase starts. So there are no way we can improve the > worst case scenario. > > Kind regards > Uffe ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
