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 18:59:43 +0200 [thread overview]
Message-ID: <20210604185943.3efa2a19@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().
>
> > [ 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().
>
> > 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? :)
>
sigh,..
ok, it breaks something. gadget (at least ecm) only works if
musb/phy stuff is loaded, ecm configured via configfs
rmmod omap2430
modprube 2430
until the next usb disconnect
and another rmmod/modprobe is required.
The following musb patches were applied additional to that one you
added to this mail on top of 5.13-rc4.
usb: musb: fix MUSB_QUIRK_B_DISCONNECT_99 handling
usb: musb: Add missing PM suspend and resume functions for 2430 glue
usb: musb: Check devctl status again for a spurious session request
Regards,
Andreas
next prev parent reply other threads:[~2021-06-04 16:59 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
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 [this message]
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=20210604185943.3efa2a19@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.