On 07/26/2013 07:43 AM, Guennadi Liakhovetski wrote:
Hi Nishanth
On Fri, 26 Jul 2013, Nishanth Menon wrote:
On 07/26/2013 05:19 AM, Guennadi Liakhovetski wrote:
Currently the cpufreq-cpu0 driver doesn't support Device Tree probing. To
support it we add an OF match table to it. In principle this alone is
enough to get the driver working with DT devices, but then the driver
rewrites the .of_node field of the probed device with a different one,
which isn't clean. To avoid this we use the cpu0 system device for clock
and OPP handling, similar to what the arm_big_little CPUFreq driver does.
This is also less intrusive, since the cpu0 device's .of_node field is
initially NULL, since this isn't a DT device.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@xxxxxxxxx>
---
drivers/cpufreq/cpufreq-cpu0.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..d2ad7b8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,6 +12,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/clk.h>
+#include <linux/cpu.h>
#include <linux/cpufreq.h>
#include <linux/err.h>
#include <linux/module.h>
@@ -194,7 +195,7 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
goto out_put_parent;
}
- cpu_dev = &pdev->dev;
+ cpu_dev = get_cpu_device(0);
cpu_dev->of_node = np;
cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
@@ -289,10 +290,17 @@ static int cpu0_cpufreq_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id cpu0_cpufreq_of_match[] = {
+ {.compatible = "cpufreq-cpu0"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, cpu0_cpufreq_of_match);
+
static struct platform_driver cpu0_cpufreq_platdrv = {
.driver = {
- .name = "cpufreq-cpu0",
- .owner = THIS_MODULE,
+ .name = "cpufreq-cpu0",
+ .of_match_table = cpu0_cpufreq_of_match,
+ .owner = THIS_MODULE,
},
.probe = cpu0_cpufreq_probe,
.remove = cpu0_cpufreq_remove,
Did we not go down this approach[1] previously? Could you explain why this
path is different now?
Yes, you're right, I forgot about that discussion, sorry. But my
motivation was the following: yes, I'm aware, that the DT should only
describe real hardware _devices_ and hardware _properties_. But this patch
- just like your original patch - don't add a pseudo _device_ or
_property_, but a compatibility string. So, to me it was like "a class of
all systems, where the CPU performance can be scaled using one power
supply and one clock. Isn't this a hardware feature? We already have CPU
The definition of the hardware (CPU) behavior - which is performance
indicator, would be an operating performance point (OPP), no? we have
already modelled that in dts - in fact Mike has a better approach that
is maturing.
As far as I am concerned, a generic device(including processing) which
does not have the deep linkage to kernel behavior should be managed by
devfreq, cpufreq has linkage to core scheduler and PM behavior, and
could be arguably stand alone on its own - though it could be argued
that devfreq could be made as a superset of which cpufreq functionality
is just one part of it.
nodes in DT, this would be just (an additional) compatibility string to
them? I'll be happy to drop this patch and revive yours, if we manage to
agree upon the scope.
As far as I am concerned, the original argument Shawn made[1] is
convincing enough for me.
Will probably look at Viresh and others to see if there is a change in
opinion.
[1] http://marc.info/?l=devicetree&m=137435418742097&w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
