On 20 September 2016 at 12:28, Jon Hunter <jonathanh@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
