[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 3 Mar 2014 11:54:26 +0800
From: Mark Brown <broonie@...nel.org>
To: Nishanth Menon <nm@...com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>,
MyungJoo Ham <myungjoo.ham@...sung.com>,
Mike Turquette <mturquette@...aro.org>,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-omap@...r.kernel.org
Subject: Re: [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain
driver support
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
> Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
> platforms such as TI's OMAP derivatives, and other SoCs which differ
> only by the sequence involved in voltage scale operations. So, this
> patch provides a framework for registering the underlying
> implementation of the SoC specific voltage change methodology.
That bit is clear, what's very opaque from the code is how this is going
to be accomplished.
> Overall the sequence takes place after this patch is as follows:
> a) voltage domain drivers such as those of TI or others register with
> voltage domain with devm_voltdm_register.
> b) cpufreq-cpu0/devfreq drivers:
> of_pm_voltdm_notifier_register(introduced as part of patch #1) to
> register notifiers around clk of interest. This request is linked to
> the specific voltage domain using phandle in device tree.
> c) when cpufreq-cpu0/devfreq does a clk_set_rate, the common clock
> framework triggers notifiers in voltage domain core which in turn,
> invokes the corresponding handlers for the voltage domain driver
> ensuring the right dvfs sequence specific to the SoC is triggered.
So the first question I have here is what happens if multiple clocks
need to be updated in lock step - if we're only triggering off clock
notifiers that seems tricky. The other thing here is that the fact that
your API is "of_" suggests that it is in fact linked very srongly to DT
- it'd be good to split out the layers to make sure things make sense
standalone, the DT helpers are obviously good but the API should be able
to stand separately.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists