On 06/10/16 13:22, Ulf Hansson wrote: > 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. 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 -- 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