[PATCH 2/9] PM / Domains: Remove dev->driver check for runtime PM
Kevin Hilman
khilman at kernel.org
Fri Aug 21 14:04:20 PDT 2015
Geert Uytterhoeven <geert at linux-m68k.org> writes:
> Hi Kevin,
>
> On Fri, Aug 14, 2015 at 7:19 PM, Kevin Hilman <khilman at kernel.org> wrote:
>> On Fri, Aug 14, 2015 at 12:24 AM, Geert Uytterhoeven
>> <geert at linux-m68k.org> wrote:
>>> On Fri, Aug 14, 2015 at 5:40 AM, Kevin Hilman <khilman at kernel.org> wrote:
>>>> Geert Uytterhoeven <geert at linux-m68k.org> writes:
>>>>> On Wed, Aug 12, 2015 at 9:50 PM, Kevin Hilman <khilman at kernel.org> wrote:
>>>>>> This check might have made sense before PM domains, but with PM domains,
>>>>>> it's entirely possible to have a simple device without a driver and the
>>>>>> PM domain handles all the necesary PM, so I think this check
>>>>>> could/should be removed.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> Simple devices without a driver aren't handled automatically.
>>>>> At minimum, the driver should call pm_runtime_enable(), cfr.
>>>>> drivers/bus/simple-pm-bus.c.
>>>>
>>>> That's correct, and in the proof-of-concept stuff I hacked up and in
>>>> Lina's series, the CPU "devices" do indeed to this. Without that, they
>>>> wouldn't end up ever taking this codepath through genpd's
>>>> runtime_suspend and power_off hooks.
>>>>
>>>> Also, I'm not sure if your comment was meant to be an objection to the
>>>> patch? or if you're OK with it.
>>>
>>> My comment was purely meant as a response to "it's entirely possible to have a
>>> simple device without a driver and the PM domain handles all the necesary PM".
>>
>> Right, so if the PM domain does the pm_runtime_enable() for these
>> "simple" devices without drivers, they can still exist without a
>> driver, and the PM domain doing all the magic.
>
> Is it possible to let the PM Domain do the pm_runtime_enable() itself in
> the absence of a driver?
Well, I suppose it's possible, not sure it's recommended. :)
> If yes, I wouldn't have needed simple-pm-bus.c.
> What if a driver is bound later?
Yeah, you're approach is better.
Kevin
More information about the linux-arm-kernel
mailing list