LKML Archive on
help / color / mirror / Atom feed
From: Eric Anholt <>
To: Geert Uytterhoeven <>,
	"Rafael J. Wysocki" <>
Cc: Kevin Hilman <>,
	Ulf Hansson <>,
	"linux-kernel\" <>,
	Tomasz Figa <>,
	Greg Kroah-Hartman <>,
	Linux PM list <>
Subject: Re: [PATCH] PM / Domains: If an OF node is found but no device probed yet, defer.
Date: Thu, 12 Mar 2015 12:31:54 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3188 bytes --]

Geert Uytterhoeven <> writes:

> On Wed, Mar 11, 2015 at 11:08 PM, Rafael J. Wysocki <> wrote:
>> More CCes.
>> On Wednesday, March 11, 2015 08:27:28 AM Eric Anholt wrote:
>>> If we've declared a power domain in the OF, and the OF node is found
>>> but the requested domain hasn't been registered on it yet, then we
>>> probably have just tried to probe before the power domain driver has.
>>> Defer our device's probe until it shows up.
>>> Signed-off-by: Eric Anholt <>
>> Kevin, Ulf, any chance to have a look at this, please?
>>> ---
>>> I ran into this when turning my ad-hoc code for BCM2835 (Raspberry Pi)
>>> USB poweron support in the DWC2 controller to an OF-based power domain
>>> declaration.
> I guess you are initializing the PM domains from module_init()?
> I use core_initcall() in arch/arm/mach-shmobile/pm-rmobile.c to make sure it's
> initialized earlier, as e.g. the interrupt controller uses postcore_initcall().

Yeah, it's just going through normal DT-based module initialization as a
module_platform_driver().  And it depends on another platform driver
(the mailbox to talk to the firmware in the first place), so it's
unlikely to show up early.

The BCM2835 architecture maintainers don't appear to be fans of fixed
init sequence stuff (our sequence is just bcm2835_setup_restart(),
bcm2835_init_clocks(), of_platform_populate()), and I figured
dependencies expressed in DT were supposed to be the ideal way for
things these days.  I can try turning my drivers into fixed init
sequence code, but I don't expect this to go over well.

>>> drivers/base/power/domain.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>>> index ba4abbe..2b93c98 100644
>>> --- a/drivers/base/power/domain.c
>>> +++ b/drivers/base/power/domain.c
>>> @@ -2064,7 +2064,7 @@ EXPORT_SYMBOL_GPL(of_genpd_del_provider);
>>>  struct generic_pm_domain *of_genpd_get_from_provider(
>>>                                       struct of_phandle_args *genpdspec)
>>>  {
>>> -     struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
>>> +     struct generic_pm_domain *genpd = ERR_PTR(-EPROBE_DEFER);
> Currently platform_drv_probe() just continues if dev_pm_domain_attach() returns
> a different error than -EPROBE_DEFER, which is what you are seeing.
> Your change does have the side effect that a new DT with PM domains won't
> work on an older kernel that doesn't have the PM domain driver yet.
> Whether this is a good or a bad thing depends on your bootloader. If all PM
> domains are powered when Linux boots, it can work without PM domain driver.
> Since DT PM domains are quite recent, I guess this is the case for most
> existing SoCs.

The main bootloader doesn't turn on these domains, thus why I wrote a
driver for it (so I could get USB and thus netowrking).  You can
chainload U-Boot and it'll turn it on USB for you, though.

Is there a way we could maybe tell if there's a driver due to try
probing on the node but that hasn't had a chance yet?  That could
mitigate the backwards kernel compat for new DT problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2015-03-12 19:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-11 15:27 [PATCH] PM / Domains: If an OF node is found but no device probed yet, defer Eric Anholt
2015-03-11 22:08 ` Rafael J. Wysocki
2015-03-11 22:14   ` Geert Uytterhoeven
2015-03-12 19:31     ` Eric Anholt [this message]
2015-03-13 18:01     ` Kevin Hilman
2015-03-16  8:44       ` Geert Uytterhoeven
2015-03-16 10:12       ` Ulf Hansson
2015-03-18 22:55         ` Eric Anholt
2015-03-12  8:39 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).