omap cpufreq driver in multi-platform kernels

The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option.

From c1b4374d9cdcf59e0cbe93aa5a23335cb3e60798 Mon Sep 17 00:00:00 2001

Hi

Quoted 8 lines · Rob Herring

The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option.

We could move the

	mpu_clk = clk_get(NULL, "cpufreq_ck");

down to omap_cpufreq_init(), and bail out early if the clock alias doesn't exist. (Presumably we'd also want to change the clock role name if we did that, to something like "omap_cpufreq_ck".)

Experimental patch follows, comments welcome.

- Paul

From c1b4374d9cdcf59e0cbe93aa5a23335cb3e60798 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <[email protected]>
Date: Tue, 26 Mar 2013 20:16:39 -0600
Subject: [PATCH] EXPERIMENTAL: cpufreq: avoid loading the OMAP driver on
non-OMAP multiplatform targets

etc. etc.

---
 arch/arm/mach-omap2/cclock2420_data.c |    2 +-
 arch/arm/mach-omap2/cclock2430_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/cclock44xx_data.c |    2 +-
 drivers/cpufreq/omap-cpufreq.c        |    8 ++++----
 5 files changed, 8 insertions(+), 8 deletions(-)

arch/arm/mach-omap2/cclock2420_data.c +1 -1

index 0f0a97c..d4316e9 100644
@@ -1885,7 +1885,7 @@ static struct omap_clk omap2420_clks[] = {
 	CLK(NULL,	"timer_32k_ck",	&func_32k_ck,	CK_242X),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_242X),
 	CLK(NULL,	"timer_ext_ck",	&alt_ck,	CK_242X),
-	CLK(NULL,	"cpufreq_ck",	&virt_prcm_set,	CK_242X),
+	CLK(NULL,	"omap_cpufreq_ck",	&virt_prcm_set,	CK_242X),
 };
 
 

arch/arm/mach-omap2/cclock2430_data.c +1 -1

index aed8f74..7c855b9 100644
@@ -2001,7 +2001,7 @@ static struct omap_clk omap2430_clks[] = {
 	CLK(NULL,	"timer_32k_ck",  &func_32k_ck,   CK_243X),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_243X),
 	CLK(NULL,	"timer_ext_ck",	&alt_ck,	CK_243X),
