From: Rajendra Nayak <rnayak@codeaurora.org>
To: Jon Hunter <jonathanh@nvidia.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Kevin Hilman <khilman@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
geert@linux-m68k.org
Cc: stanimir.varbanov@linaro.org, sboyd@codeaurora.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
Date: Mon, 10 Apr 2017 15:32:32 +0530 [thread overview]
Message-ID: <673fbd2f-3fcb-453b-be84-668ce659abb4@codeaurora.org> (raw)
In-Reply-To: <3135e238-48a3-3693-bb59-63bf2a6d8d0e@nvidia.com>
On 04/10/2017 01:54 PM, Jon Hunter wrote:
>
> On 10/04/17 05:09, Rajendra Nayak wrote:
>> Hey Jon,
>>
>> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>>> The current generic PM domain framework (GenDP) only allows a single
>>> PM domain to be associated with a given device. There are several
>>> use-cases for various system-on-chip devices where it is necessary for
>>> a PM domain consumer to control more than one PM domain where the PM
>>> domains:
>>> i). Do not conform to a parent-child relationship so are not nested
>>> ii). May not be powered on and off at the same time so need independent
>>> control.
>>>
>>> To support the above, add new APIs for GenPD to allow consumers to get,
>>> power-on, power-off and put PM domains so that they can be explicitly
>>> controlled by the consumer.
>>
>> thanks for working on this RFC.
>>
>> []..
>>
>>> +/**
>>> + * pm_genpd_get - Get a generic I/O PM domain by name
>>> + * @name: Name of the PM domain.
>>> + *
>>> + * Look-ups a PM domain by name. If found, increment the device
>>> + * count for PM domain to ensure that the PM domain cannot be
>>> + * removed, increment the suspended count so that it can still
>>> + * be turned off (when not in-use) and return a pointer to its
>>> + * generic_pm_domain structure. If not found return ERR_PTR().
>>> + */
>>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>>> +{
>>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>>> +
>>> + if (!name)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + mutex_lock(&gpd_list_lock);
>>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>>> + if (!strcmp(gpd->name, name)) {
Also looking up the powerdomain this way means the consumers need
to know the _exact_ name with which the providers have registered
the powerdomains?
>>> + genpd_lock(gpd);
>>> + gpd->device_count++;
>>
>> There apis' should also take a device pointer as a parameter,
>> so we can track all the devices belonging to a powerdomain.
>> That would also mean keeping the genpd->dev_list updated instead of
>> only incrementing the device_count here.
>
> I had contemplated that and I am happy to do that if that is what the
> consensus wants. However, my only reservation about doing that was it
> only allows devices to call the APIs, but maybe that is ok. I was trying
> to keep it similar to the clk and regulator APIs.
>
>>> + gpd->suspended_count++;
>>> + genpd_unlock(gpd);
>>> + genpd = gpd;
>>> + break;
>>> + }
>>> + }
>>> + mutex_unlock(&gpd_list_lock);
>>> +
>>> + return genpd;
>>
>> Instead of returning a pointer to generic_pm_domain to all
>> consumers (who are then free to poke around it) we should hide
>> all internal structures handled by the framework and only expose
>> some kind of a handle to all the consumers.
>> That would also mean having a clear split of the headers to
>> distinguish between what's accessible to consumers vs providers.
>
> OK, I will take a look at that.
>
> Cheers
> Jon
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2017-04-10 10:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-28 14:13 [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains Jon Hunter
2017-03-28 14:14 ` [RFC PATCH 1/4] PM / Domains: Prepare for supporting explicit PM domain control Jon Hunter
2017-03-28 14:14 ` [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains Jon Hunter
2017-04-10 4:09 ` Rajendra Nayak
2017-04-10 8:24 ` Jon Hunter
2017-04-10 10:02 ` Rajendra Nayak [this message]
2017-04-10 19:48 ` Jon Hunter
2017-03-28 14:14 ` [RFC PATCH 3/4] PM / Domains: Add OF helpers for getting " Jon Hunter
2017-03-28 14:14 ` [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple " Jon Hunter
2017-04-10 4:12 ` Rajendra Nayak
2017-04-10 8:24 ` Jon Hunter
2017-04-25 11:13 ` [RFC PATCH 0/4] PM / Domains: Add support for explicit control of " Jon Hunter
2017-04-25 19:34 ` Ulf Hansson
2017-04-25 21:17 ` Rafael J. Wysocki
2017-05-02 10:10 ` Jon Hunter
2017-05-02 21:51 ` Rafael J. Wysocki
2017-05-03 8:12 ` Ulf Hansson
2017-05-03 8:32 ` Jon Hunter
2017-05-03 13:43 ` Ulf Hansson
2017-05-03 14:57 ` Jon Hunter
2017-05-03 17:12 ` Ulf Hansson
2017-05-04 8:44 ` Jon Hunter
2017-05-30 3:41 ` Rajendra Nayak
2017-10-09 16:36 ` Todor Tomov
2017-10-10 9:13 ` Jon Hunter
2017-05-03 8:12 ` Jon Hunter
2017-04-26 8:06 ` Geert Uytterhoeven
2017-04-26 9:04 ` Ulf Hansson
2017-04-26 9:17 ` Geert Uytterhoeven
2017-04-26 9:55 ` Ulf Hansson
2017-05-03 6:43 ` Geert Uytterhoeven
2017-05-03 8:54 ` Geert Uytterhoeven
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=673fbd2f-3fcb-453b-be84-668ce659abb4@codeaurora.org \
--to=rnayak@codeaurora.org \
--cc=geert@linux-m68k.org \
--cc=jonathanh@nvidia.com \
--cc=khilman@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.org \
--cc=stanimir.varbanov@linaro.org \
--cc=ulf.hansson@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).