All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Ricardo Salveti <rsalveti@rsalveti.net>
Cc: eyalr@ti.com, John Stultz <john.stultz@linaro.org>,
	linux-wireless@vger.kernel.org, anders.roxell@linaro.org
Subject: Re: [EXTERNAL] Re: wlcore getting stuck on hikey after the runtime PM autosuspend support change
Date: Fri, 14 Dec 2018 15:28:57 -0800	[thread overview]
Message-ID: <20181214232857.GZ39861@atomide.com> (raw)
In-Reply-To: <CAHYQr0qg31hqyzm9uK03qz=DmUkA9idqTrhLaP9A6nuXPEW73w@mail.gmail.com>

* Ricardo Salveti <rsalveti@rsalveti.net> [181214 12:42]:
> Hi,
> 
> On Thu, Dec 13, 2018 at 12:45 PM Tony Lindgren <tony@atomide.com> wrote:
> > * Ricardo Salveti <rsalveti@rsalveti.net> [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


  reply	other threads:[~2018-12-14 23:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 18:06 wlcore getting stuck on hikey after the runtime PM autosuspend support change Ricardo Salveti
2018-12-11 18:19 ` Tony Lindgren
2018-12-11 18:52   ` Ricardo Salveti
2018-12-11 19:01     ` Tony Lindgren
2018-12-11 19:25       ` Ricardo Salveti
2018-12-11 19:50         ` John Stultz
2018-12-11 20:12           ` Tony Lindgren
2018-12-11 20:23             ` Ricardo Salveti
2018-12-11 20:44               ` Ricardo Salveti
2018-12-12  1:45                 ` Tony Lindgren
2018-12-12  7:27                   ` [EXTERNAL] " Reizer, Eyal
2018-12-12 18:31                     ` Tony Lindgren
2018-12-12 19:24                       ` Ricardo Salveti
2018-12-13  7:49                         ` Reizer, Eyal
2018-12-13 13:52                           ` Ricardo Salveti
2018-12-13 14:45                             ` Tony Lindgren
2018-12-13 14:53                               ` Reizer, Eyal
2018-12-13 14:55                                 ` Ricardo Salveti
2018-12-14 20:41                               ` Ricardo Salveti
2018-12-14 23:28                                 ` Tony Lindgren [this message]
2018-12-15  3:37                                   ` Ricardo Salveti
2018-12-17 14:45                                     ` Tony Lindgren
2018-12-12 19:16                     ` Ricardo Salveti
2018-12-11 21:50               ` Ricardo Salveti
2018-12-11 23:44                 ` Anders Roxell
2018-12-12 18:33                   ` Tony Lindgren
2018-12-17  9:36                     ` Anders Roxell
2018-12-12  1:25                 ` Tony Lindgren
2018-12-12 19:20                   ` Ricardo Salveti
2018-12-11 19:13 ` John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181214232857.GZ39861@atomide.com \
    --to=tony@atomide.com \
    --cc=anders.roxell@linaro.org \
    --cc=eyalr@ti.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rsalveti@rsalveti.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.