From: Sudeep Holla <sudeep.holla@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
"rob.herring@linaro.org" <rob.herring@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Santosh Shilimkar <santosh.shilimkar@oracle.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
Mike Turquette <mike.turquette@linaro.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"kesavan.abhilash@gmail.com" <kesavan.abhilash@gmail.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"k.chander@samsung.com" <k.chander@samsung.com>,
"olof@lixom.net" <olof@lixom.net>,
"ta.omasab@gmail.com" <ta.omasab@gmail.com>
Subject: Re: [RFC] cpufreq: Add "dvfs-method" binding to probe cpufreq drivers
Date: Wed, 26 Nov 2014 17:00:11 +0000 [thread overview]
Message-ID: <5476071B.1060705@arm.com> (raw)
In-Reply-To: <596a6d49f2b3e2837aa9a54a3e1249161d3c9265.1416991009.git.viresh.kumar@linaro.org>
Hi Viresh,
On 26/11/14 08:46, Viresh Kumar wrote:
> DT based cpufreq drivers doesn't require much support from platform code now a
> days as most of the stuff is moved behind generic APIs. Like clk APIs for
> changing clock rates, regulator APIs for changing voltages, etc.
>
> One of the bottleneck still left was how to select which cpufreq driver to probe
> for a given platform as there might be multiple drivers available.
>
> Traditionally, we used to create platform devices from machine specific code
> which binds with a cpufreq driver. And while we moved towards DT based device
> creation, these devices stayed as is.
>
> The problem is getting worse now as we have architectures now with Zero platform
> specific code. Forcefully these platforms have to create a new file in
> drivers/cpufreq/ to just add these platform devices in order to use the generic
> drivers like cpufreq-dt.c.
>
> This has been discussed again and again, but with no solution yet. Last it was
> discussed here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256154.html
>
> This patch is an attempt towards getting the bindings.
>
> We only need to have one entry in cpus@cpu0 node which will match with drivers
> name.
>
This seems fundamentally broken as the driver always needs to
unconditionally refer to cpu0. Furthermore the node need not be called
cpu0 as the name depends on its reg field.
> We can then add another file drivers/cpufreq/device_dt.c, which will add a
> platform device with the name it finds from cpus@cpu0 node and existing drivers
> will work without any change. Or something else if somebody have a better
> proposal. But lets fix the bindings first.
IIUC you will retain the existing list of cpufreq-dt platform device
creation as is. If not that breaks compatibility with old DT.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/cpufreq/drivers.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/drivers.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/drivers.txt b/Documentation/devicetree/bindings/cpufreq/drivers.txt
> new file mode 100644
> index 0000000..bd14917
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/drivers.txt
> @@ -0,0 +1,53 @@
> +Binding to select which cpufreq driver to register
> +
> +It is a generic DT binding for selecting which cpufreq-driver to register for
> +any platform.
> +
> +The property listed below must be defined under node /cpus/cpu@0 node. We don't
> +support multiple CPUFreq driver currently for different cluster and so this
> +information isn't required to be present in CPUs of all clusters.
> +
> +Required properties:
> +- None
> +
> +Optional properties:
> +- dvfs-method: CPUFreq driver to probe. For example: "arm-bL-cpufreq-dt",
> + "cpufreq-dt", etc
> +
You should manage this with compatible rather than a new property as
it's not a real hardware property. IMHO Rob's suggestion[1] should work
fine.
IIUC, you can have the driver which create this platform device if DT
has generic compatible unconditionally(e.g "cpufreq-dt" as you have
chosen above). For all existing DT you can create a blacklist of
compatibles to match(as it doesn't have the generic compatible) covering
all the existing platforms using cpufreq-dt driver, there by you can
even remove the platform device creating from multiple places.
IMO something like the patch below should work(not tested, also
late_initcall is used just to demonstrate the idea)
Rob, please correct me if my understanding is wrong.
Regards,
Sudeep
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256191.html
--->8
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index f657c571b18e..19a616e298e0 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -387,6 +387,32 @@ static struct platform_driver dt_cpufreq_platdrv = {
};
module_platform_driver(dt_cpufreq_platdrv);
+static const struct of_device_id compatible_machine_match[] = {
+ /* All new machines must have the below compatible to use this
driver */
+ { .compatible = "cpufreq-generic-dt" },
+ /* BLACKLIST of existing users of cpufreq-dt below */
+ { .compatible = "samsung,exynos5420" },
+ { .compatible = "samsung,exynos5800" },
+ {},
+};
+
+static int cpufreq_generic_dt_init(void)
+{
+ struct device_node *root = of_find_node_by_path("/");
+ struct platform_device_info devinfo = { .name = "cpufreq-dt", };
+ /*
+ * Initialize the device for the platforms either
+ * blacklisted or compliant to generic compatible
+ */
+ if (!of_match_node(compatible_machine_match, root))
+ return -ENODEV;
+
+ /* Instantiate cpufreq-dt */
+ platform_device_register_full(&devinfo);
+ return 0;
+}
+late_initcall(cpufreq_generic_dt_init);
+
next prev parent reply other threads:[~2014-11-26 17:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 8:46 [RFC] cpufreq: Add "dvfs-method" binding to probe cpufreq drivers Viresh Kumar
2014-11-26 8:49 ` Viresh Kumar
2014-11-26 16:34 ` santosh shilimkar
2014-11-27 5:14 ` Viresh Kumar
2014-11-30 20:04 ` santosh.shilimkar
2014-11-26 17:00 ` Sudeep Holla [this message]
2014-11-26 17:04 ` Sudeep Holla
2014-11-27 5:29 ` Viresh Kumar
2014-11-27 9:54 ` Sudeep Holla
2014-11-27 10:22 ` Viresh Kumar
2014-11-27 11:15 ` Sudeep Holla
2014-11-28 6:31 ` Viresh Kumar
2014-11-28 11:51 ` Sudeep Holla
2014-12-01 8:06 ` Viresh Kumar
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=5476071B.1060705@arm.com \
--to=sudeep.holla@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=arnd.bergmann@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=k.chander@samsung.com \
--cc=kesavan.abhilash@gmail.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=mike.turquette@linaro.org \
--cc=nm@ti.com \
--cc=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=rob.herring@linaro.org \
--cc=santosh.shilimkar@oracle.com \
--cc=sboyd@codeaurora.org \
--cc=ta.omasab@gmail.com \
--cc=viresh.kumar@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.