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

[Jon Hunter <jonathanh@nvidia.com>]

On 06/10/16 13:22, Ulf Hansson wrote:
> On 20 September 2016 at 12:28, Jon Hunter <jonathanh@nvidia.com> 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