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. Thanks, Alex ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
