All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kevin Hilman <khilman@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
Date: Wed, 10 Feb 2016 18:01:24 +0000	[thread overview]
Message-ID: <56BB7AF4.8040708@nvidia.com> (raw)
In-Reply-To: <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>


On 04/02/16 15:44, Ulf Hansson wrote:
> On 28 January 2016 at 17:33, Jon Hunter <jonathanh@nvidia.com> wrote:
>> Adds generic PM support to the PMC driver where the PM domains are
>> populated from device-tree and the PM domain consumer devices are
>> bound to their relevant PM domains via device-tree as well.
>>
>> Update the tegra_powergate_sequence_power_up() API so that internally
>> it calls the same tegra_powergate_xxx functions that are used by the
>> tegra generic power domain code for consistency.
>>
>> This is based upon work by Thierry Reding <treding@nvidia.com>
>> and Vince Hsu <vinceh@nvidia.com>.
>>
>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>> ---
>>  drivers/soc/tegra/pmc.c                     | 470 ++++++++++++++++++++++++++--
>>  include/dt-bindings/power/tegra-powergate.h |  36 +++
>>  include/soc/tegra/pmc.h                     |  39 +--
> 
> I suggest you split the header changes into a separate patch.
> 
> Moreover, these new DT definitions should be documented in the patch
> describing the new powergate DT bindings. At least a simple list
> providing the available options.

Ok.

> [...]
> 
>>
>> +static void tegra_powergate_disable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +
>> +       for (i = 0; i < pg->num_clks; i++)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +}
>> +
>> +static int tegra_powergate_enable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +       int err;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               err = clk_prepare_enable(pg->clks[i]);
>> +               if (err)
>> +                       goto out;
>> +       }
>> +
>> +       return 0;
>> +
>> +out:
>> +       while (i--)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +
>> +       return err;
>> +}
> 
> I have seen similar code around in other PM domains, dealing with
> enabling/disabling a *list* of clocks.
> Perhaps we should invent a new clock API that helps with this to
> prevents code duplication!?

Yes, I have been thinking about that as well. I will have a look at that.

