On 1/25/17, 2:45 PM, "linux-mmc-owner@xxxxxxxxxxxxxxx on behalf of Adrian Hunter" <linux-mmc-owner@xxxxxxxxxxxxxxx on behalf of adrian.hunter@xxxxxxxxx> wrote:
> > 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?
POWER_OFF_SHORT should be completed within GENERIC_CMD6_TIME,
which is a standard Switch command time.
>
> 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.
>
>
>
--
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
��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
