Hi Ulf, > -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > Sent: Monday, June 15, 2015 11:24 AM > To: Alex Lemberg > Cc: Avi Shchislowski; linux-mmc > Subject: Re: [RFC PATCH v3] mmc: sleep notification > > On 8 June 2015 at 15:17, Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx> > wrote: > > Hi Ulf, > > > > [...] > > > >> > >> One of my comments for v2, was that I think you should remove all > >> code which was related to HPI to interrupt sleep notification from > >> the runtime PM resume path. Instead I wanted you to add that > >> functionality as separate patch based on top of this patch. > >> > >> You haven't done that in v3, why? > > > > The sleep_notify call was moved to suspend() per your recommendation. > > As far as I understand, no new requests should be sent during > > mmc_suspend() process, thus HPI support is not needed anymore. > > Is this the correct assumption? > > Yes. > > I don't think you need mmc_card_set_sleep_notify() and the corresponding > new MMC_STATE_SLEEP_NOTIFY , mmc_device_prg_state(), etc. mmc_card_set_sleep_notify(), MMC_STATE_SLEEP_NOTIFY and the corresponding - We are removing it from the current patch. Probably will add them as a separate patch in future. mmc_device_prg_state() - is required for waiting for Sleep_Notification completion/timeout, although we would like to leave this function. > > Overall, I think this patch could be simplified yet another step. > > > The only case where HPI is used in this patch - is during sleep_notify > timeout error. > > Why? In case of timeout error, we would like to handle it by sending HPI - to let device interrupt/stop the prg state. > > One final question, I noticed that you have removed the check for > MMC_CAP2_FULL_PWR_CYCLE in the _mmc_suspend() function, why? As far as we understand, this MMC_CAP2_FULL_PWR_CYCLE was used to distinguish between PON (when the power can be cut) and Sleep (when the power have to stay ON). Now we have Sleep_Notification PON, which allows to cut the power also in case of Sleep. Hope the interpretation above is correct. > > Kind regards > Uffe ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
