All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: Tony Lindgren <tony@atomide.com>
Cc: Bin Liu <b-liu@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
	letux-kernel@openphoenux.org
Subject: Re: [PATCH] usb: musb: Check devctl status again for a spurious session request
Date: Fri, 4 Jun 2021 11:59:49 +0200	[thread overview]
Message-ID: <20210604115949.4c74d4af@aktux> (raw)
In-Reply-To: <YLn06uuntThMlaTQ@atomide.com>

On Fri, 4 Jun 2021 12:39:54 +0300
Tony Lindgren <tony@atomide.com> wrote:

> * Andreas Kemnade <andreas@kemnade.info> [210604 08:35]:
> > I inserted some more dev-dbg
> > [   60.241790] PM: suspend entry (deep)
> > [   60.245513] Filesystems sync: 0.000 seconds
> > [   60.251312] Freezing user space processes ... (elapsed 0.001 seconds) done.
> > [   60.260040] OOM killer disabled.
> > [   60.263275] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> > [   60.272338] printk: Suspending console(s) (use no_console_suspend to debug)
> > [   60.281311] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_resume  
> > -> this is triggered by what?  
> 
> I think that comes from the pm_runtime_get_sync() in musb_suspend().
> 
@@ -2825,6 +2826,7 @@ static int musb_suspend(struct device *dev)
        struct musb     *musb = dev_to_musb(dev);
        unsigned long   flags;
        int ret;
+       dev_dbg(musb->controller, "musb_suspend begin\n");
 
        ret = pm_runtime_get_sync(dev);
        if (ret < 0) {

my dev_dbg comes before that.

> > [   60.281341] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume  
> > -> and here something stays on...  
> > 
> > [   60.346374] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_phy_power_on
> > [   60.796630] musb-hdrc musb-hdrc.0.auto: musb_suspend begin
> > [   60.796722] musb-hdrc musb-hdrc.0.auto: musb_suspend end
> > [   60.796752] musb-omap2430 480ab000.usb_otg_hs: omap2430 suspend
> > [   60.796783] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_suspend
> > [   60.796783] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_phy_power_off
> > [   60.796813] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_usb_suspend
> > [   60.806549] Disabling non-boot CPUs ...
> > [   60.806579] Successfully put all powerdomains to target state  
> 
> Well since commit 88d26136a256 ("PM: Prevent runtime suspend during system resume")
> nothing gets runtime idled during suspend with the extra pm_runtime_get_noresume()
> call in device_prepare() that does not get released until in device_complete().
> 
well, the result is that the phy stays powered on. And that is the
problem.
static int twl4030_phy_power_off(struct phy *phy)
and 
static int __maybe_unused twl4030_usb_suspend(struct device *dev)
do not turn off the phy. I think the solution is to turn the phy off if
no cable is connected. 

> > forcing omap2430 runtime on before suspend:
> > [  160.467742] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_resume
> > [  165.001495] PM: suspend entry (deep)
> > [  165.005218] Filesystems sync: 0.000 seconds
> > [  165.010284] Freezing user space processes ... (elapsed 0.001 seconds) done.
> > [  165.018981] OOM killer disabled.
> > [  165.022247] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> > [  165.031311] printk: Suspending console(s) (use no_console_suspend to debug)
> > [  165.040496] musb-hdrc musb-hdrc.0.auto: musb_suspend begin
> > [  165.040618] musb-hdrc musb-hdrc.0.auto: musb_suspend end
> > [  165.040618] musb-omap2430 480ab000.usb_otg_hs: omap2430 suspend
> > [  165.040649] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_suspend
> > [  165.040679] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_usb_suspend
> > [  165.050506] Disabling non-boot CPUs ...
> > [  165.050537] Successfully put all powerdomains to target state  
> 
> That's interesting. Hmm so we bail out early based on glue->is_runtime_suspended,
> and omap3 is still probing devices with omap_device.c instead of ti-sysc.c, so
> sounds like the duplicate calls you noticed might cause the issue.
> 
> Does the following patch fix things for you or does something else break again? :)
> 
looks like something I have already tried, but I will give it a look
again.

Regards,
Andreas

  reply	other threads:[~2021-06-04 10:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 15:06 [PATCH] usb: musb: Check devctl status again for a spurious session request Tony Lindgren
2021-05-27 19:15 ` Andreas Kemnade
2021-05-28  5:57   ` Tony Lindgren
2021-05-28  9:37     ` Andreas Kemnade
2021-06-02  5:41       ` Tony Lindgren
2021-06-03 21:22         ` Andreas Kemnade
2021-06-04  8:35     ` Andreas Kemnade
2021-06-04  9:39       ` Tony Lindgren
2021-06-04  9:59         ` Andreas Kemnade [this message]
2021-06-04 10:08           ` Tony Lindgren
2021-06-04 10:20             ` Andreas Kemnade
2021-06-04 14:45         ` Andreas Kemnade
2021-06-04 16:59         ` Andreas Kemnade
2021-06-05  5:18           ` Tony Lindgren
2021-06-05 14:20             ` Andreas Kemnade
2021-06-06  6:01               ` Tony Lindgren

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=20210604115949.4c74d4af@aktux \
    --to=andreas@kemnade.info \
    --cc=b-liu@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=tony@atomide.com \
    /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.