Hi, > From: Ulf Hansson, Sent: Friday, December 1, 2017 6:22 PM > > + Kishon > > On 30 November 2017 at 13:51, Yoshihiro Shimoda > <yoshihiro.shimoda...@renesas.com> wrote: > > Hi, > > > >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM > >> > >> On 29 November 2017 at 10:43, Geert Uytterhoeven <ge...@linux-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