Re: [PATCH 3/3] mmc: Checking BKOPS status prior to Suspend

[Adrian Hunter <adrian.hunter@intel.com>]

On 25/01/17 14:40, Alex Lemberg wrote:
> 
> 
> On 1/25/17, 12:30 PM, "Adrian Hunter" <adrian.hunter@intel.com> wrote:
> 
>     On 25/01/17 11:48, Alex Lemberg wrote:
>     > 
>     > 
>     > On 1/24/17, 4:36 PM, "Adrian Hunter" <adrian.hunter@intel.com> wrote:
>     > 
>     >     On 23/01/17 19:07, Alex Lemberg wrote:
>     >     > Hi Adrian,
>     >     > 
>     >     > I would like to add several notes on top of Uri’s answer...
>     >     > I agree with you, by the spec, PON Sleep_Notification should be
>     >     > set before calling Sleep command.
>     >     > As you probably remember, we have tried to implement it
>     >     > in the past and even submitted a patch – “[PATCH] mmc: sleep notification”
>     >     > https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg30906.html
>     >     > As you can see from the thread, one of the main issues in Sleep_Notification
>     >     > is a SLEEP_NOTIFICATION_TIME (defined in EXT_CSD [216]), which need to be
>     >     > considered in implementation…
>     >     
>     >     Does it?  I would tend to assume SLEEP_NOTIFICATION_TIME will be acceptable
>     >     during _suspend until proven otherwise.
>     > 
>     > Potentially, by the spec, the Max value of SLEEP_NOTIFICATION_TIME can be 83.88 seconds.
>     > Can we assume that this time is acceptable during _suspend?
>     
>     Do you know of any cards that take that long?
> 
> Yes - for some cards it can take several seconds in some corner cases.

Wouldn't that mean POWER_OFF_SHORT has the same problem since that is
preparing for *both* Vcc and Vccq to go off?

> 
>     As I wrote, I would assume it is acceptable until we know otherwise.
> 
> I think Sleep_Notification requires more detailed review. 
> Since PON Sleep_Notification is a blocking command (BUSY asserted),
> in case of getting new request, driver need to send HPI command in order
> to interrupt the Sleep_Notification process.
> We tried to handle this case in our Sleep_Notification patchset…
> Anyway, I think we need to discuss it separately, not related to
> the AUTO_BKOPS support…
> 
>     >     
>     >     > Thus, I think postponing Sleep during suspend requires a different from current
>     >     > AUTO_BKOPS implementation, and I suggest to handle it in separate
>     >     > patchset, if possible.
>     >     
>     >     Not at all sure what you mean by "postponing Sleep"?
>     > 
>     > I mean letting Sleep_Notification to be completed before Sleep.
>     
>     ook.
>     
>     
>