On 29-05-18, 12:04, Ulf Hansson wrote: > Changes in v2: > - Addressed comments from Geert around DT doc. > - Addressed comments from Jon around clarification of how to use this > and changes to returned error codes. > - Fixed build error in case CONFIG_PM was unset. > > There are devices that are partitioned across multiple PM domains. Currently > these can't be supported well by the available PM infrastructures we have in > the kernel. This series is an attempt to address this. > > The interesting parts happens from patch 5 an onwards, including a minor DT > update to the existing power-domain bindings, the 4 earlier are just trivial > clean-ups of some related code in genpd, which I happened to stumble over. > > Some additional background: > > One existing case where devices are partitioned across multiple PM domains, is > the Nvida Tegra 124/210 X-USB subsystem. A while ago Jon Hunter (Nvidia) sent a > series, trying to address these issues, however this is a new approach, while > it re-uses the same concepts from DT point of view. > > The Tegra 124/210 X-USB subsystem contains of a host controller and a device > controller. Each controller have its own independent PM domain, but are being > partitioned across another shared PM domain for the USB super-speed logic. > > Currently to make the drivers work, either the related PM domains needs to stay > powered on always or the PM domain topology needs to be in-correctly modelled > through sub-domains. In both cases PM domains may be powered on while they > don't need to be, so in the end this means - wasting power -. > > As stated above, this series intends to address these problem from a PM > infrastructure point of view. More details are available in each changelog. > > It should be noted that this series has been tested on HW, however only by using > a home-cooked test PM domain driver for genpd and together with a test driver. > This allowed me to play with PM domain (genpd), runtime PM and device links. > > Any further deployment for real use cases are greatly appreciated. I am happy to > to help, if needed! Reviewed-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx> -- viresh -- 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