-	CLK(NULL,	"cpufreq_ck",	&virt_prcm_set,	CK_243X),
+	CLK(NULL,	"omap_cpufreq_ck",	&virt_prcm_set,	CK_243X),
 };
 
 static const char *enable_init_clks[] = {

arch/arm/mach-omap2/cclock3xxx_data.c +1 -1

index 4579c3c..17dd82c 100644
@@ -3501,7 +3501,7 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
 	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
-	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
+	CLK(NULL,	"omap_cpufreq_ck",	&dpll1_ck,	CK_3XXX),
 };
 
 static const char *enable_init_clks[] = {

arch/arm/mach-omap2/cclock44xx_data.c +1 -1

index 3d58f33..66b85e5 100644
@@ -1660,7 +1660,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLK(NULL,	"omap_cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
 };
 
 int __init omap4xxx_clk_init(void)

drivers/cpufreq/omap-cpufreq.c +4 -4

index 9128c07..d46caa5 100644
@@ -175,10 +175,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
 
-	mpu_clk = clk_get(NULL, "cpufreq_ck");
-	if (IS_ERR(mpu_clk))
-		return PTR_ERR(mpu_clk);
-
 	if (policy->cpu >= NR_CPUS) {
 		result = -EINVAL;
 		goto fail_ck;

@@ -254,6 +250,10 @@ static struct cpufreq_driver omap_driver = {
 
 static int __init omap_cpufreq_init(void)
 {
+	mpu_clk = clk_get(NULL, "omap_cpufreq_ck");
+	if (IS_ERR(mpu_clk))
+		return PTR_ERR(mpu_clk);
+
 	mpu_dev = get_cpu_device(0);
 	if (!mpu_dev) {
 		pr_warning("%s: unable to get the mpu device\n", __func__);

Signature · 6 lines

1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 21 lines · Paul Walmsley

Hi

Quoted 8 lines · Rob Herring

The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option.

We could move the

	mpu_clk = clk_get(NULL, "cpufreq_ck");

down to omap_cpufreq_init(), and bail out early if the clock alias doesn't exist. (Presumably we'd also want to change the clock role name if we did that, to something like "omap_cpufreq_ck".)

Quoted 1 line

Experimental patch follows, comments welcome.

We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO.
http://marc.info/?l=linux-omap&m=136371580826031&w=2
is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane?

Quoted 104 lines

- Paul

From c1b4374d9cdcf59e0cbe93aa5a23335cb3e60798 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <[email protected]>
Date: Tue, 26 Mar 2013 20:16:39 -0600
Subject: [PATCH] EXPERIMENTAL: cpufreq: avoid loading the OMAP driver on
non-OMAP multiplatform targets

etc. etc.

---
 arch/arm/mach-omap2/cclock2420_data.c |    2 +-
 arch/arm/mach-omap2/cclock2430_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/cclock44xx_data.c |    2 +-
 drivers/cpufreq/omap-cpufreq.c        |    8 ++++----
 5 files changed, 8 insertions(+), 8 deletions(-)

arch/arm/mach-omap2/cclock2420_data.c +1 -1

index 0f0a97c..d4316e9 100644
@@ -1885,7 +1885,7 @@ static struct omap_clk omap2420_clks[] = {
 	CLK(NULL,	"timer_32k_ck",	&func_32k_ck,	CK_242X),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_242X),
 	CLK(NULL,	"timer_ext_ck",	&alt_ck,	CK_242X),
-	CLK(NULL,	"cpufreq_ck",	&virt_prcm_set,	CK_242X),
+	CLK(NULL,	"omap_cpufreq_ck",	&virt_prcm_set,	CK_242X),
 };
 
 

arch/arm/mach-omap2/cclock2430_data.c +1 -1

index aed8f74..7c855b9 100644
@@ -2001,7 +2001,7 @@ static struct omap_clk omap2430_clks[] = {
 	CLK(NULL,	"timer_32k_ck",  &func_32k_ck,   CK_243X),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_243X),
 	CLK(NULL,	"timer_ext_ck",	&alt_ck,	CK_243X),
-	CLK(NULL,	"cpufreq_ck",	&virt_prcm_set,	CK_243X),
+	CLK(NULL,	"omap_cpufreq_ck",	&virt_prcm_set,	CK_243X),
 };
 
 static const char *enable_init_clks[] = {

arch/arm/mach-omap2/cclock3xxx_data.c +1 -1

index 4579c3c..17dd82c 100644
@@ -3501,7 +3501,7 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
 	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
-	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
+	CLK(NULL,	"omap_cpufreq_ck",	&dpll1_ck,	CK_3XXX),
 };
 
 static const char *enable_init_clks[] = {

arch/arm/mach-omap2/cclock44xx_data.c +1 -1

index 3d58f33..66b85e5 100644
@@ -1660,7 +1660,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLK(NULL,	"omap_cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
 };
 
 int __init omap4xxx_clk_init(void)

drivers/cpufreq/omap-cpufreq.c +4 -4

index 9128c07..d46caa5 100644
@@ -175,10 +175,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
 
-	mpu_clk = clk_get(NULL, "cpufreq_ck");
-	if (IS_ERR(mpu_clk))
-		return PTR_ERR(mpu_clk);
-
 	if (policy->cpu >= NR_CPUS) {
 		result = -EINVAL;
 		goto fail_ck;

@@ -254,6 +250,10 @@ static struct cpufreq_driver omap_driver = {
 
 static int __init omap_cpufreq_init(void)
 {
+	mpu_clk = clk_get(NULL, "omap_cpufreq_ck");
+	if (IS_ERR(mpu_clk))
+		return PTR_ERR(mpu_clk);
+
 	mpu_dev = get_cpu_device(0);
 	if (!mpu_dev) {
 		pr_warning("%s: unable to get the mpu device\n", __func__);

Signature · 6 lines

1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 22 lines · Nishanth Menon

Quoted 21 lines · Paul Walmsley

Hi

Quoted 8 lines · Rob Herring

The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option.

We could move the

	mpu_clk = clk_get(NULL, "cpufreq_ck");

down to omap_cpufreq_init(), and bail out early if the clock alias doesn't exist. (Presumably we'd also want to change the clock role name if we did that, to something like "omap_cpufreq_ck".)

Quoted 7 lines

Quoted 1 line

Experimental patch follows, comments welcome.

We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO.
http://marc.info/?l=linux-omap&m=136371580826031&w=2
is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane?

That only solves the problem for DT, but not non-DT. My understanding is non-DT omap platforms will be around for some time.

Quoted 31 lines · Rob Herring

Quoted 22 lines · Nishanth Menon

Quoted 21 lines · Paul Walmsley

Hi

Quoted 8 lines · Rob Herring

The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option.

We could move the

	mpu_clk = clk_get(NULL, "cpufreq_ck");

down to omap_cpufreq_init(), and bail out early if the clock alias doesn't exist. (Presumably we'd also want to change the clock role name if we did that, to something like "omap_cpufreq_ck".)

Quoted 7 lines

Quoted 1 line

Experimental patch follows, comments welcome.

We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO.
http://marc.info/?l=linux-omap&m=136371580826031&w=2
is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane?

Quoted 3 lines

That only solves the problem for DT, but not non-DT. My understanding is non-DT omap platforms will be around for some time.

Yes, that is true. There are multiple parts of the problem:
part #1: DT boot:
https://patchwork.kernel.org/patch/2303471/ prevents omap-cpufreq from interfering in DT enabled boot. (seeing DT entries for highbank it probably might help in the specific platform)
part #2: non DT boot:
you would not have cpu DT nodes in the system. So, cpufreq-cpu0 wont come into play[1]
Now the conflict between omap-cpufreq Vs non-dt platform cpufreq driver:
other than registering an dummy device and moving omap_cpufreq_init to it (similar to what was done in cpufreq-cpu0[2]) I dont see how we can continue to keep multiple platforms sane in mult-arch non-dt boot.

[1] https://patchwork.kernel.org/patch/2351601/
[2] https://patchwork.kernel.org/patch/2067751/

Quoted 48 lines · Nishanth Menon

Quoted 31 lines · Rob Herring

Quoted 22 lines · Nishanth Menon

Quoted 21 lines · Paul Walmsley

Hi

Quoted 8 lines · Rob Herring

The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option.

We could move the

	mpu_clk = clk_get(NULL, "cpufreq_ck");

down to omap_cpufreq_init(), and bail out early if the clock alias doesn't exist. (Presumably we'd also want to change the clock role name if we did that, to something like "omap_cpufreq_ck".)

Quoted 7 lines

Quoted 1 line

Experimental patch follows, comments welcome.

We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO.
http://marc.info/?l=linux-omap&m=136371580826031&w=2
is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane?

Quoted 3 lines

That only solves the problem for DT, but not non-DT. My understanding is non-DT omap platforms will be around for some time.

Yes, that is true. There are multiple parts of the problem:
part #1: DT boot:
https://patchwork.kernel.org/patch/2303471/ prevents omap-cpufreq from interfering in DT enabled boot. (seeing DT entries for highbank it probably might help in the specific platform)
part #2: non DT boot:
you would not have cpu DT nodes in the system. So, cpufreq-cpu0 wont come into play[1]
Now the conflict between omap-cpufreq Vs non-dt platform cpufreq driver:
other than registering an dummy device and moving omap_cpufreq_init to it (similar to what was done in cpufreq-cpu0[2]) I dont see how we can continue to keep multiple platforms sane in mult-arch non-dt boot.

Quoted 2 lines

[1] https://patchwork.kernel.org/patch/2351601/
[2] https://patchwork.kernel.org/patch/2067751/

I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1].

I'll have a closer look at that series also and comment there as well.

Kevin

[1] http://marc.info/?l=linux-omap&m=136371580826031&w=2

Quoted 8 lines · Kevin Hilman

Quoted 6 lines · Nishanth Menon

Quoted 5 lines · Rob Herring

Quoted 4 lines · Nishanth Menon

Quoted 3 lines · Paul Walmsley

Quoted 2 lines · Rob Herring

Converting the driver to a platform driver would be another option.

Quoted 3 lines

I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1].

Yep, thinking about this over lunch, I came to the same conclusion that instead of checking on DT node existance, platform_device conversion will solve both parts of the puzzle.

Hi folks,

Quoted 9 lines · Nishanth Menon

Quoted 8 lines · Kevin Hilman

Quoted 6 lines · Nishanth Menon

Quoted 5 lines · Rob Herring

Quoted 4 lines · Nishanth Menon

Quoted 3 lines · Paul Walmsley

Quoted 2 lines · Rob Herring

Converting the driver to a platform driver would be another option.

Quoted 7 lines

Quoted 3 lines

I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1].

Yep, thinking about this over lunch, I came to the same conclusion that instead of checking on DT node existance, platform_device conversion will solve both parts of the puzzle.

Looked at this a little today. I see that the platform_driver CPUFreq driver approach was taken with several SoCs in mainline. Could someone explain the theory behind making the CPUFreq drivers platform_drivers, rather than just modules?

The part that doesn't make sense to me is that the existing CPUFreq drivers don't represent an actual hardware block. Conceptually, they aren't drivers for the CPU, nor are they drivers for a CPU frequency scaling IP block. One might as well bind a CPUIdle driver or a CPU throttling thermal driver to the CPU device.

Wouldn't it be best to just make them modules?

Also, noticed that the Highbank CPUFreq driver creates a virtual device in its code. That also doesn't seem right. Isn't device creation better left to DT/ACPI/whatever?

regards,

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hey Paul,

Quoted 36 lines · Paul Walmsley

Hi folks,

Quoted 16 lines · Nishanth Menon

Quoted 15 lines · Kevin Hilman

Quoted 11 lines · Nishanth Menon

Quoted 9 lines · Rob Herring

Quoted 7 lines · Nishanth Menon

Quoted 5 lines · Paul Walmsley

Quoted 3 lines · Rob Herring

Converting the driver to a platform driver would be another option.

Quoted 8 lines

Quoted 3 lines

I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1].

