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
next prev parent 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: linkBe 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.