linux-kernel - Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM 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]

Message-ID: <CAMuHMdXr6-pKb0wRfs0_HhNp75ikGOtd-n2mEY-fvVJhaU5idg@mail.gmail.com>
Date:   Wed, 3 May 2017 08:43:46 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Jon Hunter <jonathanh@...dia.com>,
        "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@...r.kernel.org" <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>
Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of
 PM domains

Hi Ulf,

On Wed, Apr 26, 2017 at 11:55 AM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> On 26 April 2017 at 11:17, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>> On Wed, Apr 26, 2017 at 11:04 AM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>>> On 26 April 2017 at 10:06, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>>>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>>>>> However, we currently know about at least two different SoCs that need
>>>>> this. Perhaps we can extend the below list to justify adding a new
>>>>> framework/APIs. Something along the lines what you propose in $subject
>>>>> patchset.
>>>>>
>>>>> 1) Nvidia; to solve the USB super-speed host/device problem.
>>>>> 2) QCOM, which has pointed to several cases where the PM topology is
>>>>> laid out like devices having two PM domains..
>>>>> 3?) I don't fully remember - but I think Geert also pointed to some
>>>>> examples where a device could reside in a clock domain but also in
>>>>> power domain for a Renesas SoC!?
>>>>> 4) ?
>>>>
>>>> Most Renesas SoCs have module clocks, which we model as a clock domain.
>>>> Some Renesas SoCs have power domains for CPUs, others have them for
>>>> devices as well.
>>>> As we always provide a virtual "always-on" power domain in the power domain
>>>> controller, all devices can refer to it using "power-domains" properties,
>>>> and the driver for the power domain controller can just forward the clock
>>>> domain operations to the clock driver.
>>>
>>> Okay, thanks for clarifying this.
>>>
>>> Thinking about this as bit more, when I realized that *if* we would
>>> add a new PM domain framework for explicit control of PM domains, that
>>> would mean you need to deploy support for that in the drivers.
>>
>> Correct.  And we have to update DT bindings and DTS.
>>
>>> On the other hand, as you anyway would need to change the drivers, you
>>> could instead deploy clock support in the drivers, which would avoid
>>> using the clock domain. In that way, you could still stay with one PM
>>> domain pointer per device, used to control the power domains instead.
>>> Right? Or would that have other implications?
>>
>> That's exactly what we're doing already.
>
> No really, but perhaps I was not clear enough.
>
> Currently you deploy only runtime PM support in the driver and don't
> do any clk_get() etc. Then you have a PM domain (genpd) attached to
> the device and makes use of genpd's device specific callbacks, in
> struct gpd_dev_ops ->start|stop(), which allows you to control clocks
> for each device. Of course this is perfectly okay.

OK.

> So then my question is/was; does there exist cases when these devices
> (already attached to a PM domain) would needed to be attach to yet
> another separate PM domain? From the nicely detailed description
> below, I find the answer to be *no*!?

Apart from the SYSC power areas and the CPG/MSSR clock domain
we don't have a use case for multiple power domains.

>> Which means that if you allow multiple entries in power-domains, we
>> have to change drivers, DT bindings, and DTS again (which we may
>> decide not to do ;-)
>>
>> On SH/R-Mobile, we always did it that way, as the user manual had an
>> explicit "always-on" power domain.
>>
>> On R-Car Gen2, the power domains contain CPU and L2 and GPU only,
>> so devices had their power-domains pointing to the clock controller.
>>
>> On R-Car Gen3, some devices were moved into power domains, so we
>> generalized this by creating a virtual "always-on" power domain, and
>> letting all devices point their power-domains properties to the power
>> domain controller, which forwards clock handling to the clock controller.
>> For consistency, this was applied to R-Car Gen2 as well.
>>
>> Cfr. some late relics fixed in e.g. commit 24b2d930a50662c1
>> ('ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound'),
>> but technically the fix was not needed, as it worked fine without.

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