Date:   Tue, 22 Nov 2016 14:28:46 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that
 require multiple domains


On 22/11/16 13:31, Ulf Hansson wrote:
> On 22 November 2016 at 12:12, Jon Hunter <jonathanh@...dia.com> wrote:
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:

...

>>> There is a design limitation to that, however.
>>>
>>> The PM domain concept really is about intercepting the flow of PM
>>> callbacks for a device in order to carry out additional operations,
>>> not covered by the bus type or driver.  That's why there is only one
>>> set of PM domain callbacks per device and I don't quite see how and
>>> why it would be useful to add more of them in there.
>>
>> Sorry for the delay.
>>
>> We do, however, support the nesting of power-domains to allow more than
>> one power-domain to be controlled for a device. For the current
>> implementations that use nested power-domains, I am not sure if the
>> power-domains are truly nested or just describing a relationship between
>> power-domains.
>>
>> Nesting power-domains could also work for the Tegra XHCI device.
>> However, I don't wish to statically nest the power-domains in
>> device-tree where they are defined so they are always nested, because
>> this may not be always necessary. However, I would rather the client of
>> the power-domains specify which power-domains they require and
>> dynamically nested the power-domains at runtime. This is slightly
>> different to what I proposed in this RFC, but it is not really beyond
>> the bounds of what we support today IMO. What is missing is a means to
>> do this dynamically and not statically.
> 
> Hmm, going back to the original post for this thread.
> 
> This more or less sounds very similar as the case for when Rajendra
> described the problem for the video decode block in msm8996, except
> that in this case you already have couple of different struct devices
> available that for you could deploy runtime PM.

In this case there is only one device, so ...

> Then, wouldn't it be possible to assign a parent/child relationship
> for these devices, each device has its own corresponding PM domain -
> instead of having to dynamically nest PM domains.

... no that will not work in this case unless we create some sort of
dummy parent device but I was hoping to avoid that.

> Runtime PM will help to make sure parent devices are always active
> when child devices also are active.
> 
>>
>> By the way, I am not sure if you are suggesting that for devices that
>> may need multiple power-domains we should architect the driver
>> differently and split it up in some way such that we have a power-domain
>> per device. But for the case of the Tegra XHCI it is quite complex
>> because the driver loads firmware which runs on a micro-controller and
>> we need to manage the various power-domains that are used.
> 
> Again, if it's possible to model the topology by using parent/child
> devices, and deploy runtime PM for them, then we shouldn't need more
> than one PM domain per device. I am not sure that works here though,
> but just and idea.

It is really not too different from how we nest power-domains today. In
fact I can manually nest them and add them to the device in the driver
with the existing genpd APIs. However, I don't have a meaningful way to
describe the power-domains that are used by the device in DT because
there is more than one.

Cheers
Jon

-- 
nvpublic

Powered by blists - more mailing lists