Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1523370 > unrolled thread

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-16 11:50 +0100
    Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-16 14:00 +0100
      Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-22 12:20 +0100
        Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Ulf Hansson <ulf.hansson@linaro.org> - 2016-11-22 14:40 +0100
          Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-22 15:30 +0100
        Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Kevin Hilman <khilman@baylibre.com> - 2016-11-22 19:30 +0100
          Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-22 19:50 +0100
            Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Stephen Boyd <sboyd@codeaurora.org> - 2016-11-24 03:40 +0100
          Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-22 23:40 +0100
            Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-23 10:30 +0100
              Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-23 14:20 +0100

#1523370 — Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

Hi Kevin, Ulf,

On 03/11/16 14:20, Jon Hunter wrote:
> 
> On 11/10/16 10:15, Jon Hunter wrote:
> 
> ...
> 
>>>>> Second, another way of seeing this is: Depending on the current
>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>> topology - but the device would still remain in the same PM domain.
>>>>>
>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>> the selected configuration. Would that better reflect the HW?
>>>>
>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>> like to get to ...
>>>>
>>>>         usb@70090000 {
>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>                 ...
>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>         };
>>>
>>> So, is this really is a proper description of the HW? Isn't it so,
>>> that the usb device always resides in one and the same PM domain?
>>
>> I guess technically, the usbhost controller resides in one partition and
>> the super-speed logic in another. So could the usbhost domain be the
>> primary? Possibly, but the device cannot be probed without both enabled.
>>
>>> Now, depending on the selected speed mode (superspeed) additional
>>> logic may needs to be powered on and configured for the usb device to
>>> work?
>>> Perhaps, one could consider those additional logics as a master/parent
>>> PM domain for the usb device's PM domain?
>>>
>>> Or this is not how the HW works? :-)
>>
>> It might be possible for this case, but to be honest, the more I think
>> about this, I do wonder if we need to be able to make the framework a
>> lot more flexible for devices that need multiple power-domains. In other
>> words, for devices that use multiple domains allow them to control them
>> similarly to what we do for regulators or clocks. So if there is more
>> than one defined, then the genpd core will not bind the device to the
>> pm-domain and let the driver handle it. This way if you do need more
>> granular control of the pm-domains in the driver you can do whatever you
>> need to.
>>
>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>> control multiple power-domains individually from within the context of a
>> single device driver.
> 
> So Rajendra commented to say that he does not see a need for individual
> control of power-domains for now, but a need for specifying multiple.
> 
> One simple option would be to allow users to specify multiple and have
> the genpd core effectively ignore such devices and leave it to the
> driver to configure manually. I have been able to do this for XUSB by
> dynamically adding power-domains to the device.
> 
> Let me know if you have any more thoughts on how we can do this.

Any more thoughts on this? Seems that there are a few others that would
be interested in supporting multiple domains for a device.

Cheers
Jon

-- 
nvpublic

[toc] | [next] | [standalone]

#1523448

On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> Hi Kevin, Ulf,
>
> On 03/11/16 14:20, Jon Hunter wrote:
>>
>> On 11/10/16 10:15, Jon Hunter wrote:
>>
>> ...
>>
>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>
>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>
>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>> like to get to ...
>>>>>
>>>>>         usb@70090000 {
>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>                 ...
>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>         };
>>>>
>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>> that the usb device always resides in one and the same PM domain?
>>>
>>> I guess technically, the usbhost controller resides in one partition and
>>> the super-speed logic in another. So could the usbhost domain be the
>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>
>>>> Now, depending on the selected speed mode (superspeed) additional
>>>> logic may needs to be powered on and configured for the usb device to
>>>> work?
>>>> Perhaps, one could consider those additional logics as a master/parent
>>>> PM domain for the usb device's PM domain?
>>>>
>>>> Or this is not how the HW works? :-)
>>>
>>> It might be possible for this case, but to be honest, the more I think
>>> about this, I do wonder if we need to be able to make the framework a
>>> lot more flexible for devices that need multiple power-domains. In other
>>> words, for devices that use multiple domains allow them to control them
>>> similarly to what we do for regulators or clocks. So if there is more
>>> than one defined, then the genpd core will not bind the device to the
>>> pm-domain and let the driver handle it. This way if you do need more
>>> granular control of the pm-domains in the driver you can do whatever you
>>> need to.
>>>
>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>> control multiple power-domains individually from within the context of a
>>> single device driver.
>>
>> So Rajendra commented to say that he does not see a need for individual
>> control of power-domains for now, but a need for specifying multiple.
>>
>> One simple option would be to allow users to specify multiple and have
>> the genpd core effectively ignore such devices and leave it to the
>> driver to configure manually. I have been able to do this for XUSB by
>> dynamically adding power-domains to the device.
>>
>> Let me know if you have any more thoughts on how we can do this.
>
> Any more thoughts on this? Seems that there are a few others that would
> be interested in supporting multiple domains for a device.

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.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1527424

