All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	USB list <linux-usb@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Kishon Vijay Abraham I <kishon@ti.com>
Subject: Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()
Date: Mon, 4 Dec 2017 11:41:07 +0100	[thread overview]
Message-ID: <CAPDyKFr4=Vct_-w1euOsEnb3WdeBvH9mz12zNTUfX7Z6nEwRuw@mail.gmail.com> (raw)
In-Reply-To: <TY1PR06MB09929CD76E67B64FDE54B170D8390@TY1PR06MB0992.apcprd06.prod.outlook.com>

On 1 December 2017 at 12:03, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> 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@renesas.com> wrote:
>> > Hi,
>> >
>> >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM
>> >>
>> >> On 29 November 2017 at 10:43, Geert Uytterhoeven <geert@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

Great, that confirms my theory.

I will re-work the patch and re-post it to see what people thinks about it.

>
> 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.

Yes, very likely!

However, I need some more time to look into this to be able to suggest
a solution.

>
> JFYI, the ehci-platform.c doesn't have runtime PM handling.
> So, I think that error message doesn't output from ehci devices.

Right, thanks!

Kind regards
Uffe

  parent reply	other threads:[~2017-12-04 10:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12  0:27 [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status() Rafael J. Wysocki
2017-11-13 13:26 ` Ulf Hansson
2017-11-13 21:50   ` Rafael J. Wysocki
2017-11-13 21:58     ` Rafael J. Wysocki
2017-11-14  9:13     ` Ulf Hansson
2017-11-14  9:56       ` Ulf Hansson
2017-11-14 21:44         ` Rafael J. Wysocki
2017-11-15  7:22           ` Ulf Hansson
2017-11-16  9:22 ` Johan Hovold
2017-11-16 13:57   ` Rafael J. Wysocki
2017-11-28 10:58 ` Geert Uytterhoeven
2017-11-28 12:48   ` Yoshihiro Shimoda
2017-11-28 15:06     ` Alan Stern
2017-11-29  8:21       ` Yoshihiro Shimoda
2017-11-28 17:22     ` Ulf Hansson
2017-11-29  8:21       ` Yoshihiro Shimoda
2017-11-29  9:24         ` Ulf Hansson
2017-11-29  9:43           ` Geert Uytterhoeven
2017-11-29  9:59             ` Ulf Hansson
2017-11-29 14:09               ` Geert Uytterhoeven
2017-11-30 12:51               ` Yoshihiro Shimoda
2017-12-01  9:22                 ` Ulf Hansson
2017-12-01 11:03                   ` Yoshihiro Shimoda
2017-12-01 11:54                     ` Yoshihiro Shimoda
2017-12-04 10:41                     ` Ulf Hansson [this message]
2017-12-05  3:23                       ` Yoshihiro Shimoda
2017-12-05  3:23                         ` Yoshihiro Shimoda
2017-12-05 15:03                         ` Alan Stern
2017-12-05 15:23                           ` Rafael J. Wysocki
2017-12-05 15:48                         ` Ulf Hansson
2017-11-28 14:17   ` Rafael J. Wysocki

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='CAPDyKFr4=Vct_-w1euOsEnb3WdeBvH9mz12zNTUfX7Z6nEwRuw@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=stern@rowland.harvard.edu \
    --cc=yoshihiro.shimoda.uh@renesas.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.