[lkml]   [2017]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

On 13 March 2017 at 10:37, Jon Hunter <> wrote:
> Hi Rafael, Kevin, Ulf,
> Looks like there is still some interest/needs in/for this. Any thoughts
> on how we can move this forward?

At the Linaro Connect last week, I was talking to Björn, Rajendra and
Stephen more about these related issues.

It definitely seems like we need to progress with this somehow,
meaning we need a solution for being able to associate a device with
more than one PM domain. In that context, I don't think genpd based on
its current design, is a good fit to solve the problem.

Instead I think we need something entirely new (perhaps some code can
be borrowed from genpd), which is more similar to the clock/regulator
framework. In other words, what you also were suggesting in a earlier
In this way, the driver/subsystem gains full flexibility of managing
its device's PM domains, which seems like the best future-proof

Kind regards

> Cheers
> Jon
> On 28/02/17 15:29, Geert Uytterhoeven wrote:
>> Hi Jon,
>> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <> wrote:
>>> 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.
>> It definitely makes sense to me, as the "power-domains" DT binding is not
>> limited to plain "power areas", but may refer to clock domains, too
>> (cfr. the Linux "PM Domain" notion).
>> For my (Renesas) use case, we have devices that are part of both a power
>> area and a clock domain. Currently this is handled by the power area driver
>> calling into the clock driver.
>> Thanks!
>> Gr{oetje,eeting}s,
>> Geert
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>> -- Linus Torvalds
> --
> nvpublic

 \ /
  Last update: 2017-03-13 12:46    [W:0.200 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site