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]

Message-ID: <52493231-71f4-1b62-b325-8532e63e4229@nvidia.com>
Date:   Tue, 28 Feb 2017 15:18:47 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>, <geert@...ux-m68k.org>,
        <rnayak@...eaurora.org>, <stanimir.varbanov@...aro.org>,
        <sboyd@...eaurora.org>, Marek Szyprowski <m.szyprowski@...sung.com>
CC:     <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that
 require multiple domains

Hi all,

On 20/09/16 11:28, Jon Hunter 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.

I wanted to kick this thread again now in the new year and see if there
is still some interest in pursuing this?

There is still very much a need from a Tegra perspective. I have put all
those who responded on TO.

I know that a lot of time has passed since we discuss this and so if you
are scratching your head wondering what I am harping on about,
essentially with this RFC I was looking for a way to support devices
that require multiple power domains where the domains do not have a
parent-child relationship and so not are nested in anyway.

If you need me to elaborate on the need for this, I am happy to do this.
My take away from when we discussed this last year, was that there was a
need for this.

Cheers
Jon

-- 
nvpublic