Hi Ulf,
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> 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.lemb...@sandisk.com>
> wrote:
> > Hi Ulf,
> >
> > Thanks for your review and comments!
> >
> >> -----Original Message-----
> >> From: Ulf Hansson [mailto:ulf.hans...@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.shchislow...@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.
>
> 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�����r��y����b�X��ǧv�^�){.n�+����{��g"��^n�r���z���h�����&�� �G���h�(�階�ݢj"���m������z�ޖ���f���h���~�m�
