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

From: Jon Hunter
Date: Tue Feb 28 2017 - 10:26:21 EST


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

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