[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <TY1PR06MB09929CD76E67B64FDE54B170D8390@TY1PR06MB0992.apcprd06.prod.outlook.com>
Date: Fri, 1 Dec 2017 11:03:33 +0000
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
CC: Geert Uytterhoeven <geert@...ux-m68k.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alan Stern <stern@...land.harvard.edu>,
"USB list" <linux-usb@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Kishon Vijay Abraham I <kishon@...com>
Subject: RE: [PATCH] PM / runtime: Drop children check from
__pm_runtime_set_status()
Hi,
> From: Ulf Hansson, Sent: Friday, December 1, 2017 6:22 PM
>
> + Kishon
>
> On 30 November 2017 at 13:51, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@...esas.com> wrote:
> > Hi,
> >
> >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM
> >>
> >> On 29 November 2017 at 10:43, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >> > Hi Ulf,
> > <snip>
> >> Okay, so the problem remains no matter which solution for wakeup you
> >> pick in genpd.
> >
> > Yes. Today I could reproduce this issue without usb host driver.
> > - The renesas_usb3 usb peripheral driver has generic phy handling.
> > (The peripheral driver uses different generic phy driver (phy-rcar-gen3-usb3.c) though.)
> > --> If I used the current renesas_usb3 (this means doesn't call phy_power_{on,off}(),
> > the issue didn't happen.
> > --> If I added phy_power_{on,off}() calling, the issue happened.
> > --> So, I'm thinking the APIs are related to the issue.
>
> Yes.
>
> >
> > - The generic phy APIs are in drivers/phy/phy-core.c.
> > --> The phy-rcar-gen3-usb[23] drivers call only pm_runtime_enable() before devm_phy_create().
> > --> The phy-core will call pm_runtime_{get_sync,put}() in phy_{init,exit,power_{on,off}}.
> > --> So, IIUC, both devices of phy-<dev_name>.<id> and <dev_name> will be handled by runtime PM APIs.
> > --> The runtime PM implementation of phy-core seems good to me. But...?
>
>
> I have digested the information that you and Geert provided, thanks!
>
> So, my conclusions so far is:
>
> The phy core is using runtime PM reference counting at
> phy_power_on|off(). Although it does that on the phy core device,
> which is a child device of the phy provider device.
>
> Because phy_power_off() is called during system suspend from phy
> consumer drivers like usb, the phy core device (child) and the phy
> provider device (parent) will never become runtime suspended (because
> the PM core has invoked pm_runtime_get_no_resume() for all device in
> the device prepare phase).
>
> Then, when genpd calls pm_runtime_force_suspend() at the suspend noirq
> phase for the phy provider device, the call to
> pm_runtime_set_suspended() in there, triggers the earlier error
> message, which is because the child (phy core device) is still runtime
> resumed.
Thank you very much for the conclusions!
It's helpful to me about runtime PM behavior.
> >> Then this seems to point to that the driver may be misbehaving in some
> >> way. I can help to check what is going on.
> >
> > I guess so. But, I don't find yet...
>
> I think the below patch will help, although I am not sure if that is
> sufficient as a long term fix.
Thank you very much for your help!
Also, I'm not sure how to fix for a long term kernels though...
> Can you please try and see if it solves the problems?
Sure! I tested your patch, and then the following message disappeared!
Enabling runtime PM for inactive device (ee080200.usb-phy) with active children
However, the following message still exists.
Enabling runtime PM for inactive device (ee080000.usb) with active children
So, I guess ohci-platform.c also has similar issue.
JFYI, the ehci-platform.c doesn't have runtime PM handling.
So, I think that error message doesn't output from ehci devices.
Best regards,
Yoshihiro Shimoda
Powered by blists - more mailing lists