Hi Ulf, > -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > Sent: Wednesday, March 11, 2015 4:50 AM > To: Alex Lemberg > Cc: Avi Shchislowski; linux-mmc; Chris Ball > Subject: Re: [PATCH] mmc: sleep notification > > On 10 March 2015 at 15:32, Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx> > wrote: > > Hi Ulf, > > > > Thanks for your review and comments! > > > >> -----Original Message----- > >> From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > >> Sent: Tuesday, March 10, 2015 5:08 AM > >> To: Avi Shchislowski > >> Cc: linux-mmc; Chris Ball; Alex Lemberg > >> Subject: Re: [PATCH] mmc: sleep notification > >> > >> On 10 March 2015 at 10:36, Avi Shchislowski > >> <avi.shchislowski@xxxxxxxxxxx> > >> wrote: > >> > This patch is implements the new additional state of > >> > Power_Off_Notification – SLEEP_NOTIFICATION. > >> > Until now, the implementation of Power_Off_Notification supported > >> > only three modes – POWERED_ON (0x01), POWER_OFF_SHORT (0x02) > and > >> > POWER_OFF_LONG (0x03). > >> > > >> > As part of eMMC5.0 before moving to Sleep state hosts may set the > >> > POWER_OFF_NOTIFICATION byte to SLEEP_NOTIFICATION (0x04). > >> > After setting SLEEP_NOTIFICATION, host should wait for the busy > >> > line to be de-asserted. > >> > The max timeout allowed for busy line de-assertion defined in > >> > SLEEP_NOTIFICATION_TIME byte in EXT_CSD [216]. > >> > HPI may interrupt the SLEEP_NOTIFICATION operation. > >> > In that case POWER_OFF_NOTIFICATION byte will restore to > POWERED_ON. > >> > >> Oh, just great! JEDEC has invented yet another way of how to send a > >> device to sleep state. I wonder what was wrong with the CMD5 option. > > > > I think before adding sleep_notification, host has no way to notify > > device before sending sleep command. Now device can better prepare itself > for moving into the sleep state. > > > > Also, I think we need to clarify one more point for this patch: > > As was mentioned in commit message - Sleep_Notification can be interrupted > by HPI. > > This allows not blocking the host during the Sleep_Notification busy > > time and allows accepting requests coming during this stage. Thus, > > without having HPI supported, suspend/resume process might be > > influenced by Sleep_Notification busy time, and this should not happen - > suspend/resume should be done in very fast and not blocking manner. > > I fail to understand your comment here. > > Please tell me at what point(s) your think it make sense to issue the > SLEEP_NOTIFICATION? If that is during the suspend phase, then a HPI request > can't be triggered. I think SLEEP_NOTIFICATION should be issued on mmc_pm_notify() call, on PM_SUSPEND_PREPARE case. > Kind regards > Uffe ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