Yep, thinking about this over lunch, I came to the same conclusion that instead of checking on DT node existance, platform_device conversion will solve both parts of the puzzle.

Looked at this a little today. I see that the platform_driver CPUFreq driver approach was taken with several SoCs in mainline. Could someone explain the theory behind making the CPUFreq drivers platform_drivers, rather than just modules?

Quoted 5 lines

The part that doesn't make sense to me is that the existing CPUFreq drivers don't represent an actual hardware block. Conceptually, they aren't drivers for the CPU, nor are they drivers for a CPU frequency scaling IP block. One might as well bind a CPUIdle driver or a CPU throttling thermal driver to the CPU device.

I do agree with your point. On the other hand, I'd like to make a clarification here.

CPU throttling feature not really done as a driver. The feature is exported to be used by policies built by other code. Check drivers/thermal/cpu_cooling.c.

Thermal drivers are in fact drivers, as they are bound to an actual hardware block, a bandgap, a thermal sensor or a thermistor.

Quoted 1 line

Quoted 1 line

Wouldn't it be best to just make them modules?

Thermal policies are built as modules.

Quoted 5 lines

Also, noticed that the Highbank CPUFreq driver creates a virtual device in its code. That also doesn't seem right. Isn't device creation better left to DT/ACPI/whatever?

