linux-kernel - Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Mar 2017 12:45:24 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Linux PM list <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that
 require multiple domains

+Björn

On 13 March 2017 at 10:37, Jon Hunter <jonathanh@...dia.com> 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
reply.
In this way, the driver/subsystem gains full flexibility of managing
its device's PM domains, which seems like the best future-proof
solution.

Kind regards
Uffe

>
> 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@...dia.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@...90000 {
>>>>               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@...ux-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