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 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).