mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Nayak, Rajendra" <rnayak@codeaurora.org>
To: Jon Hunter <jonathanh@nvidia.com>, Ulf Hansson <ulf.hansson@linaro.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kevin Hilman <khilman@kernel.org>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
Date: Wed, 15 Mar 2017 09:17:04 +0530	[thread overview]
Message-ID: <e91820bc-1f6c-54c2-842e-f226307a8a62@codeaurora.org> (raw)
In-Reply-To: <3e88692d-613b-9c25-2554-7d399c45637a@nvidia.com>

Hey Jon,

>>> 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.
>
> I agree, I think that that would give us the most flexibility to handle
> whatever scenario. However, I was thinking that we could still use the
> genpd core to register pm-domains with and control. My thought was to
> allow devices to have a bindings with multiple pm-domains ...
>
> 	dev-xyz {
> 		...
> 		power-domains = <&domain-a>, <&domain-b>;
> 	};
>
> Then in the genpd core we do having something like ...
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e697dec9d25b..d1ae6ddf4903 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>                                                 "samsung,power-domain", 0);
>                 if (!pd_args.np)
>                         return -ENOENT;
> +       } else if (ret > 1) {
> +               /*
> +                * If there are more than one PM domain defined for a device,
> +                * then these need to be manually controlled by the device
> +                * driver because the genpd core cannot bind a device with
> +                * more than one PM domain.
> +                */
> +               dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
> +               return 0;
>         }
>
> Then add some new public APIs for getting and controlling the pm-domains ...
>
> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>
> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
> void pm_genpd_put(struct generic_pm_domain *pd);
> int pm_genpd_power_on(struct generic_pm_domain *pd);
> int pm_genpd_power_off(struct generic_pm_domain *pd);
> - Power on/off APIs would be synchronous types

These would also need some kind of usecounting I guess, since genpd
otherwise relies on runtime PM to do the usecounting.

This overall seems like a reasonable approach to solve the problem we
have. While we discussed this approach at connect, we thought it would
be a good idea to bring out some RFC on these lines to get the
discussion going. Do you think you would be able to work on some quick 
RFC around these lines, else if you think you would be busy in the near 
term I can help with hacking up the changes as well.

regards,
Rajendra

>
> Are there any potential pitfalls of the above?
>
> Cheers
> Jon
>

  parent reply	other threads:[~2017-03-15  3:47 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 10:28 Jon Hunter
2016-09-20 10:28 ` [RFC PATCH 1/3] PM / Domains: Add helper functions for finding and attaching PM domains Jon Hunter
2016-09-20 10:28 ` [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains Jon Hunter
2016-09-20 17:54   ` Jon Hunter
2016-09-21  8:53   ` Geert Uytterhoeven
2016-09-21 10:01     ` Jon Hunter
2016-09-21 14:37     ` Jon Hunter
2016-09-21 14:57       ` Geert Uytterhoeven
2016-09-23 12:57         ` Jon Hunter
2016-09-23 14:27           ` Geert Uytterhoeven
2016-09-30  8:05             ` Jon Hunter
2016-10-07  9:14   ` Kevin Hilman
2016-10-10 11:24     ` Jon Hunter
2016-09-20 10:28 ` [RFC PATCH 3/3] dt-bindings: Add support for devices with multiple PM domains Jon Hunter
2016-10-06  6:04 ` [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Rajendra Nayak
2016-10-06  8:25   ` Jon Hunter
2016-10-06  8:43     ` Rajendra Nayak
2016-10-31 10:44       ` Jon Hunter
2016-11-02  8:56         ` Rajendra Nayak
2016-11-16 13:11           ` Ulf Hansson
2016-11-17  2:31             ` Rajendra Nayak
2016-11-17 15:39               ` Stanimir Varbanov
2016-11-22 13:05                 ` Ulf Hansson
2016-11-23  3:48                   ` Rajendra Nayak
2016-10-06 12:22 ` Ulf Hansson
2016-10-10 11:18   ` Jon Hunter
2016-10-10 14:04     ` Ulf Hansson
2016-10-11  9:15       ` Jon Hunter
2016-11-03 14:20         ` Jon Hunter
2016-11-16 10:48           ` Jon Hunter
2016-11-16 12:53             ` Rafael J. Wysocki
2016-11-22 11:12               ` Jon Hunter
2016-11-22 13:31                 ` Ulf Hansson
2016-11-22 14:28                   ` Jon Hunter
2016-11-22 18:26                 ` Kevin Hilman
2016-11-22 18:41                   ` Jon Hunter
2016-11-24  2:30                     ` Stephen Boyd
2016-11-29 11:33                       ` Marek Szyprowski
2016-12-15 11:38                         ` Jon Hunter
2016-11-22 21:55                   ` Rafael J. Wysocki
2016-11-23  9:29                     ` Jon Hunter
2016-11-23 13:15                       ` Rafael J. Wysocki
2017-02-28 15:18 ` Jon Hunter
2017-02-28 15:29   ` Geert Uytterhoeven
2017-03-13  9:37     ` Jon Hunter
2017-03-13 11:45       ` Ulf Hansson
2017-03-13 14:09         ` Jon Hunter
2017-03-13 14:19           ` Geert Uytterhoeven
2017-03-13 14:27             ` Jon Hunter
2017-03-13 14:38               ` Geert Uytterhoeven
2017-03-13 14:51                 ` Jon Hunter
2017-03-13 14:42           ` Ulf Hansson
2017-03-15  8:57             ` Jon Hunter
2017-03-15  3:47           ` Nayak, Rajendra [this message]
2017-03-15  9:03             ` Jon Hunter
2017-03-01  6:19   ` Rajendra Nayak

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=e91820bc-1f6c-54c2-842e-f226307a8a62@codeaurora.org \
    --to=rnayak@codeaurora.org \
    --cc=bjorn.andersson@linaro.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

all inboxes | Powered by JetHome®