On 16/11/16 12:53, Rafael J. Wysocki wrote:
> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>> Hi Kevin, Ulf,
>>
>> On 03/11/16 14:20, Jon Hunter wrote:
>>>
>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>
>>> ...
>>>
>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>
>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>
>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>> like to get to ...
>>>>>>
>>>>>>         usb@70090000 {
>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>                 ...
>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>         };
>>>>>
>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>> that the usb device always resides in one and the same PM domain?
>>>>
>>>> I guess technically, the usbhost controller resides in one partition and
>>>> the super-speed logic in another. So could the usbhost domain be the
>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>
>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>> logic may needs to be powered on and configured for the usb device to
>>>>> work?
>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>> PM domain for the usb device's PM domain?
>>>>>
>>>>> Or this is not how the HW works? :-)
>>>>
>>>> It might be possible for this case, but to be honest, the more I think
>>>> about this, I do wonder if we need to be able to make the framework a
>>>> lot more flexible for devices that need multiple power-domains. In other
>>>> words, for devices that use multiple domains allow them to control them
>>>> similarly to what we do for regulators or clocks. So if there is more
>>>> than one defined, then the genpd core will not bind the device to the
>>>> pm-domain and let the driver handle it. This way if you do need more
>>>> granular control of the pm-domains in the driver you can do whatever you
>>>> need to.
>>>>
>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>> control multiple power-domains individually from within the context of a
>>>> single device driver.
>>>
>>> So Rajendra commented to say that he does not see a need for individual
>>> control of power-domains for now, but a need for specifying multiple.
>>>
>>> One simple option would be to allow users to specify multiple and have
>>> the genpd core effectively ignore such devices and leave it to the
>>> driver to configure manually. I have been able to do this for XUSB by
>>> dynamically adding power-domains to the device.
>>>
>>> Let me know if you have any more thoughts on how we can do this.
>>
>> Any more thoughts on this? Seems that there are a few others that would
>> be interested in supporting multiple domains for a device.
> 
> 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.

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.

Cheers
Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]

#1527506

On 22 November 2016 at 12:12, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> Hi Kevin, Ulf,
>>>
>>> On 03/11/16 14:20, Jon Hunter wrote:
>>>>
>>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>>
>>>> ...
>>>>
>>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>>
>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>>
>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>>> like to get to ...
>>>>>>>
>>>>>>>         usb@70090000 {
>>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>>                 ...
>>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>>         };
>>>>>>
>>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>>> that the usb device always resides in one and the same PM domain?
>>>>>
>>>>> I guess technically, the usbhost controller resides in one partition and
>>>>> the super-speed logic in another. So could the usbhost domain be the
>>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>>
>>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>>> logic may needs to be powered on and configured for the usb device to
>>>>>> work?
>>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>>> PM domain for the usb device's PM domain?
>>>>>>
>>>>>> Or this is not how the HW works? :-)
>>>>>
>>>>> It might be possible for this case, but to be honest, the more I think
>>>>> about this, I do wonder if we need to be able to make the framework a
>>>>> lot more flexible for devices that need multiple power-domains. In other
>>>>> words, for devices that use multiple domains allow them to control them
>>>>> similarly to what we do for regulators or clocks. So if there is more
>>>>> than one defined, then the genpd core will not bind the device to the
>>>>> pm-domain and let the driver handle it. This way if you do need more
>>>>> granular control of the pm-domains in the driver you can do whatever you
>>>>> need to.
>>>>>
>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>>> control multiple power-domains individually from within the context of a
>>>>> single device driver.
>>>>
>>>> So Rajendra commented to say that he does not see a need for individual
>>>> control of power-domains for now, but a need for specifying multiple.
>>>>
>>>> One simple option would be to allow users to specify multiple and have
>>>> the genpd core effectively ignore such devices and leave it to the
>>>> driver to configure manually. I have been able to do this for XUSB by
>>>> dynamically adding power-domains to the device.
>>>>
>>>> Let me know if you have any more thoughts on how we can do this.
>>>
>>> Any more thoughts on this? Seems that there are a few others that would
>>> be interested in supporting multiple domains for a device.
>>
>> 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.

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.

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.

