* Ricardo Salveti <rsalveti@xxxxxxxxxxxx> [181214 12:42]: > Hi, > > On Thu, Dec 13, 2018 at 12:45 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Ricardo Salveti <rsalveti@xxxxxxxxxxxx> [181213 13:53]: > > > I tried just increasing WL1271_PRE_POWER_ON_SLEEP from 20ms to 50ms > > > (which gets used before calling wl12xx_sdio_power_on), and that was > > > already enough to fix my issues on both hikey and beaglebone black > > > wireless. > > > > OK good to hear that helps :) > > > > > Should we define another pre power on sleep specifically for the sdio > > > case (and use directly in wl12xx_sdio_power_on)? > > > > I'd probably prefer to just increase WL1271_PRE_POWER_ON_SLEEP, > > chances are the same delay is needed in all cases. > > Investigating this issue a bit more, I noticed that the hang happens > when PM decides to not suspend the device when doing an if down/up > cycle. > > Basically since commit 60f36637bbbd ("wlcore: sdio: allow pm to handle > sdio power") PM is now handling the sdio power off/on process, and if > wl12xx_sdio_power_on gets called right after wl12xx_sdio_power_off (if > down/up), the device will not go to the required power off/on sequence > (since PM will abort the suspend process), and the firmware loading > process will fail. I would guess the problem only happens with > autosuspend because of the extra delay it causes (pm_runtime_put > always returns -EBUSY on wl12xx_sdio_power_off with autosuspend). OK thanks for the update, that's interesting. > Is there a way to force the suspend on wl12xx_sdio_power_off, or > should we partially restore the old behavior? Well usually we could do pm_runtime_put_sync_suspend() but here it won't help as the pm_runtime_put() is already in progress by the SDIO subsystem and that's why we get -EBUSY. Does adding a little wait at the end of wl12xx_sdio_power_off() before return? Maybe something like: /* Make sure the card gets powered off */ while (error == -EBUSY && !pm_runtime_suspended(&card->dev) && retries--) { msleep(100); } Regards, Tony