RE: [PATCH] mmc: sleep notification

Alex Lemberg
2015-03-10T14:48:00Z

Hi Ulf,

Thanks for your review and comments!

> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> 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@sandisk.com>
> 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