Kind regards
Uffe

[toc] | [prev] | [next] | [standalone]

#1527552

On 22/11/16 13:31, Ulf Hansson wrote:
> On 22 November 2016 at 12:12, Jon Hunter <jonathanh@nvidia.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

[toc] | [prev] | [next] | [standalone]

#1527836 — Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

Jon Hunter <jonathanh@nvidia.com> writes:

> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> Hi Kevin, Ulf,
>>>
>>> On 03/11/16 14:20, Jon Hunter wrote:
>>>>
>>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>>
>>>> ...
>>>>
>>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>>
>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>>
>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>>> like to get to ...
>>>>>>>
>>>>>>>         usb@70090000 {
>>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>>                 ...
>>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>>         };
>>>>>>
>>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>>> that the usb device always resides in one and the same PM domain?
>>>>>
>>>>> I guess technically, the usbhost controller resides in one partition and
>>>>> the super-speed logic in another. So could the usbhost domain be the
>>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>>
>>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>>> logic may needs to be powered on and configured for the usb device to
>>>>>> work?
>>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>>> PM domain for the usb device's PM domain?
>>>>>>
>>>>>> Or this is not how the HW works? :-)
>>>>>
>>>>> It might be possible for this case, but to be honest, the more I think
>>>>> about this, I do wonder if we need to be able to make the framework a
>>>>> lot more flexible for devices that need multiple power-domains. In other
>>>>> words, for devices that use multiple domains allow them to control them
>>>>> similarly to what we do for regulators or clocks. So if there is more
>>>>> than one defined, then the genpd core will not bind the device to the
>>>>> pm-domain and let the driver handle it. This way if you do need more
>>>>> granular control of the pm-domains in the driver you can do whatever you
>>>>> need to.
>>>>>
>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>>> control multiple power-domains individually from within the context of a
>>>>> single device driver.
>>>>
>>>> So Rajendra commented to say that he does not see a need for individual
>>>> control of power-domains for now, but a need for specifying multiple.
>>>>
>>>> One simple option would be to allow users to specify multiple and have
>>>> the genpd core effectively ignore such devices and leave it to the
>>>> driver to configure manually. I have been able to do this for XUSB by
>>>> dynamically adding power-domains to the device.
>>>>
>>>> Let me know if you have any more thoughts on how we can do this.
>>>
>>> Any more thoughts on this? Seems that there are a few others that would
>>> be interested in supporting multiple domains for a device.
>> 
>> 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.

@Rafael: Re: why it would be useful...

Many ARM SoCs have devices that have independent power rails for the
memory and the logic of an IP block.  For example, while powering off
the logic you could keep the memory at a retention voltage, so you'd
want to treat those power domains separately.

Today, in order to model this, you'd have to create another (dummy)
device, just for the memory and put it in its own domain so the two
could be controlled separately.

> 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.

@Jon: Do you think the nesting could work to handle the above case too?

> 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.

And, that's not describing the hardware very accurately either, IIUC

> 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.
>
> 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.

IMO, constructing a network of new struct devices just to workaround
limitations in the framework doesn't sound quite right either.

Kevin

[toc] | [prev] | [next] | [standalone]

#1527842

On 22/11/16 18:26, Kevin Hilman wrote:
> Jon Hunter <jonathanh@nvidia.com> writes:
> 
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>> Hi Kevin, Ulf,
>>>>
>>>> On 03/11/16 14:20, Jon Hunter wrote:
>>>>>
>>>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>>>
>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>>>
>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>>>> like to get to ...
>>>>>>>>
>>>>>>>>         usb@70090000 {
>>>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>>>                 ...
>>>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>>>         };
>>>>>>>
>>>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>>>> that the usb device always resides in one and the same PM domain?
>>>>>>
>>>>>> I guess technically, the usbhost controller resides in one partition and
>>>>>> the super-speed logic in another. So could the usbhost domain be the
>>>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>>>
>>>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>>>> logic may needs to be powered on and configured for the usb device to
>>>>>>> work?
>>>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>>>> PM domain for the usb device's PM domain?
>>>>>>>
>>>>>>> Or this is not how the HW works? :-)
>>>>>>
>>>>>> It might be possible for this case, but to be honest, the more I think
>>>>>> about this, I do wonder if we need to be able to make the framework a
>>>>>> lot more flexible for devices that need multiple power-domains. In other
>>>>>> words, for devices that use multiple domains allow them to control them
>>>>>> similarly to what we do for regulators or clocks. So if there is more
>>>>>> than one defined, then the genpd core will not bind the device to the
>>>>>> pm-domain and let the driver handle it. This way if you do need more
>>>>>> granular control of the pm-domains in the driver you can do whatever you
>>>>>> need to.
>>>>>>
>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>>>> control multiple power-domains individually from within the context of a
>>>>>> single device driver.
>>>>>
>>>>> So Rajendra commented to say that he does not see a need for individual
>>>>> control of power-domains for now, but a need for specifying multiple.
>>>>>
>>>>> One simple option would be to allow users to specify multiple and have
>>>>> the genpd core effectively ignore such devices and leave it to the
>>>>> driver to configure manually. I have been able to do this for XUSB by
>>>>> dynamically adding power-domains to the device.
>>>>>
>>>>> Let me know if you have any more thoughts on how we can do this.
>>>>
>>>> Any more thoughts on this? Seems that there are a few others that would
>>>> be interested in supporting multiple domains for a device.
>>>
>>> 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.
> 
> @Rafael: Re: why it would be useful...
> 
> Many ARM SoCs have devices that have independent power rails for the
> memory and the logic of an IP block.  For example, while powering off
> the logic you could keep the memory at a retention voltage, so you'd
> want to treat those power domains separately.
> 
> Today, in order to model this, you'd have to create another (dummy)
> device, just for the memory and put it in its own domain so the two
> could be controlled separately.
> 
>> 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.
> 
> @Jon: Do you think the nesting could work to handle the above case too?

Difficult to say without all the details, for example do we need to
worry about the order in which they are power-up/down?

>> 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.
> 
> And, that's not describing the hardware very accurately either, IIUC

Right, but in DT may be I would have something like ...

	dev-xyz {
		compatible ="blah blah";
		...
		power-domains = <&domain-a>, <&domain-b>;
	};

... which should describe the h/w, but it could just be implemented so
that to make this work b would be nested under a. We would have to turn
them on in sequence any way and so nesting here would be ok. The only
problem would be then if you have another device ...

	dev-abc {
		compatible ="blah blah";
		...
		power-domains = <&domain-b>, <&domain-c>;
	};

... which would mean c is nested under a and b. So may be for the
generic case this is no good either.

>> 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.
>>
>> 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.
> 
> IMO, constructing a network of new struct devices just to workaround
> limitations in the framework doesn't sound quite right either.

I agree.

Cheers
Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]

#1528929

On 11/22, Jon Hunter wrote:
> 
> On 22/11/16 18:26, Kevin Hilman wrote:
> > Jon Hunter <jonathanh@nvidia.com> writes:
> > 
> >> 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.
> >>
> >> 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.
> > 
> > IMO, constructing a network of new struct devices just to workaround
> > limitations in the framework doesn't sound quite right either.
> 
> I agree.
> 

Marek is attempting to do this for the samsung clock
controller[1] (patch #5 is informative). From what I can tell
they have one DT node for their clock controller because it's one
register address space to control clocks. But, certain clocks
exposed by that driver only work when certain power domains are
enabled. For example, they have a clock controller that exposes
clock signals for multimedia hardware blocks like video
accelerators, gpus, and cameras. The clocks seem to have been
placed inside different power domains for the multimedia hardware
they're associated with, so there may be 10 or so power domains
that need to be enabled at different times for different clocks
to work. If the GPU power domain isn't enabled when the GPU
clocks are touched by the driver, things break, etc.

In the proposed patchset, we have the top-level clock controller
node with subnodes for each power domain that needs to be
associated with clocks inside these different multimedia blocks.
So we end up with one parent device and attached driver for the
clock driver, and then that driver populates child nodes as
devices and matches up clocks with child nodes while registering
clks with clk_register(). Because we pass a dev pointer to
clk_register, we associate different devices with different
clocks all from the same top-level clock controller device
driver. Then clk framework calls runtime_pm APIs with devices
used during clk registration. Some of those devices don't have
any driver bound to them, which feels odd.

This seems like a case where we really want a better way to
explicitly control power domains without making up subnodes and
registering struct devices just to work around the one device to
one genpd construct we have today. Maybe power domains just don't
map to genpd though and that's the disconnect.

[1] http://lkml.kernel.org/r/1477311130-6534-1-git-send-email-m.szyprowski@samsung.com
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1527992

On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Jon Hunter <jonathanh@nvidia.com> writes:
>
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>> Hi Kevin, Ulf,
>>>>
>>>> On 03/11/16 14:20, Jon Hunter wrote:
>>>>>
>>>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>>>
>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>>>
>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>>>> like to get to ...
>>>>>>>>
>>>>>>>>         usb@70090000 {
>>>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>>>                 ...
>>>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>>>         };
>>>>>>>
>>>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>>>> that the usb device always resides in one and the same PM domain?
>>>>>>
>>>>>> I guess technically, the usbhost controller resides in one partition and
>>>>>> the super-speed logic in another. So could the usbhost domain be the
>>>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>>>
>>>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>>>> logic may needs to be powered on and configured for the usb device to
>>>>>>> work?
>>>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>>>> PM domain for the usb device's PM domain?
>>>>>>>
>>>>>>> Or this is not how the HW works? :-)
>>>>>>
>>>>>> It might be possible for this case, but to be honest, the more I think
>>>>>> about this, I do wonder if we need to be able to make the framework a
>>>>>> lot more flexible for devices that need multiple power-domains. In other
>>>>>> words, for devices that use multiple domains allow them to control them
>>>>>> similarly to what we do for regulators or clocks. So if there is more
>>>>>> than one defined, then the genpd core will not bind the device to the
>>>>>> pm-domain and let the driver handle it. This way if you do need more
>>>>>> granular control of the pm-domains in the driver you can do whatever you
>>>>>> need to.
>>>>>>
>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>>>> control multiple power-domains individually from within the context of a
>>>>>> single device driver.
>>>>>
>>>>> So Rajendra commented to say that he does not see a need for individual
>>>>> control of power-domains for now, but a need for specifying multiple.
>>>>>
>>>>> One simple option would be to allow users to specify multiple and have
>>>>> the genpd core effectively ignore such devices and leave it to the
>>>>> driver to configure manually. I have been able to do this for XUSB by
>>>>> dynamically adding power-domains to the device.
>>>>>
>>>>> Let me know if you have any more thoughts on how we can do this.
>>>>
>>>> Any more thoughts on this? Seems that there are a few others that would
>>>> be interested in supporting multiple domains for a device.
>>>
>>> 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.
>
> @Rafael: Re: why it would be useful...
>
> Many ARM SoCs have devices that have independent power rails for the
> memory and the logic of an IP block.  For example, while powering off
> the logic you could keep the memory at a retention voltage, so you'd
> want to treat those power domains separately.
>
> Today, in order to model this, you'd have to create another (dummy)
> device, just for the memory and put it in its own domain so the two
> could be controlled separately.

