Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

[Grygorii Strashko <grygorii.strashko@ti.com>]

On 11/13/2014 06:40 PM, Ulf Hansson wrote:
> [...]
>
>>>
>>> To my understanding, Rafael's primary reason for not accepting that
>>> was that it's not common, but it's platform-specific.
>>> http://marc.info/?l=linux-pm&m=140243462304669&w=2
>>
>> For the record, I still believe this is platform-specific.
>>
>> I also think that the knowledge about what power (or generally PM) domain
>> a device should belong to is not in a bus type or in the driver core.  That
>> knowledge is in the code that enumerates devices.
>>
>> I wonder, then, if we could set the PM domain pointer at about the time
>> when we set the bus type pointer?  Things will be consistent all the way
>> through the entire device life cycle then.
>
> Could you maybe give some examples of where such code should be
> invoked from then?
>
> I do see some difficulties in your suggestion, primarily since we
> would need all PM domains to be initialized prior "device
> enumeration". That in combination with doing PM domain initialization
> from SOC specific code, could be a bit tricky to sort out.
>
>>
>>> Now, even if we would reconsider doing as you propose, what would the
>>> actual benefit be? Obviously, we would get less amount of code to
>>> maintain, which is one reason, but are there more?
>>
>> The same set of subsystem-level PM callbacks will be present for the device
>> throughout its life cycle.
>
> I also do like the consistency this would bring us.
>
>>
>>>> 2. When do we power up the devices (and the domains)? Right now devices
>>>> in ACPI power domain are powered when they are attached to the power
>>>> domain (which coincides with probing), but generic power domains do not
>>>> do that. Can we add a separate API to explicitly power up the device (and
>>>> its domain if it is powered down) and do it again, either in device core
>>>> or in individual buses. This way, regardless of runtime PM or not, we
>>>> will have devices powered on when driver tries to bind to them. If
>>>> binding fails we can power down the device.
>>>
>>> Isn't that exactly what I implemented in [1], what am I missing?
>>
>> Not really.  Dmitry is talking about a generic interface independent of
>> PM domains.
>>
>> If we have pm_power_up(dev)/pm_power_down(dev), then the PM core could use it
>> around really_probe() for all devices.  In theory.  But that's what we
>> started with when we were working on the runtime PM framework and we ended
>> up with what we have today.
>>
>> Problem is, pm_power_up() would probably end up being pretty much the same as
>> pm_runtime_resume() without executing driver callbacks and similarly for
>> pm_power_down().  That's why I was thinking about running pm_runtime_resume()
>> at the time we know that driver callbacks are not present, just for the
>> purpose of powering up the device.  [That has a problem of working with
>> CONFIG_PM_RUNTIME unset, but let me set this one aside for a while.]
>
> I take this as we are aligned on using the runtime PM API from the
> driver core isn't a solution to the problem, right?
>
> I think Alan in the other thread [1] also had some valuable points to
> why we shouldn't use runtime PM from the driver core to power on PM
> domains.
>
> To that I would also like to add, that I really don't think the driver
> core should enable runtime PM, that's up to each an every
> subsystem/driver to decide when/if to do. Using pm_runtime_resume() or
> any of the pm_runtime_get*() API from the driver core would have
> required that as well.
>
>>
>> Now, Grygorii seems to be claiming that some drivers *require* their
>> .runtime_resume() callbacks to be executed during .probe() pretty much
>> before anything else which won't happen if pm_runtime_resume() is done
>> before really_probe().  I'm wondering, then, which drivers those are.
>
> I have looked around and there are certainly hole bunch of such drivers.
>
> I guess the most important reason to why these drivers behave as
> stated, is because that's been the common solution to make sure the PM
> domain stays powered during probe. It's unfortunate that no one cared
> about this until now.

PM domain is smth. relatively new :) Initial intention is to
execute Bus's PM callbacks and wake up parent devices.

regards,
-grygorii