> [...]
> 
>>  /**
>>   * tegra_powergate_power_on() - power on partition
>>   * @id: partition ID
>> @@ -319,35 +512,20 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>>  int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
>>                                       struct reset_control *rst)
> 
> There seems to be two viable ways for a driver to control tegra powergates.
> 
> 1)
> $Subject patch enables the use of runtime PM.
> 
> 2)
> The current tegra_powergate_sequence_power_up() and
> tegra_powergate_power_off() API.
> 
> It seems fragile to allow both options, but perhaps your are
> protecting this with some lock to prevent concurrent accesses?

There is a lock protecting accesses to the PMC registers which
ultimately control the power domain. However, may be it would be better
to ensure that any power-domain registered with genpd cannot be
controlled by the legacy APIs. I have added a bitmap to mark valid
power-domains to ensure that only valid power domains can be controlled
by these legacy APIs. I could mark the power-domain invalid after
registering with genpd to ensure that it cannot be accessed by the
legacy APIs.

> Also, I assume you need the two options in a transition phase, before
> you have deployed runtime PM for these drivers?

Right and some of the legacy APIs are entrenched in some drivers. So to
keep the patch set manageable it seems best to get some support in place
then start migrating the drivers.

> [...]
> 
>> +static int tegra_powergate_of_get_clks(struct device *dev,
>> +                                      struct tegra_powergate *pg)
>> +{
>> +       struct clk *clk;
>> +       unsigned int i;
>> +       int err;
>> +
>> +       pg->num_clks = of_count_phandle_with_args(pg->of_node, "clocks",
>> +                                                 "#clock-cells");
>> +       if (pg->num_clks == 0)
>> +               return -ENODEV;
>> +
>> +       pg->clks = devm_kcalloc(dev, pg->num_clks, sizeof(clk), GFP_KERNEL);
>> +       if (!pg->clks)
>> +               return -ENOMEM;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               pg->clks[i] = of_clk_get(pg->of_node, i);
>> +               if (IS_ERR(pg->clks[i])) {
>> +                       err = PTR_ERR(pg->clks[i]);
>> +                       goto err;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +err:
>> +       while (i--)
>> +               clk_put(pg->clks[i]);
>> +
>> +       pg->num_clks = 0;
>> +
>> +       return err;
>> +}
> 
> Fetching clocks like above function does, seems to be a quite common case.
> 
> As I suggested to add an enable/disable API for a clock list, the
> similar can be done for creating the clock list.
> 
> Just an idea...

Ok.

> [...]
> 
>> +
>> +static void tegra_powergate_remove(struct tegra_pmc *pmc)
>> +{
>> +       struct tegra_powergate *pg, *n;
>> +
>> +       list_for_each_entry_safe(pg, n, &pmc->powergates_list, node) {
> 
> The tegra powergate driver will hold a list of nvidia powergates
> domains, and the generic PM domain will hold a list of all generic PM
> domains.
> 
> Perhaps there's a way to allow the generic PM domain to control this
> by itself. If we for example used the struct device corresponding to
> the powergate driver, genpd could use it to distinguish between
> various instances of genpd structs..!? Maybe it would simplify the way
> to deal with removing domains?

Yes, that would be ideal. However, would have require changing
genpd_init()? I am not sure how genpd would be able to access the device
struct for the powergate driver because we don't provide this via any
API I am aware of? And I am guessing that you don't wish to expose the
gpd_list to the world either.

If there is an easy way, I am open to it, but looking at it today, I am
not sure I see a simple way in which we could add a new API to do this.
However, may be I am missing something!

Cheers
Jon


WARNING: multiple messages have this Message-ID (diff)
From: jonathanh@nvidia.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
Date: Wed, 10 Feb 2016 18:01:24 +0000	[thread overview]
Message-ID: <56BB7AF4.8040708@nvidia.com> (raw)
In-Reply-To: <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>


On 04/02/16 15:44, Ulf Hansson wrote:
> On 28 January 2016 at 17:33, Jon Hunter <jonathanh@nvidia.com> wrote:
>> Adds generic PM support to the PMC driver where the PM domains are
>> populated from device-tree and the PM domain consumer devices are
>> bound to their relevant PM domains via device-tree as well.
>>
>> Update the tegra_powergate_sequence_power_up() API so that internally
>> it calls the same tegra_powergate_xxx functions that are used by the
>> tegra generic power domain code for consistency.
>>
>> This is based upon work by Thierry Reding <treding@nvidia.com>
>> and Vince Hsu <vinceh@nvidia.com>.
>>
>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>> ---
>>  drivers/soc/tegra/pmc.c                     | 470 ++++++++++++++++++++++++++--
>>  include/dt-bindings/power/tegra-powergate.h |  36 +++
>>  include/soc/tegra/pmc.h                     |  39 +--
> 
> I suggest you split the header changes into a separate patch.
> 
> Moreover, these new DT definitions should be documented in the patch
> describing the new powergate DT bindings. At least a simple list
> providing the available options.

Ok.

> [...]
> 
>>
>> +static void tegra_powergate_disable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +
>> +       for (i = 0; i < pg->num_clks; i++)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +}
>> +
>> +static int tegra_powergate_enable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +       int err;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               err = clk_prepare_enable(pg->clks[i]);
>> +               if (err)
>> +                       goto out;
>> +       }
>> +
>> +       return 0;
>> +
>> +out:
>> +       while (i--)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +
>> +       return err;
>> +}
> 
> I have seen similar code around in other PM domains, dealing with
> enabling/disabling a *list* of clocks.
> Perhaps we should invent a new clock API that helps with this to
> prevents code duplication!?

Yes, I have been thinking about that as well. I will have a look at that.

> [...]
> 
>>  /**
>>   * tegra_powergate_power_on() - power on partition
>>   * @id: partition ID
>> @@ -319,35 +512,20 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>>  int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
>>                                       struct reset_control *rst)
> 
> There seems to be two viable ways for a driver to control tegra powergates.
> 
> 1)
> $Subject patch enables the use of runtime PM.
> 
> 2)
> The current tegra_powergate_sequence_power_up() and
> tegra_powergate_power_off() API.
> 
> It seems fragile to allow both options, but perhaps your are
> protecting this with some lock to prevent concurrent accesses?

There is a lock protecting accesses to the PMC registers which
ultimately control the power domain. However, may be it would be better
to ensure that any power-domain registered with genpd cannot be
controlled by the legacy APIs. I have added a bitmap to mark valid
power-domains to ensure that only valid power domains can be controlled
by these legacy APIs. I could mark the power-domain invalid after
registering with genpd to ensure that it cannot be accessed by the
legacy APIs.

> Also, I assume you need the two options in a transition phase, before
> you have deployed runtime PM for these drivers?

Right and some of the legacy APIs are entrenched in some drivers. So to
keep the patch set manageable it seems best to get some support in place
then start migrating the drivers.

> [...]
> 
>> +static int tegra_powergate_of_get_clks(struct device *dev,
>> +                                      struct tegra_powergate *pg)
>> +{
>> +       struct clk *clk;
>> +       unsigned int i;
>> +       int err;
>> +
>> +       pg->num_clks = of_count_phandle_with_args(pg->of_node, "clocks",
>> +                                                 "#clock-cells");
>> +       if (pg->num_clks == 0)
>> +               return -ENODEV;
>> +
>> +       pg->clks = devm_kcalloc(dev, pg->num_clks, sizeof(clk), GFP_KERNEL);
>> +       if (!pg->clks)
>> +               return -ENOMEM;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               pg->clks[i] = of_clk_get(pg->of_node, i);
>> +               if (IS_ERR(pg->clks[i])) {
>> +                       err = PTR_ERR(pg->clks[i]);
>> +                       goto err;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +err:
>> +       while (i--)
>> +               clk_put(pg->clks[i]);
>> +
>> +       pg->num_clks = 0;
>> +
>> +       return err;
>> +}
> 
> Fetching clocks like above function does, seems to be a quite common case.
> 
> As I suggested to add an enable/disable API for a clock list, the
> similar can be done for creating the clock list.
> 
> Just an idea...

Ok.

> [...]
> 
>> +
>> +static void tegra_powergate_remove(struct tegra_pmc *pmc)
>> +{
>> +       struct tegra_powergate *pg, *n;
>> +
>> +       list_for_each_entry_safe(pg, n, &pmc->powergates_list, node) {
> 
> The tegra powergate driver will hold a list of nvidia powergates
> domains, and the generic PM domain will hold a list of all generic PM
> domains.
> 
> Perhaps there's a way to allow the generic PM domain to control this
> by itself. If we for example used the struct device corresponding to
> the powergate driver, genpd could use it to distinguish between
> various instances of genpd structs..!? Maybe it would simplify the way
> to deal with removing domains?

Yes, that would be ideal. However, would have require changing
genpd_init()? I am not sure how genpd would be able to access the device
struct for the powergate driver because we don't provide this via any
API I am aware of? And I am guessing that you don't wish to expose the
gpd_list to the world either.

If there is an easy way, I am open to it, but looking at it today, I am
not sure I see a simple way in which we could add a new API to do this.
However, may be I am missing something!

Cheers
Jon

  reply	other threads:[~2016-02-10 18:01 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 16:33 [PATCH V5 00/14] Add generic PM domain support for Tegra Jon Hunter
2016-01-28 16:33 ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 02/14] soc: tegra: pmc: Protect public functions from potential race conditions Jon Hunter
2016-01-28 16:33   ` Jon Hunter
2016-01-29 16:20   ` Mathieu Poirier
2016-01-29 16:20     ` Mathieu Poirier
2016-02-01 13:42     ` Jon Hunter
2016-02-01 13:42       ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 03/14] soc: tegra: pmc: Change powergate and rail IDs to be an unsigned type Jon Hunter
2016-01-28 16:33   ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 04/14] soc: tegra: pmc: Fix testing of powergate state Jon Hunter
2016-01-28 16:33   ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 07/14] soc: tegra: pmc: Ensure partitions can be toggled on/off by PMC Jon Hunter
2016-01-28 16:33   ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 08/14] PM / Domains: Add function to remove a pm-domain Jon Hunter
2016-01-28 16:33   ` Jon Hunter
     [not found]   ` <1453998832-27383-9-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-02 15:35     ` Ulf Hansson
2016-02-02 15:35       ` Ulf Hansson
     [not found]       ` <CAPDyKFqJLdoee4a9819XukXTmYyd3pue452K_zbiV6XhfA=fTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-03 10:51         ` Jon Hunter
2016-02-03 10:51           ` Jon Hunter
     [not found] ` <1453998832-27383-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-28 16:33   ` [PATCH V5 01/14] soc: tegra: pmc: Restore base address on probe failure Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-01-28 16:33   ` [PATCH V5 05/14] soc: tegra: pmc: Wait for powergate state to change Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-01-29 16:58     ` Mathieu Poirier
2016-01-29 16:58       ` Mathieu Poirier
     [not found]       ` <CANLsYkycbEo+wyMX8RJ9H-S5kDTjQR4nnDZc5gvf2kShOZAv9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-01 13:44         ` Jon Hunter
2016-02-01 13:44           ` Jon Hunter
     [not found]           ` <56AF613A.1000909-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-03  9:20             ` Jon Hunter
2016-02-03  9:20               ` Jon Hunter
     [not found]               ` <56B1C647.4060504-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-03 15:58                 ` Mathieu Poirier
2016-02-03 15:58                   ` Mathieu Poirier
2016-01-28 16:33   ` [PATCH V5 06/14] soc: tegra: pmc: Fix checking of valid partitions Jon Hunter
2016-01-28 16:33     ` Jon Hunter
     [not found]     ` <1453998832-27383-7-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-29 17:08       ` Mathieu Poirier
2016-01-29 17:08         ` Mathieu Poirier
     [not found]         ` <CANLsYkxY5P2wQxGev0veN39nD-1cTVkZCVpX9jca7da39JJpWg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-01 13:45           ` Jon Hunter
2016-02-01 13:45             ` Jon Hunter
2016-01-28 16:33   ` [PATCH V5 09/14] Documentation: DT: bindings: Update NVIDIA PMC for Tegra Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-01-29 16:08     ` Rob Herring
2016-01-29 16:08       ` Rob Herring
2016-01-28 16:33   ` [PATCH V5 10/14] Documentation: DT: bindings: Add power domain info for NVIDIA PMC Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-01-29 16:06     ` Rob Herring
2016-01-29 16:06       ` Rob Herring
2016-02-03 11:02       ` Jon Hunter
2016-02-03 11:02         ` Jon Hunter
     [not found]         ` <56B1DE40.7080403-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-03 15:48           ` Rob Herring
2016-02-03 15:48             ` Rob Herring
     [not found]             ` <CAL_JsqLcoKW2znNNvM=sYLmZ6O6ZWqn7+aXspkXoONw6-O1ygg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-10 10:57               ` Jon Hunter
2016-02-10 10:57                 ` Jon Hunter
     [not found]                 ` <56BB1787.4050801-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-10 14:06                   ` Rob Herring
2016-02-10 14:06                     ` Rob Herring
2016-01-28 16:33   ` [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-02-04 15:44     ` Ulf Hansson
2016-02-04 15:44       ` Ulf Hansson
2016-02-10 18:01       ` Jon Hunter [this message]
2016-02-10 18:01         ` Jon Hunter
     [not found]         ` <56BB7AF4.8040708-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-10 18:25           ` Ulf Hansson
2016-02-10 18:25             ` Ulf Hansson
     [not found]             ` <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-11  9:13               ` Jon Hunter
2016-02-11  9:13                 ` Jon Hunter
2016-02-11  9:57                 ` Ulf Hansson
2016-02-11  9:57                   ` Ulf Hansson
     [not found]                   ` <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-11 10:13                     ` Jon Hunter
2016-02-11 10:13                       ` Jon Hunter
     [not found]                       ` <56BC5EE0.2040804-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-11 10:26                         ` Jon Hunter
2016-02-11 10:26                           ` Jon Hunter
2016-02-11 10:37                           ` Ulf Hansson
2016-02-11 10:37                             ` Ulf Hansson
2016-02-11 10:52                             ` Jon Hunter
2016-02-11 10:52                               ` Jon Hunter
2016-02-11 10:28                       ` Ulf Hansson
2016-02-11 10:28                         ` Ulf Hansson
     [not found]                         ` <CAPDyKFq_0t4tcvkgMBW8p8ubJDALWMjdhgGM+_Z6auRxEkSPdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-11 16:38                           ` Jon Hunter
2016-02-11 16:38                             ` Jon Hunter
     [not found]                             ` <56BCB90C.8000302-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-18 15:06                               ` Ulf Hansson
2016-02-18 15:06                                 ` Ulf Hansson
2016-02-12 23:14       ` Kevin Hilman
2016-02-12 23:14         ` Kevin Hilman
     [not found]         ` <7hh9hdzflv.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-02-15 11:27           ` Jon Hunter
2016-02-15 11:27             ` Jon Hunter
     [not found]             ` <56C1B62B.5060708-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-18 16:00               ` Ulf Hansson
2016-02-18 16:00                 ` Ulf Hansson
     [not found]                 ` <CAPDyKFoPrFoMOFxC37zXX4L3VdLKknaw_LUTw7ycr9mfa_=7_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-18 16:31                   ` Jon Hunter
2016-02-18 16:31                     ` Jon Hunter
2016-02-24  0:03                     ` Kevin Hilman
2016-02-24  0:03                       ` Kevin Hilman
2016-01-28 16:33   ` [PATCH V5 12/14] clk: tegra210: Add the APB2APE audio clock Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-02-02 14:37     ` Thierry Reding
2016-02-02 14:37       ` Thierry Reding
2016-01-28 16:33   ` [PATCH V5 13/14] ARM64: tegra: Add audio PM domain device node for Tegra210 Jon Hunter
2016-01-28 16:33     ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 14/14] ARM64: tegra: select PM_GENERIC_DOMAINS Jon Hunter
2016-01-28 16:33   ` Jon Hunter

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=56BB7AF4.8040708@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gnurou@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.