Re: [PATCH RFC 2/4] mmc: sdio: Add capability to skip SDIO reset at scan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25 April 2017 at 13:20, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> On 25/04/17 13:46, Ulf Hansson wrote:
>> On 25 April 2017 at 09:57, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>>> On 25/04/17 10:52, Ulf Hansson wrote:
>>>> +Grygorii Strashko
>>>>
>>>> On 25 April 2017 at 08:21, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>>>>> On 24/04/17 23:33, Ulf Hansson wrote:
>>>>>> On 21 April 2017 at 12:08, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>>>>>>> The SDIO card state might be being preserved during hibernation, for
>>>>>>> example a SDIO wifi card supporting WOWLAN. That state will be lost if an
>>>>>>> SDIO reset is done. One way to avoid that would be to build mmc core as a
>>>>>>> module and simply not load it until after attempting to restore the
>>>>>>> hibernation image. However that won't work if the hibernation image is
>>>>>>> stored on eMMC which, of course, requires mmc core.
>>>>>>
>>>>>> I don't follow here. Are you saying the SDIO card is kept powered in
>>>>>> hibernation, as to be able to support WOWLAN, right?
>>>>>
>>>>> Yes
>>>>
>>>> Okay, makes sense!
>>>>
>>>>>
>>>>>>
>>>>>> Then, it feels plain wrong the mmc_rescan() tries to re-initialize it.
>>>>>> That should never happen, unless something is broken of course.
>>>>>
>>>>> The thing to note about hibernation is that there is a regular boot in
>>>>> between saving the hibernation image and restoring it again.  At boot time,
>>>>> the kernel knows almost nothing about whether there is a hibernation image
>>>>> and whether or not it will be restored.  Consequently it becomes difficult
>>>>> to avoid mmc_rescan().  As mentioned above, we need mmc_rescan() to
>>>>> initialize the eMMC so that the hibernation image can be read.
>>>>
>>>> What's wrong with using the hibernation callbacks in the struct
>>>> dev_pm_ops? We already do this.
>>>
>>> Here is the scenario.  The kernel has just booted.  User space wants to try
>>> to restore a hibernation image, if there is one.  So user space loads the
>>> mmc core because the hibernation image is on eMMC.  Mmc core does an SDIO
>>> reset on the SDIO card and the state is lost.  It has little to do with pm
>>> callbacks AFAICS.
>>
>> Ah, now I see what you mean. I thought the problem was during the
>> actual restoring of the hibernation image.
>>
>> Alright, when a boot is triggered by WOWLAN , you want to avoid
>> sending the reset command for the SDIO card before the
>> re-initialization of the SDIO card starts.
>>
>> The problem with this approach is that you can't differentiate between
>> a cold boot and a boot triggered by WOWLAN, right!? In other words, in
>> some cases the reset command may be needed while in other it won't.
>
> SDIO reset is only needed if the card has not been power-cycled.  The
> assumption is that the platform takes care of that when needed. e.g. when
> rebooting instead of going to S4.
>
>>
>> Maybe you can elaborate more on what exactly what the problem is with
>> sending the reset command when the boot is triggered from WOWLAN? Yes,
>> the SDIO card loses its context, but how is that a problem?
>
> The wifi driver expects to find the function in an initialized state.

So how does the the wifi driver distinguish this a boot caused by
WOWLAN - and not a cold boot?

> Otherwise it would have to re-enable the function and re-do the
> function-specific initialization.  I don't know if there are other

At boot the SDIO func driver becomes probed, when the mmc core finds
and SDIO card and then registers a func device for it. Are you saying
that the SDIO func driver can take shortcuts when enabling the func
device, when the boot is trigger from WOWLAN?

> consequences.  Presumably it will have lost any information about the nature
> of the wake-up trigger.

How does that matter?

Kind regards
Uffe
--
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



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux