lkml.org 
[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
From
Date
Hi Rafael, Kevin, Ulf,

Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?

Cheers
Jon

On 28/02/17 15:29, Geert Uytterhoeven wrote:
> Hi Jon,
>
> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <jonathanh@nvidia.com> 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 -- geert@linux-m68k.org
>
> 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 10:37    [W:0.073 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site