linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Kevin Hilman <khilman@kernel.org>,
	ssantosh@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-pm@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	grant.likely@secretlab.ca, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains
Date: Wed, 19 Nov 2014 14:47:25 +0100	[thread overview]
Message-ID: <2900095.WIocOu7ue2@wuerfel> (raw)
In-Reply-To: <546C7FDD.7030906@ti.com>

On Wednesday 19 November 2014 13:32:45 Grygorii Strashko wrote:
> On 11/18/2014 09:32 PM, Arnd Bergmann wrote:
> > On Tuesday 18 November 2014 20:54:36 Grygorii Strashko wrote:
> > 
> > Have one pmdomain driver in the generic code that knows about clocks,
> > possibly also regulators and pins and just turns them on when needed.
> > You can have a "simple-pmdomain" or "generic-pmdomain" compatible
> > string.
> > 
> > I'm a bit surprised that your pmdomain code looks up the clocks from the
> > respective device, rather than know about the clocks itself. There is
> > probably a good reason for this, but I don't see it yet.
> 
> The keystone 2 uses simple PM schema based on clocks only:
> - clocks enabled -> dev is active
> - clocks disabled -> dev is suspended
> 
> To achieve explained above the Generic clock manipulation PM callbacks framework (pm_clk) is used.
> - list of managed clocks is filled for each device (for non-DT case the con_id list
>   is specified by platform code like:
> 	.con_ids = { "fck", "master", "slave", NULL }, 
>         - or - 
> 	.con_ids = { }, <-- in this case only first clock will be added to pm_clk
>   )
> - dev.pm_domain is assigned to pm_clk_domain
> - pm_clk_domain has .runtime_resume/runtime_suspend callbacks set and implemented like:
>   static int keystone_pm_runtime_suspend(struct device *dev)
>   {
> 	ret = pm_generic_runtime_suspend(dev);
> 	if (ret)
> 		return ret;
> 
> 	ret = pm_clk_suspend(dev);
> 	if (ret) {
> 		pm_generic_runtime_resume(dev);
> 		return ret;
> 	}
> 
> 	return 0;
>   }
>   static int keystone_pm_runtime_resume(struct device *dev)
>   {
> 	pm_clk_resume(dev);
> 
> 	return pm_generic_runtime_resume(dev);
>   }
> Now this configuration can be done from Platform Bus notifier (clock_ops.c) only and It'll
> be done for ALL Platform devices and, once above steps have been done, the Runtime PM
> starts working for device.
> 
> As was described early in this thread, Keystone 2 PM domain is glue layer which
> allows:
>  - configure pm_clk for devices from DT and get rid of .con_ids
>  - configure only selected devices
>  - get rid of using Platform Bus notifier
>  - enable suspend/resume for devices as side effect :)
> and which manages state of its devices through dev_ops->start()/stop() callbacks. 

Right, that makes a lot more sense now, thanks for the detailed explanation!

> > Another option would be to have a special case for an empty
> > "power-domains" property if this is the most common case: if that
> > property exists but is empty, the pmdomain core could interpret
> > it as an indication to control all the clocks/regulators/pins
> > of a device.
> 
> I can try to do the following:
> - move Keystone PM domain code in drivers/base/power/simple_domain.c
> - add DT bindings like:
> +	clk_pmdomain: simple-clk-pmdomain {
> +		compatible = "simple-clk-pmdomain", "simple-pmdomain";
> +		#power-domain-cells = <0>;
> +	};
> - in case if compatible == "simple-clk-pmdomain" it will do the same sings as in this patch
> 
> In the future, additional support for regulators/clocks/gpios can be added and these resources
> can be managed in .power_on/power_off.
> 
> Is it ok for you?

Yes, it would definitely solve the problem that I see with the infrastructure
code that the current version adds into the platform directory.

The exact binding of course should be reviewed by the pmdomain and
DT maintainers, to ensure that it is done the best possible way, because
I assume we will end up using it a lot, and it would be a shame to get
it slightly wrong.

One possible variation I can think of would be to just use "simple-pmdomain"
as the compatible string, and use properties in the node itself to decide
what the domain should control, e.g.

	clk_pmdomain: pmdomain {
		compatible = "simple-pmdomain";
		pmdomain-enable-clocks;
		#power-domain-cells = <0>;
	};
	clk_regulator_pmdomain: pmdomain {
		compatible = "simple-pmdomain";
		pmdomain-enable-clocks;
		pmdomain-enable-regulators;
		#power-domain-cells = <0>;
	};

and then have each device link to one of the nodes as the pmdomain.

	Arnd

  reply	other threads:[~2014-11-19 13:48 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10 14:59 [PATCH v4 0/2] ARM: keystone: pm: switch to use generic pm domains Grygorii Strashko
2014-11-10 14:59 ` [PATCH v4 1/2] " Grygorii Strashko
2014-11-10 15:06   ` Arnd Bergmann
2014-11-10 17:38     ` Grygorii Strashko
2014-11-10 20:36       ` Arnd Bergmann
2014-11-17 19:14         ` Kevin Hilman
2014-11-17 20:37           ` Arnd Bergmann
2014-11-17 21:50             ` Kevin Hilman
2014-11-18 18:54               ` Grygorii Strashko
2014-11-18 19:32                 ` Arnd Bergmann
2014-11-19 11:32                   ` Grygorii Strashko
2014-11-19 13:47                     ` Arnd Bergmann [this message]
2014-11-20 11:34                       ` Ulf Hansson
2014-11-20 12:03                         ` Grygorii Strashko
2014-11-20 13:12                           ` Ulf Hansson
2014-11-20 13:32                             ` Geert Uytterhoeven
2014-11-20 15:32                               ` Grygorii Strashko
2014-11-20 20:22                                 ` Kevin Hilman
2014-11-20 20:26                                   ` Geert Uytterhoeven
2014-11-20 21:48                                     ` Kevin Hilman
2014-11-20 21:54                                       ` Geert Uytterhoeven
2014-11-21  1:30                                         ` Kevin Hilman
2014-11-21  8:06                                           ` Geert Uytterhoeven
2014-11-21 18:58                                             ` Grygorii Strashko
2014-11-21 19:29                                               ` Kevin Hilman
2014-11-21 20:14                                                 ` Grygorii Strashko
2014-11-24 10:50                                               ` Arnd Bergmann
2014-11-25  6:44                                                 ` Mike Turquette
2014-11-25 10:33                                                   ` Arnd Bergmann
2014-11-25 11:08                                                     ` Grygorii Strashko
2014-11-25 12:09                                                       ` Arnd Bergmann
2014-11-25 13:30                                                         ` Grygorii Strashko
2014-11-25 14:04                                                           ` Russell King - ARM Linux
2014-11-25 14:53                                                             ` Grygorii Strashko
2014-11-25 16:28                                                               ` santosh shilimkar
2014-11-21 19:20                                             ` Kevin Hilman
2014-11-21  9:04                                 ` Geert Uytterhoeven
2014-11-18  2:18             ` santosh.shilimkar
2014-11-10 14:59 ` [PATCH v4 2/2] ARM: dts: keystone: add generic pm controller node Grygorii Strashko
2014-11-10 15:13 ` [PATCH v4 0/2] ARM: keystone: pm: switch to use generic pm domains Grygorii Strashko
2014-11-10 18:51   ` santosh.shilimkar

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=2900095.WIocOu7ue2@wuerfel \
    --to=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=grant.likely@secretlab.ca \
    --cc=grygorii.strashko@ti.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=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=ssantosh@kernel.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).