Perhaps if you want to use genpd for that. :-)

Let me rephrase, though.  I don't see why and how it would be useful
to intercept the flow of PM callbacks for a given device more than
once.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1528236

On 22/11/16 21:55, Rafael J. Wysocki wrote:
> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Jon Hunter <jonathanh@nvidia.com> writes:
>>
>>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>> Hi Kevin, Ulf,
>>>>>
>>>>> On 03/11/16 14:20, Jon Hunter wrote:
>>>>>>
>>>>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>>>>
>>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>>>>
>>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>>>>> like to get to ...
>>>>>>>>>
>>>>>>>>>         usb@70090000 {
>>>>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>>>>                 ...
>>>>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>>>>         };
>>>>>>>>
>>>>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>>>>> that the usb device always resides in one and the same PM domain?
>>>>>>>
>>>>>>> I guess technically, the usbhost controller resides in one partition and
>>>>>>> the super-speed logic in another. So could the usbhost domain be the
>>>>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>>>>
>>>>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>>>>> logic may needs to be powered on and configured for the usb device to
>>>>>>>> work?
>>>>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>>>>> PM domain for the usb device's PM domain?
>>>>>>>>
>>>>>>>> Or this is not how the HW works? :-)
>>>>>>>
>>>>>>> It might be possible for this case, but to be honest, the more I think
>>>>>>> about this, I do wonder if we need to be able to make the framework a
>>>>>>> lot more flexible for devices that need multiple power-domains. In other
>>>>>>> words, for devices that use multiple domains allow them to control them
>>>>>>> similarly to what we do for regulators or clocks. So if there is more
>>>>>>> than one defined, then the genpd core will not bind the device to the
>>>>>>> pm-domain and let the driver handle it. This way if you do need more
>>>>>>> granular control of the pm-domains in the driver you can do whatever you
>>>>>>> need to.
>>>>>>>
>>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>>>>> control multiple power-domains individually from within the context of a
>>>>>>> single device driver.
>>>>>>
>>>>>> So Rajendra commented to say that he does not see a need for individual
>>>>>> control of power-domains for now, but a need for specifying multiple.
>>>>>>
>>>>>> One simple option would be to allow users to specify multiple and have
>>>>>> the genpd core effectively ignore such devices and leave it to the
>>>>>> driver to configure manually. I have been able to do this for XUSB by
>>>>>> dynamically adding power-domains to the device.
>>>>>>
>>>>>> Let me know if you have any more thoughts on how we can do this.
>>>>>
>>>>> Any more thoughts on this? Seems that there are a few others that would
>>>>> be interested in supporting multiple domains for a device.
>>>>
>>>> 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.
>>
>> @Rafael: Re: why it would be useful...
>>
>> Many ARM SoCs have devices that have independent power rails for the
>> memory and the logic of an IP block.  For example, while powering off
>> the logic you could keep the memory at a retention voltage, so you'd
>> want to treat those power domains separately.
>>
>> Today, in order to model this, you'd have to create another (dummy)
>> device, just for the memory and put it in its own domain so the two
>> could be controlled separately.
> 
> Perhaps if you want to use genpd for that. :-)
> 
> Let me rephrase, though.  I don't see why and how it would be useful
> to intercept the flow of PM callbacks for a given device more than
> once.

In this RFC, all I was proposing is that we create a dummy pm-domain
that is a child of the actual pm-domains it uses and this new dummy
pm-domain is associated with the device. Hence, you are still only
intercepting the flow of PM callback once even with this approach. I am
just using the parent-child relationship to ensure that all require
pm-domains are turned on thats all. Sorry if I am still missing your point!

Cheers
Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]

