From: Ulf Hansson <ulf.hansson@linaro.org>
To: Rajendra Nayak <rnayak@codeaurora.org>,
Jon Hunter <jonathanh@nvidia.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
Linux PM <linux-pm@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kevin Hilman <khilman@kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Todor Tomov <todor.tomov@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-tegra@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd
Date: Wed, 23 May 2018 11:33:50 +0200 [thread overview]
Message-ID: <CAPDyKFoqLPRwEJ9b+XBpB4Zy79SGEC-a8V8shNhMkYOCQa0=oA@mail.gmail.com> (raw)
In-Reply-To: <00ba829d-faf4-168c-db00-531621b9280f@codeaurora.org>
On 23 May 2018 at 11:27, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
>
> 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?
Correct!
>
> 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.
I think this is also the case for the Tegra XUSB subsystem.
The usb device is always attached to one PM domain, but depending on
if super-speed mode is used, another PM domain for that logic needs to
be powered on as well.
Jon, please correct me if I am wrong!
Kind regards
Uffe
next prev parent reply other threads:[~2018-05-23 9:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 10:31 [PATCH 0/9] PM / Domains: Add support for multi PM domains per device Ulf Hansson
2018-05-18 10:31 ` [PATCH 1/9] PM / Domains: Drop extern declarations of functions in pm_domain.h Ulf Hansson
2018-05-18 10:31 ` [PATCH 2/9] PM / Domains: Drop __pm_genpd_add_device() Ulf Hansson
2018-05-18 10:31 ` [PATCH 3/9] PM / Domains: Drop genpd as in-param for pm_genpd_remove_device() Ulf Hansson
2018-05-18 10:31 ` [PATCH 4/9] PM / Domains: Drop unused parameter in genpd_allocate_dev_data() Ulf Hansson
2018-05-18 10:31 ` [PATCH 5/9] PM / Domains: dt: Allow power-domain property to be a list of phandles Ulf Hansson
2018-05-18 10:46 ` Geert Uytterhoeven
2018-05-18 10:31 ` [PATCH 6/9] PM / Domains: Don't attach devices in genpd with multi PM domains Ulf Hansson
2018-05-18 10:31 ` [PATCH 7/9] PM / Domains: Split genpd_dev_pm_attach() Ulf Hansson
2018-05-18 10:31 ` [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd Ulf Hansson
2018-05-22 14:31 ` Jon Hunter
2018-05-22 14:47 ` Ulf Hansson
2018-05-22 20:55 ` Jon Hunter
2018-05-23 4:51 ` Rajendra Nayak
2018-05-23 6:12 ` Ulf Hansson
2018-05-23 9:07 ` Jon Hunter
2018-05-23 9:27 ` Rajendra Nayak
2018-05-23 9:33 ` Ulf Hansson [this message]
2018-05-23 9:45 ` Jon Hunter
2018-05-23 9:47 ` Ulf Hansson
2018-05-23 10:22 ` Jon Hunter
2018-05-24 7:04 ` Ulf Hansson
2018-05-24 9:36 ` Jon Hunter
2018-05-24 12:17 ` Ulf Hansson
2018-05-24 14:34 ` Jon Hunter
2018-05-24 21:21 ` Ulf Hansson
2018-05-25 8:22 ` Jon Hunter
2018-05-18 10:31 ` [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains Ulf Hansson
2018-05-24 15:48 ` Jon Hunter
2018-05-24 21:11 ` Ulf Hansson
2018-05-25 8:31 ` Jon Hunter
2018-05-25 10:45 ` Ulf Hansson
2018-05-25 11:07 ` Jon Hunter
2018-05-25 12:34 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPDyKFoqLPRwEJ9b+XBpB4Zy79SGEC-a8V8shNhMkYOCQa0=oA@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rnayak@codeaurora.org \
--cc=todor.tomov@linaro.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).