Quoted 25 lines · Paul Walmsley

Quoted 10 lines · Nishanth Menon

Quoted 9 lines · Kevin Hilman

Quoted 7 lines · Nishanth Menon

Quoted 6 lines · Rob Herring

Quoted 5 lines · Nishanth Menon

Quoted 4 lines · Paul Walmsley

Quoted 3 lines · Rob Herring

Converting the driver to a platform driver would be another option.

Quoted 7 lines

Quoted 3 lines

I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1].

Yep, thinking about this over lunch, I came to the same conclusion that instead of checking on DT node existance, platform_device conversion will solve both parts of the puzzle.

Looked at this a little today. I see that the platform_driver CPUFreq driver approach was taken with several SoCs in mainline. Could someone explain the theory behind making the CPUFreq drivers platform_drivers, rather than just modules?

Quoted 5 lines

The part that doesn't make sense to me is that the existing CPUFreq drivers don't represent an actual hardware block. Conceptually, they aren't drivers for the CPU, nor are they drivers for a CPU frequency scaling IP block. One might as well bind a CPUIdle driver or a CPU throttling thermal driver to the CPU device.

I do agree with your point. On the other hand, I'd like to make a clarification here.

CPU throttling feature not really done as a driver. The feature is exported to be used by policies built by other code. Check drivers/thermal/cpu_cooling.c.

Thermal drivers are in fact drivers, as they are bound to an actual hardware block, a bandgap, a thermal sensor or a thermistor.

Hi folks,

Quoted 9 lines · Nishanth Menon

Quoted 8 lines · Kevin Hilman

Quoted 6 lines · Nishanth Menon

Quoted 5 lines · Rob Herring

Quoted 4 lines · Nishanth Menon

Quoted 3 lines · Paul Walmsley

Quoted 2 lines · Rob Herring

Converting the driver to a platform driver would be another option.

Quoted 7 lines

Quoted 3 lines

I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1].

Yep, thinking about this over lunch, I came to the same conclusion that instead of checking on DT node existance, platform_device conversion will solve both parts of the puzzle.

Looked at this a little today. I see that the platform_driver CPUFreq driver approach was taken with several SoCs in mainline. Could someone explain the theory behind making the CPUFreq drivers platform_drivers, rather than just modules?

The part that doesn't make sense to me is that the existing CPUFreq drivers don't represent an actual hardware block. Conceptually, they aren't drivers for the CPU, nor are they drivers for a CPU frequency scaling IP block. One might as well bind a CPUIdle driver or a CPU throttling thermal driver to the CPU device.

Wouldn't it be best to just make them modules?

Also, noticed that the Highbank CPUFreq driver creates a virtual device in its code. That also doesn't seem right. Isn't device creation better left to DT/ACPI/whatever?

Quoted 6 lines · Paul Walmsley

Looked at this a little today. I see that the platform_driver CPUFreq driver approach was taken with several SoCs in mainline. Could someone explain the theory behind making the CPUFreq drivers platform_drivers, rather than just modules?

Quoted 7 lines

The part that doesn't make sense to me is that the existing CPUFreq drivers don't represent an actual hardware block. Conceptually, they aren't drivers for the CPU, nor are they drivers for a CPU frequency scaling IP block. One might as well bind a CPUIdle driver or a CPU throttling thermal driver to the CPU device.

Wouldn't it be best to just make them modules?

Then module auto loading doesn't work AFAIK. We will want them to be built as modules in multi-platform kernels to reduce the kernel size, but you don't want to just shift the problem to the OS to decide what modules a given platform needs.

Quoted 3 lines

Also, noticed that the Highbank CPUFreq driver creates a virtual device in its code. That also doesn't seem right. Isn't device creation better left to DT/ACPI/whatever?

DT describes the h/w. Creating DT nodes that match the cpufreq drivers is not describing the h/w, but what Linux wants currently. Cpufreq drivers either touch parts of multiple h/w blocks, a single shared h/w block or don't touch h/w directly. The cpufreq-cpu0 driver is the last case and does use DT. Perhaps we will get to the point that all low-level interfaces are abstracted and we can have a single cpufreq driver.

I think platform drivers are the right way to go, but I'd like to come up with a better way to instantiate the devices. The only idea I've come up with is to do some sort of automatic device creation based machine compatible property matching.

We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO.
http://marc.info/?l=linux-omap&m=136371580826031&w=2
is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane?

Hi

On Wed, 27 Mar 2013, Nishanth Menon wrote:

Quoted 6 lines

We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO.
http://marc.info/?l=linux-omap&m=136371580826031&w=2
is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane?

Haven't looked closely at the series, but the idea makes sense to me, as

long as OMAP doesn't need to do anything too exotic in the CPUFreq driver.