* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-08 19:57 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-08 19:57 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm,
Felipe Balbi
By adding operating points, cpufreq-dt has a
chance of running and doing something useful.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c80a3e233792..ea1db20f64fc 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -38,6 +38,15 @@
clocks = <&dpll_mpu_ck>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz uV */
+ 1000000 1325000 /* OPP_NITRO */
+ 800000 1260000 /* OPP_TURBO */
+ 720000 1200000 /* OPP_120 */
+ 600000 1100000 /* OPP_100 */
+ 300000 950000 /* OPP_50 */
+ >;
+
clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
--
2.4.0.rc3
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-08 19:57 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-08 19:57 UTC (permalink / raw)
To: linux-arm-kernel
By adding operating points, cpufreq-dt has a
chance of running and doing something useful.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c80a3e233792..ea1db20f64fc 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -38,6 +38,15 @@
clocks = <&dpll_mpu_ck>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz uV */
+ 1000000 1325000 /* OPP_NITRO */
+ 800000 1260000 /* OPP_TURBO */
+ 720000 1200000 /* OPP_120 */
+ 600000 1100000 /* OPP_100 */
+ 300000 950000 /* OPP_50 */
+ >;
+
clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
--
2.4.0.rc3
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
2015-05-08 19:57 ` Felipe Balbi
@ 2015-05-08 19:57 ` Felipe Balbi
-1 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-08 19:57 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm,
Felipe Balbi
by adding the missing MODULE_ALIAS(), cpufreq-dt
can be autoloaded by udev/systemd.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/cpufreq/cpufreq-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index bab67db54b7e..528a82bf5038 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
};
module_platform_driver(dt_cpufreq_platdrv);
+MODULE_ALIAS("platform:cpufreq-dt");
MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
MODULE_DESCRIPTION("Generic cpufreq driver");
--
2.4.0.rc3
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
@ 2015-05-08 19:57 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-08 19:57 UTC (permalink / raw)
To: linux-arm-kernel
by adding the missing MODULE_ALIAS(), cpufreq-dt
can be autoloaded by udev/systemd.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/cpufreq/cpufreq-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index bab67db54b7e..528a82bf5038 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
};
module_platform_driver(dt_cpufreq_platdrv);
+MODULE_ALIAS("platform:cpufreq-dt");
MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
MODULE_DESCRIPTION("Generic cpufreq driver");
--
2.4.0.rc3
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-08 19:57 ` Felipe Balbi
@ 2015-05-08 20:09 ` Nishanth Menon
-1 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-08 20:09 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren
Cc: Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm
On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> By adding operating points, cpufreq-dt has a
> chance of running and doing something useful.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index c80a3e233792..ea1db20f64fc 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -38,6 +38,15 @@
> clocks = <&dpll_mpu_ck>;
> clock-names = "cpu";
>
> + operating-points = <
> + /* kHz uV */
> + 1000000 1325000 /* OPP_NITRO */
> + 800000 1260000 /* OPP_TURBO */
> + 720000 1200000 /* OPP_120 */
> + 600000 1100000 /* OPP_100 */
> + 300000 950000 /* OPP_50 */
> + >;
> +
> clock-latency = <300000>; /* From omap-cpufreq driver */
> };
> };
>
which of these OPPs need AVS? which of these are dependent on Efuse bit
dependent?
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-08 20:09 ` Nishanth Menon
0 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-08 20:09 UTC (permalink / raw)
To: linux-arm-kernel
On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> By adding operating points, cpufreq-dt has a
> chance of running and doing something useful.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index c80a3e233792..ea1db20f64fc 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -38,6 +38,15 @@
> clocks = <&dpll_mpu_ck>;
> clock-names = "cpu";
>
> + operating-points = <
> + /* kHz uV */
> + 1000000 1325000 /* OPP_NITRO */
> + 800000 1260000 /* OPP_TURBO */
> + 720000 1200000 /* OPP_120 */
> + 600000 1100000 /* OPP_100 */
> + 300000 950000 /* OPP_50 */
> + >;
> +
> clock-latency = <300000>; /* From omap-cpufreq driver */
> };
> };
>
which of these OPPs need AVS? which of these are dependent on Efuse bit
dependent?
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-08 20:09 ` Nishanth Menon
@ 2015-05-08 20:12 ` Nishanth Menon
-1 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-08 20:12 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren
Cc: Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm
On 05/08/2015 03:09 PM, Nishanth Menon wrote:
> On 05/08/2015 02:57 PM, Felipe Balbi wrote:
>> By adding operating points, cpufreq-dt has a
>> chance of running and doing something useful.
>>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> ---
>> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index c80a3e233792..ea1db20f64fc 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -38,6 +38,15 @@
>> clocks = <&dpll_mpu_ck>;
>> clock-names = "cpu";
>>
>> + operating-points = <
>> + /* kHz uV */
>> + 1000000 1325000 /* OPP_NITRO */
>> + 800000 1260000 /* OPP_TURBO */
>> + 720000 1200000 /* OPP_120 */
>> + 600000 1100000 /* OPP_100 */
>> + 300000 950000 /* OPP_50 */
>> + >;
>> +
>> clock-latency = <300000>; /* From omap-cpufreq driver */
>> };
>> };
>>
> which of these OPPs need AVS? which of these are dependent on Efuse bit
> dependent?
>
You can use
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
for reference.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-08 20:12 ` Nishanth Menon
0 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-08 20:12 UTC (permalink / raw)
To: linux-arm-kernel
On 05/08/2015 03:09 PM, Nishanth Menon wrote:
> On 05/08/2015 02:57 PM, Felipe Balbi wrote:
>> By adding operating points, cpufreq-dt has a
>> chance of running and doing something useful.
>>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> ---
>> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index c80a3e233792..ea1db20f64fc 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -38,6 +38,15 @@
>> clocks = <&dpll_mpu_ck>;
>> clock-names = "cpu";
>>
>> + operating-points = <
>> + /* kHz uV */
>> + 1000000 1325000 /* OPP_NITRO */
>> + 800000 1260000 /* OPP_TURBO */
>> + 720000 1200000 /* OPP_120 */
>> + 600000 1100000 /* OPP_100 */
>> + 300000 950000 /* OPP_50 */
>> + >;
>> +
>> clock-latency = <300000>; /* From omap-cpufreq driver */
>> };
>> };
>>
> which of these OPPs need AVS? which of these are dependent on Efuse bit
> dependent?
>
You can use
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
for reference.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
2015-05-08 19:57 ` Felipe Balbi
@ 2015-05-08 20:16 ` Nishanth Menon
-1 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-08 20:16 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren
Cc: Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm
On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> by adding the missing MODULE_ALIAS(), cpufreq-dt
> can be autoloaded by udev/systemd.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/cpufreq/cpufreq-dt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index bab67db54b7e..528a82bf5038 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
> };
> module_platform_driver(dt_cpufreq_platdrv);
>
> +MODULE_ALIAS("platform:cpufreq-dt");
> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> MODULE_DESCRIPTION("Generic cpufreq driver");
>
This patch does not depend on patch #1 of the series.
other than that..
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
@ 2015-05-08 20:16 ` Nishanth Menon
0 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-08 20:16 UTC (permalink / raw)
To: linux-arm-kernel
On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> by adding the missing MODULE_ALIAS(), cpufreq-dt
> can be autoloaded by udev/systemd.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/cpufreq/cpufreq-dt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index bab67db54b7e..528a82bf5038 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
> };
> module_platform_driver(dt_cpufreq_platdrv);
>
> +MODULE_ALIAS("platform:cpufreq-dt");
> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> MODULE_DESCRIPTION("Generic cpufreq driver");
>
This patch does not depend on patch #1 of the series.
other than that..
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-08 20:12 ` Nishanth Menon
@ 2015-05-08 20:24 ` Felipe Balbi
-1 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-08 20:24 UTC (permalink / raw)
To: Nishanth Menon
Cc: Felipe Balbi, Tony Lindgren, Rob Herring, Mark Rutland, rjw,
Viresh Kumar, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-pm
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
On Fri, May 08, 2015 at 03:12:27PM -0500, Nishanth Menon wrote:
> On 05/08/2015 03:09 PM, Nishanth Menon wrote:
> > On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> >> By adding operating points, cpufreq-dt has a
> >> chance of running and doing something useful.
> >>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> ---
> >> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> >> index c80a3e233792..ea1db20f64fc 100644
> >> --- a/arch/arm/boot/dts/am4372.dtsi
> >> +++ b/arch/arm/boot/dts/am4372.dtsi
> >> @@ -38,6 +38,15 @@
> >> clocks = <&dpll_mpu_ck>;
> >> clock-names = "cpu";
> >>
> >> + operating-points = <
> >> + /* kHz uV */
> >> + 1000000 1325000 /* OPP_NITRO */
> >> + 800000 1260000 /* OPP_TURBO */
> >> + 720000 1200000 /* OPP_120 */
> >> + 600000 1100000 /* OPP_100 */
> >> + 300000 950000 /* OPP_50 */
> >> + >;
> >> +
> >> clock-latency = <300000>; /* From omap-cpufreq driver */
> >> };
> >> };
> >>
> > which of these OPPs need AVS? which of these are dependent on Efuse bit
> > dependent?
> >
>
>
> You can use
> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
> for reference.
heh, why isn't that upstream yet ? Seems to be ready already. The point
is that as of now, u-boot will set maximum OPP it can find and, for
AM437x, that will be 800MHz or 1GHz depending on your board. 1GHz might
not be supported in all SoCs and letting that be used all the time is
likely going to reduce silicon lifetime.
At least allowing ondemand governor run, we will be mostly running at
300MHz and only jump to "invalid" OPPs under load which, granted, is
still not perfect, but better than running at 1GHz all the time, don't
you agree ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-08 20:24 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-08 20:24 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 08, 2015 at 03:12:27PM -0500, Nishanth Menon wrote:
> On 05/08/2015 03:09 PM, Nishanth Menon wrote:
> > On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> >> By adding operating points, cpufreq-dt has a
> >> chance of running and doing something useful.
> >>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> ---
> >> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> >> index c80a3e233792..ea1db20f64fc 100644
> >> --- a/arch/arm/boot/dts/am4372.dtsi
> >> +++ b/arch/arm/boot/dts/am4372.dtsi
> >> @@ -38,6 +38,15 @@
> >> clocks = <&dpll_mpu_ck>;
> >> clock-names = "cpu";
> >>
> >> + operating-points = <
> >> + /* kHz uV */
> >> + 1000000 1325000 /* OPP_NITRO */
> >> + 800000 1260000 /* OPP_TURBO */
> >> + 720000 1200000 /* OPP_120 */
> >> + 600000 1100000 /* OPP_100 */
> >> + 300000 950000 /* OPP_50 */
> >> + >;
> >> +
> >> clock-latency = <300000>; /* From omap-cpufreq driver */
> >> };
> >> };
> >>
> > which of these OPPs need AVS? which of these are dependent on Efuse bit
> > dependent?
> >
>
>
> You can use
> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
> for reference.
heh, why isn't that upstream yet ? Seems to be ready already. The point
is that as of now, u-boot will set maximum OPP it can find and, for
AM437x, that will be 800MHz or 1GHz depending on your board. 1GHz might
not be supported in all SoCs and letting that be used all the time is
likely going to reduce silicon lifetime.
At least allowing ondemand governor run, we will be mostly running at
300MHz and only jump to "invalid" OPPs under load which, granted, is
still not perfect, but better than running at 1GHz all the time, don't
you agree ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150508/84baa977/attachment.sig>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
2015-05-08 19:57 ` Felipe Balbi
@ 2015-05-09 2:29 ` Viresh Kumar
-1 siblings, 0 replies; 28+ messages in thread
From: Viresh Kumar @ 2015-05-09 2:29 UTC (permalink / raw)
To: Felipe Balbi
Cc: Tony Lindgren, Rob Herring, Mark Rutland, Rafael J. Wysocki,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm
On 9 May 2015 at 01:27, Felipe Balbi <balbi@ti.com> wrote:
> by adding the missing MODULE_ALIAS(), cpufreq-dt
> can be autoloaded by udev/systemd.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/cpufreq/cpufreq-dt.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
@ 2015-05-09 2:29 ` Viresh Kumar
0 siblings, 0 replies; 28+ messages in thread
From: Viresh Kumar @ 2015-05-09 2:29 UTC (permalink / raw)
To: linux-arm-kernel
On 9 May 2015 at 01:27, Felipe Balbi <balbi@ti.com> wrote:
> by adding the missing MODULE_ALIAS(), cpufreq-dt
> can be autoloaded by udev/systemd.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/cpufreq/cpufreq-dt.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-08 20:24 ` Felipe Balbi
@ 2015-05-11 0:23 ` Nishanth Menon
-1 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-11 0:23 UTC (permalink / raw)
To: balbi
Cc: Tony Lindgren, Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm
On 05/08/2015 03:24 PM, Felipe Balbi wrote:
> On Fri, May 08, 2015 at 03:12:27PM -0500, Nishanth Menon wrote:
>> On 05/08/2015 03:09 PM, Nishanth Menon wrote:
>>> On 05/08/2015 02:57 PM, Felipe Balbi wrote:
>>>> By adding operating points, cpufreq-dt has a
>>>> chance of running and doing something useful.
>>>>
>>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>> ---
>>>> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>>>> index c80a3e233792..ea1db20f64fc 100644
>>>> --- a/arch/arm/boot/dts/am4372.dtsi
>>>> +++ b/arch/arm/boot/dts/am4372.dtsi
>>>> @@ -38,6 +38,15 @@
>>>> clocks = <&dpll_mpu_ck>;
>>>> clock-names = "cpu";
>>>>
>>>> + operating-points = <
>>>> + /* kHz uV */
>>>> + 1000000 1325000 /* OPP_NITRO */
>>>> + 800000 1260000 /* OPP_TURBO */
>>>> + 720000 1200000 /* OPP_120 */
>>>> + 600000 1100000 /* OPP_100 */
>>>> + 300000 950000 /* OPP_50 */
>>>> + >;
>>>> +
>>>> clock-latency = <300000>; /* From omap-cpufreq driver */
>>>> };
>>>> };
>>>>
>>> which of these OPPs need AVS? which of these are dependent on Efuse bit
>>> dependent?
>>>
>>
>>
>> You can use
>> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
>> for reference.
>
> heh, why isn't that upstream yet ? Seems to be ready already. The point
we have tried in the past[1] - unfortunately that was just bandaid since
the existing OPP device tree bindings have very limiting behavior across
multiple SoCs.This was one of the reasons why we stopped adding more
OPPs, since we are hoping to see the new bindings[2] which is under
discussion settle down and help enable support for cases like that we
have on TI SoCs, iMX SoCs etc.
> is that as of now, u-boot will set maximum OPP it can find and, for
> AM437x, that will be 800MHz or 1GHz depending on your board. 1GHz might
> not be supported in all SoCs and letting that be used all the time is
> likely going to reduce silicon lifetime.
> At least allowing ondemand governor run, we will be mostly running at
> 300MHz and only jump to "invalid" OPPs under load which, granted, is
> still not perfect, but better than running at 1GHz all the time, don't
> you agree ?
The fix for this should ideally be in u-boot - we are trying not to
introduce dts changes in the hopes that the new proposed bindings that
Viresh has on discussion comes to conclusion and help introduce new dtb
support with proper SoC description. allowing an SoC to enter an invalid
OPP is broken by design. we must attempt to curb it. unfortunately, we
already do have a broken implementation for AM335x, DRA7 in place which
went with the assumption that we will be able to do modifiers on top of
existing dt description and the hopes that [1] will eventually get
upstream. But, as is clear now, [1] has no future path in upstream
kernel. following the same broken path for newer SoC definitions will
probably very short sighted by us.
in my opinion, doing a temporary hack in upstream kernel is not an
elegant approach. I suggest helping review and approving Viresh's new
bindings so that we have a longer term solution is more the way to do this.
Just my 2 cents. Thanks once again for identifying the urgent need for
helping Viresh's series along - will be great if folks could help review
and approve his series to get them upstream and help all of us ARM SoC
variations along.
[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/309466
[2] http://marc.info/?l=devicetree&m=143039569104090&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-11 0:23 ` Nishanth Menon
0 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-11 0:23 UTC (permalink / raw)
To: linux-arm-kernel
On 05/08/2015 03:24 PM, Felipe Balbi wrote:
> On Fri, May 08, 2015 at 03:12:27PM -0500, Nishanth Menon wrote:
>> On 05/08/2015 03:09 PM, Nishanth Menon wrote:
>>> On 05/08/2015 02:57 PM, Felipe Balbi wrote:
>>>> By adding operating points, cpufreq-dt has a
>>>> chance of running and doing something useful.
>>>>
>>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>> ---
>>>> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>>>> index c80a3e233792..ea1db20f64fc 100644
>>>> --- a/arch/arm/boot/dts/am4372.dtsi
>>>> +++ b/arch/arm/boot/dts/am4372.dtsi
>>>> @@ -38,6 +38,15 @@
>>>> clocks = <&dpll_mpu_ck>;
>>>> clock-names = "cpu";
>>>>
>>>> + operating-points = <
>>>> + /* kHz uV */
>>>> + 1000000 1325000 /* OPP_NITRO */
>>>> + 800000 1260000 /* OPP_TURBO */
>>>> + 720000 1200000 /* OPP_120 */
>>>> + 600000 1100000 /* OPP_100 */
>>>> + 300000 950000 /* OPP_50 */
>>>> + >;
>>>> +
>>>> clock-latency = <300000>; /* From omap-cpufreq driver */
>>>> };
>>>> };
>>>>
>>> which of these OPPs need AVS? which of these are dependent on Efuse bit
>>> dependent?
>>>
>>
>>
>> You can use
>> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
>> for reference.
>
> heh, why isn't that upstream yet ? Seems to be ready already. The point
we have tried in the past[1] - unfortunately that was just bandaid since
the existing OPP device tree bindings have very limiting behavior across
multiple SoCs.This was one of the reasons why we stopped adding more
OPPs, since we are hoping to see the new bindings[2] which is under
discussion settle down and help enable support for cases like that we
have on TI SoCs, iMX SoCs etc.
> is that as of now, u-boot will set maximum OPP it can find and, for
> AM437x, that will be 800MHz or 1GHz depending on your board. 1GHz might
> not be supported in all SoCs and letting that be used all the time is
> likely going to reduce silicon lifetime.
> At least allowing ondemand governor run, we will be mostly running at
> 300MHz and only jump to "invalid" OPPs under load which, granted, is
> still not perfect, but better than running at 1GHz all the time, don't
> you agree ?
The fix for this should ideally be in u-boot - we are trying not to
introduce dts changes in the hopes that the new proposed bindings that
Viresh has on discussion comes to conclusion and help introduce new dtb
support with proper SoC description. allowing an SoC to enter an invalid
OPP is broken by design. we must attempt to curb it. unfortunately, we
already do have a broken implementation for AM335x, DRA7 in place which
went with the assumption that we will be able to do modifiers on top of
existing dt description and the hopes that [1] will eventually get
upstream. But, as is clear now, [1] has no future path in upstream
kernel. following the same broken path for newer SoC definitions will
probably very short sighted by us.
in my opinion, doing a temporary hack in upstream kernel is not an
elegant approach. I suggest helping review and approving Viresh's new
bindings so that we have a longer term solution is more the way to do this.
Just my 2 cents. Thanks once again for identifying the urgent need for
helping Viresh's series along - will be great if folks could help review
and approve his series to get them upstream and help all of us ARM SoC
variations along.
[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/309466
[2] http://marc.info/?l=devicetree&m=143039569104090&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-11 0:23 ` Nishanth Menon
@ 2015-05-11 15:19 ` Felipe Balbi
-1 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-11 15:19 UTC (permalink / raw)
To: Nishanth Menon
Cc: balbi, Tony Lindgren, Rob Herring, Mark Rutland, rjw,
Viresh Kumar, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-pm
[-- Attachment #1: Type: text/plain, Size: 4586 bytes --]
Hi,
On Sun, May 10, 2015 at 07:23:34PM -0500, Nishanth Menon wrote:
> On 05/08/2015 03:24 PM, Felipe Balbi wrote:
> > On Fri, May 08, 2015 at 03:12:27PM -0500, Nishanth Menon wrote:
> >> On 05/08/2015 03:09 PM, Nishanth Menon wrote:
> >>> On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> >>>> By adding operating points, cpufreq-dt has a
> >>>> chance of running and doing something useful.
> >>>>
> >>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >>>> ---
> >>>> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
> >>>> 1 file changed, 9 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> >>>> index c80a3e233792..ea1db20f64fc 100644
> >>>> --- a/arch/arm/boot/dts/am4372.dtsi
> >>>> +++ b/arch/arm/boot/dts/am4372.dtsi
> >>>> @@ -38,6 +38,15 @@
> >>>> clocks = <&dpll_mpu_ck>;
> >>>> clock-names = "cpu";
> >>>>
> >>>> + operating-points = <
> >>>> + /* kHz uV */
> >>>> + 1000000 1325000 /* OPP_NITRO */
> >>>> + 800000 1260000 /* OPP_TURBO */
> >>>> + 720000 1200000 /* OPP_120 */
> >>>> + 600000 1100000 /* OPP_100 */
> >>>> + 300000 950000 /* OPP_50 */
> >>>> + >;
> >>>> +
> >>>> clock-latency = <300000>; /* From omap-cpufreq driver */
> >>>> };
> >>>> };
> >>>>
> >>> which of these OPPs need AVS? which of these are dependent on Efuse bit
> >>> dependent?
> >>>
> >>
> >>
> >> You can use
> >> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
> >> for reference.
> >
> > heh, why isn't that upstream yet ? Seems to be ready already. The point
>
> we have tried in the past[1] - unfortunately that was just bandaid since
> the existing OPP device tree bindings have very limiting behavior across
> multiple SoCs.This was one of the reasons why we stopped adding more
> OPPs, since we are hoping to see the new bindings[2] which is under
> discussion settle down and help enable support for cases like that we
> have on TI SoCs, iMX SoCs etc.
fair enough.
> > is that as of now, u-boot will set maximum OPP it can find and, for
> > AM437x, that will be 800MHz or 1GHz depending on your board. 1GHz might
> > not be supported in all SoCs and letting that be used all the time is
> > likely going to reduce silicon lifetime.
>
> > At least allowing ondemand governor run, we will be mostly running at
> > 300MHz and only jump to "invalid" OPPs under load which, granted, is
> > still not perfect, but better than running at 1GHz all the time, don't
> > you agree ?
> The fix for this should ideally be in u-boot - we are trying not to
right, ideally, yeah; but then we go back to the discussion regarding
kernel vs bootloader dependencies :-)
> introduce dts changes in the hopes that the new proposed bindings that
> Viresh has on discussion comes to conclusion and help introduce new dtb
> support with proper SoC description. allowing an SoC to enter an invalid
> OPP is broken by design. we must attempt to curb it. unfortunately, we
> already do have a broken implementation for AM335x, DRA7 in place which
> went with the assumption that we will be able to do modifiers on top of
> existing dt description and the hopes that [1] will eventually get
> upstream. But, as is clear now, [1] has no future path in upstream
> kernel. following the same broken path for newer SoC definitions will
> probably very short sighted by us.
>
> in my opinion, doing a temporary hack in upstream kernel is not an
> elegant approach. I suggest helping review and approving Viresh's new
however this is not a hack, right ? If we get rid of OPP_NITRO and
OPP_TURBO, then we will more than likely always be dealing with safe
OPPs (yeah, I need to confirm this since it's not on public TRM, so as
of now, take this statement with a grain of salt :-), moreover, even
though we're trying to change opp bindings, the current situation is
still very much accepted and will remain valid even after changing
binding :-)
Not to mention that people using AM43xx today might be using it under
invalid OPPs and decreasing silicon life; I'd assume that's a very
urgent detail to sort out.
> bindings so that we have a longer term solution is more the way to do this.
>
> Just my 2 cents. Thanks once again for identifying the urgent need for
> helping Viresh's series along - will be great if folks could help review
> and approve his series to get them upstream and help all of us ARM SoC
> variations along.
np.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-11 15:19 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-11 15:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Sun, May 10, 2015 at 07:23:34PM -0500, Nishanth Menon wrote:
> On 05/08/2015 03:24 PM, Felipe Balbi wrote:
> > On Fri, May 08, 2015 at 03:12:27PM -0500, Nishanth Menon wrote:
> >> On 05/08/2015 03:09 PM, Nishanth Menon wrote:
> >>> On 05/08/2015 02:57 PM, Felipe Balbi wrote:
> >>>> By adding operating points, cpufreq-dt has a
> >>>> chance of running and doing something useful.
> >>>>
> >>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >>>> ---
> >>>> arch/arm/boot/dts/am4372.dtsi | 9 +++++++++
> >>>> 1 file changed, 9 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> >>>> index c80a3e233792..ea1db20f64fc 100644
> >>>> --- a/arch/arm/boot/dts/am4372.dtsi
> >>>> +++ b/arch/arm/boot/dts/am4372.dtsi
> >>>> @@ -38,6 +38,15 @@
> >>>> clocks = <&dpll_mpu_ck>;
> >>>> clock-names = "cpu";
> >>>>
> >>>> + operating-points = <
> >>>> + /* kHz uV */
> >>>> + 1000000 1325000 /* OPP_NITRO */
> >>>> + 800000 1260000 /* OPP_TURBO */
> >>>> + 720000 1200000 /* OPP_120 */
> >>>> + 600000 1100000 /* OPP_100 */
> >>>> + 300000 950000 /* OPP_50 */
> >>>> + >;
> >>>> +
> >>>> clock-latency = <300000>; /* From omap-cpufreq driver */
> >>>> };
> >>>> };
> >>>>
> >>> which of these OPPs need AVS? which of these are dependent on Efuse bit
> >>> dependent?
> >>>
> >>
> >>
> >> You can use
> >> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-3.14.y/arch/arm/mach-omap2/opp43xx_data.c
> >> for reference.
> >
> > heh, why isn't that upstream yet ? Seems to be ready already. The point
>
> we have tried in the past[1] - unfortunately that was just bandaid since
> the existing OPP device tree bindings have very limiting behavior across
> multiple SoCs.This was one of the reasons why we stopped adding more
> OPPs, since we are hoping to see the new bindings[2] which is under
> discussion settle down and help enable support for cases like that we
> have on TI SoCs, iMX SoCs etc.
fair enough.
> > is that as of now, u-boot will set maximum OPP it can find and, for
> > AM437x, that will be 800MHz or 1GHz depending on your board. 1GHz might
> > not be supported in all SoCs and letting that be used all the time is
> > likely going to reduce silicon lifetime.
>
> > At least allowing ondemand governor run, we will be mostly running at
> > 300MHz and only jump to "invalid" OPPs under load which, granted, is
> > still not perfect, but better than running at 1GHz all the time, don't
> > you agree ?
> The fix for this should ideally be in u-boot - we are trying not to
right, ideally, yeah; but then we go back to the discussion regarding
kernel vs bootloader dependencies :-)
> introduce dts changes in the hopes that the new proposed bindings that
> Viresh has on discussion comes to conclusion and help introduce new dtb
> support with proper SoC description. allowing an SoC to enter an invalid
> OPP is broken by design. we must attempt to curb it. unfortunately, we
> already do have a broken implementation for AM335x, DRA7 in place which
> went with the assumption that we will be able to do modifiers on top of
> existing dt description and the hopes that [1] will eventually get
> upstream. But, as is clear now, [1] has no future path in upstream
> kernel. following the same broken path for newer SoC definitions will
> probably very short sighted by us.
>
> in my opinion, doing a temporary hack in upstream kernel is not an
> elegant approach. I suggest helping review and approving Viresh's new
however this is not a hack, right ? If we get rid of OPP_NITRO and
OPP_TURBO, then we will more than likely always be dealing with safe
OPPs (yeah, I need to confirm this since it's not on public TRM, so as
of now, take this statement with a grain of salt :-), moreover, even
though we're trying to change opp bindings, the current situation is
still very much accepted and will remain valid even after changing
binding :-)
Not to mention that people using AM43xx today might be using it under
invalid OPPs and decreasing silicon life; I'd assume that's a very
urgent detail to sort out.
> bindings so that we have a longer term solution is more the way to do this.
>
> Just my 2 cents. Thanks once again for identifying the urgent need for
> helping Viresh's series along - will be great if folks could help review
> and approve his series to get them upstream and help all of us ARM SoC
> variations along.
np.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150511/c2b9f3dd/attachment.sig>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-11 15:19 ` Felipe Balbi
@ 2015-05-11 16:46 ` Nishanth Menon
-1 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-11 16:46 UTC (permalink / raw)
To: Balbi, Felipe
Cc: Mark Rutland, linux-pm, Tony Lindgren, Viresh Kumar, rjw,
Rob Herring, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List
On Mon, May 11, 2015 at 10:19 AM, Felipe Balbi <balbi@ti.com> wrote:
>
>> in my opinion, doing a temporary hack in upstream kernel is not an
>> elegant approach. I suggest helping review and approving Viresh's new
>
> however this is not a hack, right ? If we get rid of OPP_NITRO and
> OPP_TURBO, then we will more than likely always be dealing with safe
> OPPs (yeah, I need to confirm this since it's not on public TRM, so as
> of now, take this statement with a grain of salt :-), moreover, even
> though we're trying to change opp bindings, the current situation is
> still very much accepted and will remain valid even after changing
> binding :-)
yes - if we do have a documented subset of OPPs that are valid for all
"variants" of AM437x, we could add that in using the legacy bindings,
but, we will have to do a transition over to the new bindings when
they are finalized to support all OPPs appropriately.
> Not to mention that people using AM43xx today might be using it under
> invalid OPPs and decreasing silicon life; I'd assume that's a very
> urgent detail to sort out.
While I do agree that there is always a debate between fixing things
in kernel for bootloader issues, but it does not mean that we should
just postpone fixing the bootloader in this case - since, at this very
moment, we are already in broken configuration - example sitting on a
bootloader shell does have the same impact we have at this time.
Lets try to help Viresh in getting his series sorted out meanwhile -
maybe others can help as well :(
---
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-11 16:46 ` Nishanth Menon
0 siblings, 0 replies; 28+ messages in thread
From: Nishanth Menon @ 2015-05-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 11, 2015 at 10:19 AM, Felipe Balbi <balbi@ti.com> wrote:
>
>> in my opinion, doing a temporary hack in upstream kernel is not an
>> elegant approach. I suggest helping review and approving Viresh's new
>
> however this is not a hack, right ? If we get rid of OPP_NITRO and
> OPP_TURBO, then we will more than likely always be dealing with safe
> OPPs (yeah, I need to confirm this since it's not on public TRM, so as
> of now, take this statement with a grain of salt :-), moreover, even
> though we're trying to change opp bindings, the current situation is
> still very much accepted and will remain valid even after changing
> binding :-)
yes - if we do have a documented subset of OPPs that are valid for all
"variants" of AM437x, we could add that in using the legacy bindings,
but, we will have to do a transition over to the new bindings when
they are finalized to support all OPPs appropriately.
> Not to mention that people using AM43xx today might be using it under
> invalid OPPs and decreasing silicon life; I'd assume that's a very
> urgent detail to sort out.
While I do agree that there is always a debate between fixing things
in kernel for bootloader issues, but it does not mean that we should
just postpone fixing the bootloader in this case - since, at this very
moment, we are already in broken configuration - example sitting on a
bootloader shell does have the same impact we have at this time.
Lets try to help Viresh in getting his series sorted out meanwhile -
maybe others can help as well :(
---
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points
2015-05-11 16:46 ` Nishanth Menon
@ 2015-05-11 17:02 ` Felipe Balbi
-1 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-11 17:02 UTC (permalink / raw)
To: Nishanth Menon
Cc: Balbi, Felipe, Mark Rutland, linux-pm, Tony Lindgren,
Viresh Kumar, rjw, Rob Herring, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
HI,
On Mon, May 11, 2015 at 11:46:13AM -0500, Nishanth Menon wrote:
> On Mon, May 11, 2015 at 10:19 AM, Felipe Balbi <balbi@ti.com> wrote:
> >
> >> in my opinion, doing a temporary hack in upstream kernel is not an
> >> elegant approach. I suggest helping review and approving Viresh's new
> >
> > however this is not a hack, right ? If we get rid of OPP_NITRO and
> > OPP_TURBO, then we will more than likely always be dealing with safe
> > OPPs (yeah, I need to confirm this since it's not on public TRM, so as
> > of now, take this statement with a grain of salt :-), moreover, even
> > though we're trying to change opp bindings, the current situation is
> > still very much accepted and will remain valid even after changing
> > binding :-)
>
> yes - if we do have a documented subset of OPPs that are valid for all
> "variants" of AM437x, we could add that in using the legacy bindings,
> but, we will have to do a transition over to the new bindings when
> they are finalized to support all OPPs appropriately.
sounds fair to me.
> > Not to mention that people using AM43xx today might be using it under
> > invalid OPPs and decreasing silicon life; I'd assume that's a very
> > urgent detail to sort out.
>
> While I do agree that there is always a debate between fixing things
> in kernel for bootloader issues, but it does not mean that we should
> just postpone fixing the bootloader in this case - since, at this very
> moment, we are already in broken configuration - example sitting on a
> bootloader shell does have the same impact we have at this time.
agreed, I'll cook up a patch for bootloader too.
> Lets try to help Viresh in getting his series sorted out meanwhile -
> maybe others can help as well :(
sure.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/2] arm: boot: dts: am4372: add operating points
@ 2015-05-11 17:02 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-05-11 17:02 UTC (permalink / raw)
To: linux-arm-kernel
HI,
On Mon, May 11, 2015 at 11:46:13AM -0500, Nishanth Menon wrote:
> On Mon, May 11, 2015 at 10:19 AM, Felipe Balbi <balbi@ti.com> wrote:
> >
> >> in my opinion, doing a temporary hack in upstream kernel is not an
> >> elegant approach. I suggest helping review and approving Viresh's new
> >
> > however this is not a hack, right ? If we get rid of OPP_NITRO and
> > OPP_TURBO, then we will more than likely always be dealing with safe
> > OPPs (yeah, I need to confirm this since it's not on public TRM, so as
> > of now, take this statement with a grain of salt :-), moreover, even
> > though we're trying to change opp bindings, the current situation is
> > still very much accepted and will remain valid even after changing
> > binding :-)
>
> yes - if we do have a documented subset of OPPs that are valid for all
> "variants" of AM437x, we could add that in using the legacy bindings,
> but, we will have to do a transition over to the new bindings when
> they are finalized to support all OPPs appropriately.
sounds fair to me.
> > Not to mention that people using AM43xx today might be using it under
> > invalid OPPs and decreasing silicon life; I'd assume that's a very
> > urgent detail to sort out.
>
> While I do agree that there is always a debate between fixing things
> in kernel for bootloader issues, but it does not mean that we should
> just postpone fixing the bootloader in this case - since, at this very
> moment, we are already in broken configuration - example sitting on a
> bootloader shell does have the same impact we have at this time.
agreed, I'll cook up a patch for bootloader too.
> Lets try to help Viresh in getting his series sorted out meanwhile -
> maybe others can help as well :(
sure.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150511/b970e4dc/attachment.sig>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
2015-05-08 19:57 ` Felipe Balbi
@ 2015-06-16 21:40 ` Felipe Balbi
-1 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-06-16 21:40 UTC (permalink / raw)
To: Felipe Balbi
Cc: Tony Lindgren, Rob Herring, Mark Rutland, rjw, Viresh Kumar,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List, linux-pm
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
> by adding the missing MODULE_ALIAS(), cpufreq-dt
> can be autoloaded by udev/systemd.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
looks like this wasn't applied anywhere. Viresh, can you apply this
patch please ?
> ---
> drivers/cpufreq/cpufreq-dt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index bab67db54b7e..528a82bf5038 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
> };
> module_platform_driver(dt_cpufreq_platdrv);
>
> +MODULE_ALIAS("platform:cpufreq-dt");
> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> MODULE_DESCRIPTION("Generic cpufreq driver");
> --
> 2.4.0.rc3
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
@ 2015-06-16 21:40 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-06-16 21:40 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
> by adding the missing MODULE_ALIAS(), cpufreq-dt
> can be autoloaded by udev/systemd.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
looks like this wasn't applied anywhere. Viresh, can you apply this
patch please ?
> ---
> drivers/cpufreq/cpufreq-dt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index bab67db54b7e..528a82bf5038 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
> };
> module_platform_driver(dt_cpufreq_platdrv);
>
> +MODULE_ALIAS("platform:cpufreq-dt");
> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> MODULE_DESCRIPTION("Generic cpufreq driver");
> --
> 2.4.0.rc3
>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150616/83a6496d/attachment.sig>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
2015-06-16 21:40 ` Felipe Balbi
@ 2015-06-16 22:04 ` Rafael J. Wysocki
-1 siblings, 0 replies; 28+ messages in thread
From: Rafael J. Wysocki @ 2015-06-16 22:04 UTC (permalink / raw)
To: Felipe Balbi
Cc: Tony Lindgren, Rob Herring, Mark Rutland, Rafael J. Wysocki,
Viresh Kumar, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-pm
On Tue, Jun 16, 2015 at 11:40 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
>> by adding the missing MODULE_ALIAS(), cpufreq-dt
>> can be autoloaded by udev/systemd.
>>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>
> looks like this wasn't applied anywhere. Viresh, can you apply this
> patch please ?
I've overlooked it, sorry about that. Applied now, thanks!
>> ---
>> drivers/cpufreq/cpufreq-dt.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
>> index bab67db54b7e..528a82bf5038 100644
>> --- a/drivers/cpufreq/cpufreq-dt.c
>> +++ b/drivers/cpufreq/cpufreq-dt.c
>> @@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
>> };
>> module_platform_driver(dt_cpufreq_platdrv);
>>
>> +MODULE_ALIAS("platform:cpufreq-dt");
>> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
>> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
>> MODULE_DESCRIPTION("Generic cpufreq driver");
>> --
>> 2.4.0.rc3
>>
>
> --
> balbi
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
@ 2015-06-16 22:04 ` Rafael J. Wysocki
0 siblings, 0 replies; 28+ messages in thread
From: Rafael J. Wysocki @ 2015-06-16 22:04 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 16, 2015 at 11:40 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
>> by adding the missing MODULE_ALIAS(), cpufreq-dt
>> can be autoloaded by udev/systemd.
>>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>
> looks like this wasn't applied anywhere. Viresh, can you apply this
> patch please ?
I've overlooked it, sorry about that. Applied now, thanks!
>> ---
>> drivers/cpufreq/cpufreq-dt.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
>> index bab67db54b7e..528a82bf5038 100644
>> --- a/drivers/cpufreq/cpufreq-dt.c
>> +++ b/drivers/cpufreq/cpufreq-dt.c
>> @@ -416,6 +416,7 @@ static struct platform_driver dt_cpufreq_platdrv = {
>> };
>> module_platform_driver(dt_cpufreq_platdrv);
>>
>> +MODULE_ALIAS("platform:cpufreq-dt");
>> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
>> MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
>> MODULE_DESCRIPTION("Generic cpufreq driver");
>> --
>> 2.4.0.rc3
>>
>
> --
> balbi
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
2015-06-16 22:04 ` Rafael J. Wysocki
@ 2015-06-16 22:08 ` Felipe Balbi
-1 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-06-16 22:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Felipe Balbi, Tony Lindgren, Rob Herring, Mark Rutland,
Rafael J. Wysocki, Viresh Kumar, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-pm
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On Wed, Jun 17, 2015 at 12:04:07AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 16, 2015 at 11:40 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
> >> by adding the missing MODULE_ALIAS(), cpufreq-dt
> >> can be autoloaded by udev/systemd.
> >>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >
> > looks like this wasn't applied anywhere. Viresh, can you apply this
> > patch please ?
>
> I've overlooked it, sorry about that. Applied now, thanks!
Thanks Rafael.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 2/2] cpufreq: dt: allow driver to boot automatically
@ 2015-06-16 22:08 ` Felipe Balbi
0 siblings, 0 replies; 28+ messages in thread
From: Felipe Balbi @ 2015-06-16 22:08 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 17, 2015 at 12:04:07AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 16, 2015 at 11:40 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
> >> by adding the missing MODULE_ALIAS(), cpufreq-dt
> >> can be autoloaded by udev/systemd.
> >>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >
> > looks like this wasn't applied anywhere. Viresh, can you apply this
> > patch please ?
>
> I've overlooked it, sorry about that. Applied now, thanks!
Thanks Rafael.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150616/de9514a8/attachment-0001.sig>
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2015-06-16 22:08 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-08 19:57 [PATCH 1/2] arm: boot: dts: am4372: add operating points Felipe Balbi
2015-05-08 19:57 ` Felipe Balbi
2015-05-08 19:57 ` [PATCH 2/2] cpufreq: dt: allow driver to boot automatically Felipe Balbi
2015-05-08 19:57 ` Felipe Balbi
2015-05-08 20:16 ` Nishanth Menon
2015-05-08 20:16 ` Nishanth Menon
2015-05-09 2:29 ` Viresh Kumar
2015-05-09 2:29 ` Viresh Kumar
2015-06-16 21:40 ` Felipe Balbi
2015-06-16 21:40 ` Felipe Balbi
2015-06-16 22:04 ` Rafael J. Wysocki
2015-06-16 22:04 ` Rafael J. Wysocki
2015-06-16 22:08 ` Felipe Balbi
2015-06-16 22:08 ` Felipe Balbi
2015-05-08 20:09 ` [PATCH 1/2] arm: boot: dts: am4372: add operating points Nishanth Menon
2015-05-08 20:09 ` Nishanth Menon
2015-05-08 20:12 ` Nishanth Menon
2015-05-08 20:12 ` Nishanth Menon
2015-05-08 20:24 ` Felipe Balbi
2015-05-08 20:24 ` Felipe Balbi
2015-05-11 0:23 ` Nishanth Menon
2015-05-11 0:23 ` Nishanth Menon
2015-05-11 15:19 ` Felipe Balbi
2015-05-11 15:19 ` Felipe Balbi
2015-05-11 16:46 ` Nishanth Menon
2015-05-11 16:46 ` Nishanth Menon
2015-05-11 17:02 ` Felipe Balbi
2015-05-11 17:02 ` Felipe Balbi
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.