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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