#1528398

On Wed, Nov 23, 2016 at 10:29 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 22/11/16 21:55, Rafael J. Wysocki wrote:
>> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>> Jon Hunter <jonathanh@nvidia.com> writes:
>>>
>>>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>>> Hi Kevin, Ulf,
>>>>>>
>>>>>> On 03/11/16 14:20, Jon Hunter wrote:
>>>>>>>
>>>>>>> On 11/10/16 10:15, Jon Hunter wrote:
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>>>>>>
>>>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>>>>>>
>>>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>>>>>>> like to get to ...
>>>>>>>>>>
>>>>>>>>>>         usb@70090000 {
>>>>>>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>>>>>>                 ...
>>>>>>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>>>>>>         };
>>>>>>>>>
>>>>>>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>>>>>>> that the usb device always resides in one and the same PM domain?
>>>>>>>>
>>>>>>>> I guess technically, the usbhost controller resides in one partition and
>>>>>>>> the super-speed logic in another. So could the usbhost domain be the
>>>>>>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>>>>>>
>>>>>>>>> Now, depending on the selected speed mode (superspeed) additional
>>>>>>>>> logic may needs to be powered on and configured for the usb device to
>>>>>>>>> work?
>>>>>>>>> Perhaps, one could consider those additional logics as a master/parent
>>>>>>>>> PM domain for the usb device's PM domain?
>>>>>>>>>
>>>>>>>>> Or this is not how the HW works? :-)
>>>>>>>>
>>>>>>>> It might be possible for this case, but to be honest, the more I think
>>>>>>>> about this, I do wonder if we need to be able to make the framework a
>>>>>>>> lot more flexible for devices that need multiple power-domains. In other
>>>>>>>> words, for devices that use multiple domains allow them to control them
>>>>>>>> similarly to what we do for regulators or clocks. So if there is more
>>>>>>>> than one defined, then the genpd core will not bind the device to the
>>>>>>>> pm-domain and let the driver handle it. This way if you do need more
>>>>>>>> granular control of the pm-domains in the driver you can do whatever you
>>>>>>>> need to.
>>>>>>>>
>>>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>>>>>>> control multiple power-domains individually from within the context of a
>>>>>>>> single device driver.
>>>>>>>
>>>>>>> So Rajendra commented to say that he does not see a need for individual
>>>>>>> control of power-domains for now, but a need for specifying multiple.
>>>>>>>
>>>>>>> One simple option would be to allow users to specify multiple and have
>>>>>>> the genpd core effectively ignore such devices and leave it to the
>>>>>>> driver to configure manually. I have been able to do this for XUSB by
>>>>>>> dynamically adding power-domains to the device.
>>>>>>>
>>>>>>> Let me know if you have any more thoughts on how we can do this.
>>>>>>
>>>>>> Any more thoughts on this? Seems that there are a few others that would
>>>>>> be interested in supporting multiple domains for a device.
>>>>>
>>>>> 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.
>>>
>>> @Rafael: Re: why it would be useful...
>>>
>>> Many ARM SoCs have devices that have independent power rails for the
>>> memory and the logic of an IP block.  For example, while powering off
>>> the logic you could keep the memory at a retention voltage, so you'd
>>> want to treat those power domains separately.
>>>
>>> Today, in order to model this, you'd have to create another (dummy)
>>> device, just for the memory and put it in its own domain so the two
>>> could be controlled separately.
>>
>> Perhaps if you want to use genpd for that. :-)
>>
>> Let me rephrase, though.  I don't see why and how it would be useful
>> to intercept the flow of PM callbacks for a given device more than
>> once.
>
> In this RFC, all I was proposing is that we create a dummy pm-domain
> that is a child of the actual pm-domains it uses and this new dummy
> pm-domain is associated with the device. Hence, you are still only
> intercepting the flow of PM callback once even with this approach. I am
> just using the parent-child relationship to ensure that all require
> pm-domains are turned on thats all. Sorry if I am still missing your point!

No, you aren't, thanks for explaining that!

Thanks,
Rafael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web