Re: [PATCH] PM / Domains: If an OF node is found but no device probed yet, defer.

[Eric Anholt <eric@anholt.net>]

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

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Wed, Mar 11, 2015 at 11:08 PM, Rafael J. Wysocki <rjw@rjwysocki.net> 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 <eric@anholt.net>
>>
>> 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 --]