>-----Original Message----- >From: Adrian Hunter [mailto:adrian.hunter@xxxxxxxxx] >Sent: Tuesday, March 10, 2015 3:36 PM >To: Avi Shchislowski; ulf.hansson@xxxxxxxxxx >Cc: linux-mmc@xxxxxxxxxxxxxxx; chris@xxxxxxxxxx; Alex Lemberg >Subject: Re: [PATCH] mmc: sleep notification > >On 10/03/15 11:36, Avi Shchislowski 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. > >Is it so that the point of SLEEP_NOTIFICATION is to notify that VCC will be >powered off after the device is put to sleep by CMD5? The purpose of SLEEP_NOTIFICATION is to give the eMMC enough time to prepare itself before powered off. Before the SLEEP_NOTIFICATION fetcher the eMMC did not know he will get into sleep but only when the sleep was issued With this solution the device start to prepare itself during the sleep preparation > >At the moment, the card does not get put to sleep if there is support for >power-off-notification? No, it will enter to sleep after the device will finish its "internal work" -- 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
