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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Oct 2016 12:18:10 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that
 require multiple domains


On 06/10/16 13:22, Ulf Hansson wrote:
> On 20 September 2016 at 12:28, Jon Hunter <jonathanh@...dia.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@...90000 {
>>                 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@...90000 {
		compatible = "nvidia,tegra210-xusb";
		...
		power-domains = <&pd_xusbhost>, <&pd_xusbss>;
	};

Cheers
Jon

-- 
nvpublic