[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <878uetq5jk.fsf@eliezer.anholt.net>
Date: Wed, 18 Mar 2015 15:55:43 -0700
From: Eric Anholt <eric@...olt.net>
To: Ulf Hansson <ulf.hansson@...aro.org>,
Kevin Hilman <khilman@...nel.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
Tomasz Figa <tomasz.figa@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] PM / Domains: If an OF node is found but no device probed yet, defer.
Ulf Hansson <ulf.hansson@...aro.org> writes:
> On 13 March 2015 at 19:01, Kevin Hilman <khilman@...nel.org> wrote:
>> Geert Uytterhoeven <geert@...ux-m68k.org> writes:
>>
>>> On Wed, Mar 11, 2015 at 11:08 PM, Rafael J. Wysocki <rjw@...ysocki.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@...olt.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, I think most existing users are initizling PM domains early, but IMO
>> we should be working towards supporting PM domains that are created
>> later as well (as this patch does.)
>
> I do agree, that we _should_ allow PM domains to be created later/any
> time. Unfortunate, that's not going to be a simple one-liner patch.
> :-)
>
> To have genpd_dev_pm_attach() return -EPROBE_DEFER, due to that the PM
> domain hasn’t been _initialized_ yet, we need to know whether a PM
> domain exists at all for the device. In principle we need to split the
> work done by genpd_dev_pm_attach() into the two parts described below.
>
> 1.
> At struct device creation time, done from the "OF core", we also need
> to parse for a PM domain node. If such is found, we somehow needs to
> assigned it to the device.
>
> Normally we would have assigned the struct dev_pm_domain in the struct
> device to deal with this, but that has some implications. Currently
> the struct dev_pm_domain is created from SoC specific code and it's
> also done at different init levels.
I haven't made sense of what's actually proposed here, so I'm not
stepping forward to write this. I think I'd be less confused if the
"struct device" references in the explanation made it clear which ones
were the pm domain controller and which were the pm domain consumer.
Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)
Powered by blists - more mailing lists