mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device
Date: Sun, 24 Dec 2017 13:00:56 +0100	[thread overview]
Message-ID: <1828343.cNA3rGR90B@aspire.rjw.lan> (raw)
In-Reply-To: <CAPDyKFpHNYbf3Wz+Hq94Rm_wQGWnQkc6B2cS_RTjkmcbeeZoyw@mail.gmail.com>

On Saturday, December 23, 2017 4:09:33 PM CET Ulf Hansson wrote:
> [...]
> 
> >
> > So IMO the changes you are proposing make sense regardless of the
> > genpd issue, because they generally simplify the phy code, but the
> > additional use_runtime_pm field in struct phy represents redundant
> > information (manipulating reference counters shouldn't matter if
> > runtime PM is disabled), so it doesn't appear to be necessary.
> >
> 
> Actually, the first version I posted treated the return codes from
> pm_runtime_get_sync() according to your suggestion above.
> 
> However, Kishon pointed out that it didn't work. That's because, there
> are phy provider drivers that enables runtime PM *after* calling
> phy_create(). And in those cases, that is because they want to treat
> runtime PM themselves.
> 
> I think that's probably something we should look into to change, but I
> find it being a separate issue, that I didn't want to investigate as
> part of this series.
> 
> See more about the thread here:
> https://www.spinics.net/lists/linux-renesas-soc/msg21711.html

Even so, it shouldn't matter when the provider enables runtime PM.

Calling pm_runtime_get_*()/pm_runtime_put_*() should always work as
long as they are balanced properly regardless of whether or not
runtime PM is enabled for the device or it is enabled in the meantime.
Of course, the initial runtime PM status of the device must reflect
the values of the usage counters, but that should not be too hard to
ensure.

The reason why it matters here is because the phy core tries to be smart
about manipulating reference counters by itself and that's a mistake.

So it looks to me like the whole thing needs to be reworked and yes,
that should be done in the first place IMO, because it will make the
issue with genpd go away automatically.

[Why is phy_pm_runtime_get() there at all, for instance?  It seems
to have no users and I kind of don't see use cases for it.  Also
phy_pm_runtime_get_sync() is only used by the phy core in three
places - shouldn't be too hard to fix that.]

So the issue with genpd really seems to be a messenger here. :-)

Thanks,
Rafael

  reply	other threads:[~2017-12-24 12:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20 14:09 [PATCH v2 0/3] phy: core: Re-work runtime PM deployment and fix an issue Ulf Hansson
2017-12-20 14:09 ` [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device Ulf Hansson
2017-12-21  1:39   ` Rafael J. Wysocki
2017-12-21 10:50     ` Ulf Hansson
2017-12-23  1:35       ` Rafael J. Wysocki
2017-12-23  1:50         ` Rafael J. Wysocki
2017-12-23 12:37         ` Ulf Hansson
2017-12-23 12:47           ` Rafael J. Wysocki
2017-12-23 12:39     ` Rafael J. Wysocki
2017-12-23 15:09       ` Ulf Hansson
2017-12-24 12:00         ` Rafael J. Wysocki [this message]
2018-01-02 13:28           ` Ulf Hansson
2017-12-20 14:09 ` [PATCH v2 2/3] phy: core: Drop unused runtime PM APIs Ulf Hansson
2017-12-21 10:33   ` Yoshihiro Shimoda
2017-12-21 10:57     ` Ulf Hansson
2017-12-21 12:24       ` Yoshihiro Shimoda
2017-12-21 14:23         ` Ulf Hansson
2017-12-23  9:55   ` kbuild test robot
2017-12-23 10:08   ` kbuild test robot
2017-12-20 14:09 ` [PATCH v2 3/3] phy: core: Update the runtime PM section in the docs to reflect changes Ulf Hansson

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=1828343.cNA3rGR90B@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=geert@linux-m68k.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=rafael@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®