On 20 September 2016 at 12:28, Jon Hunter <[email protected]> wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) is partitioned across 3 PM domains which are:
> - XUSBA: Superspeed logic (for USB 3.0)
> - XUSBB: Device controller
> - XUSBC: Host controller
>
> These power domains are not nested and can be powered-up and down
> independently of one another. In practice different scenarios require
> different combinations of the power domains, for example:
> - Superspeed host: XUSBA and XUSBC
> - Superspeed device: XUSBA and XUSBB
>
> Although it could be possible to logically nest both the XUSBB and XUSBC
> domains under the XUSBA, superspeed may not always be used/required and
> so this would keep it on unnecessarily.
>
> Given that Tegra uses device-tree for describing the hardware, it would
> be ideal that the device-tree 'power-domains' property for generic PM
> domains could be extended to allow more than one PM domain to be
> specified. For example, define the following the Tegra210 xHCI device ...
>
> usb@70090000 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
> };
>
> This RFC extends the generic PM domain framework to allow a device to
> define more than one PM domain in the device-tree 'power-domains'
> property.
First, I don't really like extending the internal logic of genpd to
deal with multiple PM domains per device. *If* this really is needed,
I think we should try to extend the struct device to cover this, then
make genpd to use it somehow.
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?
[...]
Kind regards
Uffe
On 06/10/16 13:22, Ulf Hansson wrote:
> On 20 September 2016 at 12:28, Jon Hunter <[email protected]> wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) is partitioned across 3 PM domains which are:
>> - XUSBA: Superspeed logic (for USB 3.0)
>> - XUSBB: Device controller
>> - XUSBC: Host controller
>>
>> These power domains are not nested and can be powered-up and down
>> independently of one another. In practice different scenarios require
>> different combinations of the power domains, for example:
>> - Superspeed host: XUSBA and XUSBC
>> - Superspeed device: XUSBA and XUSBB
>>
>> Although it could be possible to logically nest both the XUSBB and XUSBC
>> domains under the XUSBA, superspeed may not always be used/required and
>> so this would keep it on unnecessarily.
>>
>> Given that Tegra uses device-tree for describing the hardware, it would
>> be ideal that the device-tree 'power-domains' property for generic PM
>> domains could be extended to allow more than one PM domain to be
>> specified. For example, define the following the Tegra210 xHCI device ...
>>
>> usb@70090000 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>> };
>>
>> This RFC extends the generic PM domain framework to allow a device to
>> define more than one PM domain in the device-tree 'power-domains'
>> property.
>
> First, I don't really like extending the internal logic of genpd to
> deal with multiple PM domains per device. *If* this really is needed,
> I think we should try to extend the struct device to cover this, then
> make genpd to use it somehow.
I had looked at that initially but it was looking quite complex because
of the various structures (dev_pm_domain in the device structure,
pm_domain_data in pm_subsys_data, etc). This implementation is quite
simple and less intrusive. However, if there is a lot of interest in
this and it does appear to be, I would agree that having the device
structure handle this would be best.
> 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>;
};
Cheers
Jon
--
nvpublic
On 10 October 2016 at 13:18, Jon Hunter <[email protected]> wrote:
>
> On 06/10/16 13:22, Ulf Hansson wrote:
>> On 20 September 2016 at 12:28, Jon Hunter <[email protected]> wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) is partitioned across 3 PM domains which are:
>>> - XUSBA: Superspeed logic (for USB 3.0)
>>> - XUSBB: Device controller
>>> - XUSBC: Host controller
>>>
>>> These power domains are not nested and can be powered-up and down
>>> independently of one another. In practice different scenarios require
>>> different combinations of the power domains, for example:
>>> - Superspeed host: XUSBA and XUSBC
>>> - Superspeed device: XUSBA and XUSBB
>>>
>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>> domains under the XUSBA, superspeed may not always be used/required and
>>> so this would keep it on unnecessarily.
>>>
>>> Given that Tegra uses device-tree for describing the hardware, it would
>>> be ideal that the device-tree 'power-domains' property for generic PM
>>> domains could be extended to allow more than one PM domain to be
>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>
>>> usb@70090000 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>> };
>>>
>>> This RFC extends the generic PM domain framework to allow a device to
>>> define more than one PM domain in the device-tree 'power-domains'
>>> property.
>>
>> First, I don't really like extending the internal logic of genpd to
>> deal with multiple PM domains per device. *If* this really is needed,
>> I think we should try to extend the struct device to cover this, then
>> make genpd to use it somehow.
>
> I had looked at that initially but it was looking quite complex because
> of the various structures (dev_pm_domain in the device structure,
> pm_domain_data in pm_subsys_data, etc). This implementation is quite
I didn't care much about the complexity, more trying to understand how
the HW actually works. :-)
> simple and less intrusive. However, if there is a lot of interest in
> this and it does appear to be, I would agree that having the device
> structure handle this would be best.
>
>> 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?
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? :-)
Kind regards
Uffe
On 10/10/16 15:04, Ulf Hansson wrote:
> On 10 October 2016 at 13:18, Jon Hunter <[email protected]> wrote:
>>
>> On 06/10/16 13:22, Ulf Hansson wrote:
>>> On 20 September 2016 at 12:28, Jon Hunter <[email protected]> wrote:
>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>>> controllers) is partitioned across 3 PM domains which are:
>>>> - XUSBA: Superspeed logic (for USB 3.0)
>>>> - XUSBB: Device controller
>>>> - XUSBC: Host controller
>>>>
>>>> These power domains are not nested and can be powered-up and down
>>>> independently of one another. In practice different scenarios require
>>>> different combinations of the power domains, for example:
>>>> - Superspeed host: XUSBA and XUSBC
>>>> - Superspeed device: XUSBA and XUSBB
>>>>
>>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>>> domains under the XUSBA, superspeed may not always be used/required and
>>>> so this would keep it on unnecessarily.
>>>>
>>>> Given that Tegra uses device-tree for describing the hardware, it would
>>>> be ideal that the device-tree 'power-domains' property for generic PM
>>>> domains could be extended to allow more than one PM domain to be
>>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>>
>>>> usb@70090000 {
>>>> compatible = "nvidia,tegra210-xusb";
>>>> ...
>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>> };
>>>>
>>>> This RFC extends the generic PM domain framework to allow a device to
>>>> define more than one PM domain in the device-tree 'power-domains'
>>>> property.
>>>
>>> First, I don't really like extending the internal logic of genpd to
>>> deal with multiple PM domains per device. *If* this really is needed,
>>> I think we should try to extend the struct device to cover this, then
>>> make genpd to use it somehow.
>>
>> I had looked at that initially but it was looking quite complex because
>> of the various structures (dev_pm_domain in the device structure,
>> pm_domain_data in pm_subsys_data, etc). This implementation is quite
>
> I didn't care much about the complexity, more trying to understand how
> the HW actually works. :-)
OK.
>> simple and less intrusive. However, if there is a lot of interest in
>> this and it does appear to be, I would agree that having the device
>> structure handle this would be best.
>>
>>> 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.
Cheers
Jon
--
nvpublic
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.
Cheers
Jon
--
nvpublic
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
On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On 16/11/16 12:53, Rafael J. Wysocki wrote:
> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On 22 November 2016 at 12:12, Jon Hunter <[email protected]> wrote:
>
> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On 22/11/16 13:31, Ulf Hansson wrote:
> On 22 November 2016 at 12:12, Jon Hunter <[email protected]> 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
Jon Hunter <[email protected]> writes:
> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On 22/11/16 18:26, Kevin Hilman wrote:
> Jon Hunter <[email protected]> writes:
>
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <[email protected]> wrote:
> Jon Hunter <[email protected]> writes:
>
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On 22/11/16 21:55, Rafael J. Wysocki wrote:
> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <[email protected]> wrote:
>> Jon Hunter <[email protected]> writes:
>>
>>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On Wed, Nov 23, 2016 at 10:29 AM, Jon Hunter <[email protected]> wrote:
>
> On 22/11/16 21:55, Rafael J. Wysocki wrote:
>> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <[email protected]> wrote:
>>> Jon Hunter <[email protected]> writes:
>>>
>>>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <[email protected]> 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
On 11/22, Jon Hunter wrote:
>
> On 22/11/16 18:26, Kevin Hilman wrote:
> > Jon Hunter <[email protected]> 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/[email protected]
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi Stephen,
Thanks for pointing to my patches, but I would like to clarify a few things.
On 2016-11-24 03:30, Stephen Boyd wrote:
> On 11/22, Jon Hunter wrote:
>> On 22/11/16 18:26, Kevin Hilman wrote:
>>> Jon Hunter <[email protected]> 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).
You probably meant patch #3 / #4, which is a patch for Exynos 4412
( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ).
Patch #5 is for Exynos 5433, which already has separate nodes for
each clock sub-controller, so there is no problem to add generic
power domains there (see multiple CMU nodes):
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261
> 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.
This is valid only for the Exynos4412 case (and not-yet-posted
Exynos5422), which has a single clock controller node and patch #4
added a sub-node for ISP clocks part (the only one which in fact
is in the other power domain).
> 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.
Right, this is how I did it for Exynos4412 case.
> Some of those devices don't have
> any driver bound to them, which feels odd.
Well, I don't get this. In the proposed patches each sub-node has
a separate driver, none is left without a driver.
> 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.
Having an API for full control over multiple power domain assigned to
a single device node might indeed solve somehow this problem, but as
long as runtime pm is tied to struct device, this will again end in
creating virtual sub-devices per each power domain to fit runtime pm
principles. However we might be able to avoid creating sub-nodes in
the device tree.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 29/11/16 11:33, Marek Szyprowski wrote:
> Hi Stephen,
>
> Thanks for pointing to my patches, but I would like to clarify a few
> things.
>
> On 2016-11-24 03:30, Stephen Boyd wrote:
>> On 11/22, Jon Hunter wrote:
>>> On 22/11/16 18:26, Kevin Hilman wrote:
>>>> Jon Hunter <[email protected]> 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).
>
> You probably meant patch #3 / #4, which is a patch for Exynos 4412
> ( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ).
Sorry for the delay, I have been meaning to get back to this thread. Yes
patch #3 is definitely interesting and highlights power-domain
complexities with various SoCs ...
https://marc.info/?l=linux-clk&m=147731116925951&w=2
> Patch #5 is for Exynos 5433, which already has separate nodes for
> each clock sub-controller, so there is no problem to add generic
> power domains there (see multiple CMU nodes):
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261
>
>
>> 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.
>
> This is valid only for the Exynos4412 case (and not-yet-posted
> Exynos5422), which has a single clock controller node and patch #4
> added a sub-node for ISP clocks part (the only one which in fact
> is in the other power domain).
>
>> 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.
>
> Right, this is how I did it for Exynos4412 case.
>
>> Some of those devices don't have
>> any driver bound to them, which feels odd.
>
> Well, I don't get this. In the proposed patches each sub-node has
> a separate driver, none is left without a driver.
So it seems in this solution you are creating a pseudo device in order
to control the pm-domain.
>> 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.
>
> Having an API for full control over multiple power domain assigned to
> a single device node might indeed solve somehow this problem, but as
> long as runtime pm is tied to struct device, this will again end in
> creating virtual sub-devices per each power domain to fit runtime pm
> principles. However we might be able to avoid creating sub-nodes in
> the device tree.
Right, but what if the device is not bound to the pm-domain? What if due
to pm-domain complexities we need to have finer granularity over the
control of pm-domains?
It seems to me that because we don't always have foresight into the
creativeness of the SoC h/w designers, may be the pm-domain framework
needs to expose APIs to allow direct control of the pm-domains without
binding the pm-domain to the device, so that these APIs can be called in
the context on the runtime-pm callbacks as we do for clocks, etc.
Do you see any benefit to being able to directly control the pm-domains?
That said, I did recently add a patch to prevent the expose of the
pm-domain struct to clients in order to be able to remove them [0].
However, ref-counting can obviously be used to allow client to request
handles to pm-domains.
Cheers
Jon
[0]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/base/power/domain.c?id=f58d4e5ab0ca3453f091eab514474e9fdbfc539f
--
nvpublic