linux-kernel - Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd

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: <00ba829d-faf4-168c-db00-531621b9280f@codeaurora.org>
Date:   Wed, 23 May 2018 14:57:33 +0530
From:   Rajendra Nayak <rnayak@...eaurora.org>
To:     Jon Hunter <jonathanh@...dia.com>,
        Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux PM <linux-pm@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kevin Hilman <khilman@...nel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Todor Tomov <todor.tomov@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        linux-tegra@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per
 device to genpd



On 05/23/2018 02:37 PM, Jon Hunter wrote:
> 
> On 23/05/18 07:12, Ulf Hansson wrote:
> 
> ...
> 
>>>>>> Thanks for sending this. Believe it or not this has still been on my to-do list
>>>>>> and so we definitely need a solution for Tegra.
>>>>>>
>>>>>> Looking at the above it appears that additional power-domains exposed as devices
>>>>>> to the client device. So I assume that this means that the drivers for devices
>>>>>> with multiple power-domains will need to call RPM APIs for each of these
>>>>>> additional power-domains. Is that correct?
>>>>>
>>>>> They can, but should not!
>>>>>
>>>>> Instead, the driver shall use device_link_add() and device_link_del(),
>>>>> dynamically, depending on what PM domain that their original device
>>>>> needs for the current running use case.
>>>>>
>>>>> In that way, they keep existing runtime PM deployment, operating on
>>>>> its original device.
>>>>
>>>> OK, sounds good. Any reason why the linking cannot be handled by the above API? Is there a use-case where you would not want it linked?
>>>
>>> I am guessing the linking is what would give the driver the ability to decide which subset of powerdomains it actually wants to control
>>> at any point using runtime PM. If we have cases wherein the driver would want to turn on/off _all_ its associated powerdomains _always_
>>> then a default linking of all would help.
>>
>> First, I think we need to decide on *where* the linking should be
>> done, not at both places, as that would just mess up synchronization
>> of who is responsible for calling the device_link_del() at detach.
>>
>> Second, It would in principle be fine to call device_link_add() and
>> device_link_del() as a part of the attach/detach APIs. However, there
>> is a downside to such solution, which would be that the driver then
>> needs call the detach API, just to do device_link_del(). Of course
>> then it would also needs to call the attach API later if/when needed.
>> Doing this adds unnecessary overhead - comparing to just let the
>> driver call device_link_add|del() when needed. On the upside, yes, it
>> would put less burden on the drivers as it then only needs to care
>> about using one set of functions.
>>
>> Which solution do you prefer?
> 
> Any reason why we could not add a 'boolean' argument to the API to indicate whether the new device should be linked? I think that I prefer the API handles it, but I can see there could be instances where drivers may wish to handle it themselves.
> 
> Rajendra, do you have a use-case right now where the driver would want to handle the linking?

So if I understand this right, any driver which does want to control individual powerdomain state would
need to do the linking itself right?

What I am saying is, if I have device A, with powerdomains X and Y, and if I want to turn on only X,
then I would want only X to be linked with A, and at a later point if I want both X and Y to be turned on,
I would then go ahead and link both X and Y to A? Is that correct or did I get it all wrong?

I know atleast Camera on msm8996 would need to do this since it has 2 vfe powerdoamins, which can be
turned on one at a time (depending on what resolution needs to be supported) or both together if we
really need very high resolution using both vfe modules. 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation