Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[PATCH 3/3] ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies
30 views
Skip to first unread message
Nishanth Menon
May 16, 2014, 6:50:02 AM5/16/14
to
OMAP5432, DRA75x and DRA72x have MPU DPLLs that need Duty Cycle
Correction(DCC) to operate safely at frequencies >= 1.4GHz.
Switch to "ti,omap5-mpu-dpll-clock" compatible property which provides
this support.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..aac5522 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -277,7 +277,7 @@
dpll_mpu_ck: dpll_mpu_ck {
#clock-cells = <0>;
- compatible = "ti,omap4-dpll-clock";
+ compatible = "ti,omap5-mpu-dpll-clock";
clocks = <&sys_clkin1>, <&mpu_dpll_hs_clk_div>;
reg = <0x0160>, <0x0164>, <0x016c>, <0x0168>;
};
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fda..465505c 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -362,7 +362,7 @@
dpll_mpu_ck: dpll_mpu_ck {
#clock-cells = <0>;
- compatible = "ti,omap4-dpll-clock";
+ compatible = "ti,omap5-mpu-dpll-clock";
clocks = <&sys_clkin>, <&mpu_dpll_hs_clk_div>;
reg = <0x0160>, <0x0164>, <0x016c>, <0x0168>;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Correction(DCC) to operate safely at frequencies >= 1.4GHz.
Switch to "ti,omap5-mpu-dpll-clock" compatible property which provides
this support.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..aac5522 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -277,7 +277,7 @@
dpll_mpu_ck: dpll_mpu_ck {
#clock-cells = <0>;
- compatible = "ti,omap4-dpll-clock";
+ compatible = "ti,omap5-mpu-dpll-clock";
clocks = <&sys_clkin1>, <&mpu_dpll_hs_clk_div>;
reg = <0x0160>, <0x0164>, <0x016c>, <0x0168>;
};
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fda..465505c 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -362,7 +362,7 @@
dpll_mpu_ck: dpll_mpu_ck {
#clock-cells = <0>;
- compatible = "ti,omap4-dpll-clock";
+ compatible = "ti,omap5-mpu-dpll-clock";
clocks = <&sys_clkin>, <&mpu_dpll_hs_clk_div>;
reg = <0x0160>, <0x0164>, <0x016c>, <0x0168>;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nishanth Menon
May 16, 2014, 6:50:02 AM5/16/14
to
From: Andrii Tseglytskyi <andrii.ts...@ti.com>
Duty Cycle Correction(DCC) needs to be enabled if the MPU is to run at
frequencies beyond 1.4GHz for OMAP5, DRA75x, DRA72x.
MPU DPLL has a limitation on the maximum frequency it can be locked
at. Duty Cycle Correction circuit is used to recover a correct duty
cycle for achieving higher frequencies (hardware internally switches
output to M3 output(CLKOUTHIF) from M2 output (CLKOUT)).
For further information, See the note on OMAP5432 Technical Reference
Manual(SWPU282U) chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters",
and also the "OMAP543x ES2.0 DM Operating Conditions Addendum v0.5"
chapter 2.1 "Micro Processor Unit (MPU)". Equivalent information is
present in relevant DRA75x, 72x documentation(SPRUHP2E, SPRUHI2P).
Signed-off-by: Andrii Tseglytskyi <andrii.ts...@ti.com>
Signed-off-by: Taras Kondratiuk <ta...@ti.com>
Signed-off-by: J Keerthy <j-ke...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
[t-kr...@ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo <t-kr...@ti.com>
---
arch/arm/mach-omap2/dpll3xxx.c | 9 +++++++++
include/linux/clk/ti.h | 4 ++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fcd8036..6d7ba37 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -319,6 +319,15 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap *clk, u16 freqsel)
/* Set DPLL multiplier, divider */
v = omap2_clk_readl(clk, dd->mult_div1_reg);
+
+ /* Handle Duty Cycle Correction */
+ if (dd->dcc_mask) {
+ if (dd->last_rounded_rate >= dd->dcc_rate)
+ v |= dd->dcc_mask; /* Enable DCC */
+ else
+ v &= ~dd->dcc_mask; /* Disable DCC */
+ }
+
v &= ~(dd->mult_mask | dd->div1_mask);
v |= dd->last_rounded_m << __ffs(dd->mult_mask);
v |= (dd->last_rounded_n - 1) << __ffs(dd->div1_mask);
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 4a21a87..1f5c55e 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -41,6 +41,8 @@
* @idlest_reg: register containing the DPLL idle status bitfield
* @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
* @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
+ * @dcc_mask: mask of the DPLL DCC correction bitfield @mult_div1_reg
+ * @dcc_rate: rate atleast which DCC @dcc_mask must be set
* @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
* @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
* @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
@@ -86,6 +88,8 @@ struct dpll_data {
u32 idlest_mask;
u32 dco_mask;
u32 sddiv_mask;
+ u32 dcc_mask;
+ unsigned long dcc_rate;
u32 lpmode_mask;
u32 m4xen_mask;
u8 auto_recal_bit;
Duty Cycle Correction(DCC) needs to be enabled if the MPU is to run at
frequencies beyond 1.4GHz for OMAP5, DRA75x, DRA72x.
MPU DPLL has a limitation on the maximum frequency it can be locked
at. Duty Cycle Correction circuit is used to recover a correct duty
cycle for achieving higher frequencies (hardware internally switches
output to M3 output(CLKOUTHIF) from M2 output (CLKOUT)).
For further information, See the note on OMAP5432 Technical Reference
Manual(SWPU282U) chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters",
and also the "OMAP543x ES2.0 DM Operating Conditions Addendum v0.5"
chapter 2.1 "Micro Processor Unit (MPU)". Equivalent information is
present in relevant DRA75x, 72x documentation(SPRUHP2E, SPRUHI2P).
Signed-off-by: Andrii Tseglytskyi <andrii.ts...@ti.com>
Signed-off-by: Taras Kondratiuk <ta...@ti.com>
Signed-off-by: J Keerthy <j-ke...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
[t-kr...@ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo <t-kr...@ti.com>
---
arch/arm/mach-omap2/dpll3xxx.c | 9 +++++++++
include/linux/clk/ti.h | 4 ++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fcd8036..6d7ba37 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -319,6 +319,15 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap *clk, u16 freqsel)
/* Set DPLL multiplier, divider */
v = omap2_clk_readl(clk, dd->mult_div1_reg);
+
+ /* Handle Duty Cycle Correction */
+ if (dd->dcc_mask) {
+ if (dd->last_rounded_rate >= dd->dcc_rate)
+ v |= dd->dcc_mask; /* Enable DCC */
+ else
+ v &= ~dd->dcc_mask; /* Disable DCC */
+ }
+
v &= ~(dd->mult_mask | dd->div1_mask);
v |= dd->last_rounded_m << __ffs(dd->mult_mask);
v |= (dd->last_rounded_n - 1) << __ffs(dd->div1_mask);
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 4a21a87..1f5c55e 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -41,6 +41,8 @@
* @idlest_reg: register containing the DPLL idle status bitfield
* @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
* @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
+ * @dcc_mask: mask of the DPLL DCC correction bitfield @mult_div1_reg
+ * @dcc_rate: rate atleast which DCC @dcc_mask must be set
* @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
* @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
* @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
@@ -86,6 +88,8 @@ struct dpll_data {
u32 idlest_mask;
u32 dco_mask;
u32 sddiv_mask;
+ u32 dcc_mask;
+ unsigned long dcc_rate;
u32 lpmode_mask;
u32 m4xen_mask;
u8 auto_recal_bit;
Nishanth Menon
May 16, 2014, 6:50:02 AM5/16/14
to
MPU DPLL on OMAP5, DRA75x, DRA72x has a limitation on the maximum
the setting up the minimum frequency for DPLL. 1.4GHz is common
for all these devices and is based on Technical Reference Manual
information for OMAP5432((SWPU282U) chapter 3.6.3.3.1 "DPLLs Output
Clocks Parameters", and equivalent information from DRA75x, DRA72x
documentation(SPRUHP2E, SPRUHI2P).
.../devicetree/bindings/clock/ti/dpll.txt | 1 +
drivers/clk/ti/dpll.c | 21 ++++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index 30bfdb7..a4d0723 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -24,6 +24,7 @@ Required properties:
"ti,omap4-dpll-core-clock",
"ti,omap4-dpll-m4xen-clock",
"ti,omap4-dpll-j-type-clock",
+ "ti,omap5-mpu-dpll-clock",
"ti,am3-dpll-no-gate-clock",
"ti,am3-dpll-j-type-clock",
"ti,am3-dpll-no-gate-j-type-clock",
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a4..c06e94a 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -396,6 +396,27 @@ static void __init of_ti_omap4_dpll_setup(struct device_node *node)
CLK_OF_DECLARE(ti_omap4_dpll_clock, "ti,omap4-dpll-clock",
of_ti_omap4_dpll_setup);
+static void __init of_ti_omap5_mpu_dpll_setup(struct device_node *node)
+{
+ const struct dpll_data dd = {
+ .idlest_mask = 0x1,
+ .enable_mask = 0x7,
+ .autoidle_mask = 0x7,
+ .mult_mask = 0x7ff << 8,
+ .div1_mask = 0x7f,
+ .max_multiplier = 2047,
+ .max_divider = 128,
+ .dcc_mask = BIT(22),
+ .dcc_rate = 1400000000, /* DCC beyond 1.4GHz */
+ .min_divider = 1,
+ .modes = (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
+ };
+
+ of_ti_dpll_setup(node, &dpll_ck_ops, &dd, DPLL_HAS_AUTOIDLE);
+}
+CLK_OF_DECLARE(of_ti_omap5_mpu_dpll_clock, "ti,omap5-mpu-dpll-clock",
+ of_ti_omap5_mpu_dpll_setup);
+
static void __init of_ti_omap4_core_dpll_setup(struct device_node *node)
{
const struct dpll_data dd = {
frequency it can be locked at. Duty Cycle Correction circuit is used
to recover a correct duty cycle for achieving higher frequencies
(hardware internally switches output to M3 output(CLKOUTHIF) from M2
output (CLKOUT)).
So provide support to setup required data to handle Duty cycle by
to recover a correct duty cycle for achieving higher frequencies
(hardware internally switches output to M3 output(CLKOUTHIF) from M2
output (CLKOUT)).
the setting up the minimum frequency for DPLL. 1.4GHz is common
for all these devices and is based on Technical Reference Manual
information for OMAP5432((SWPU282U) chapter 3.6.3.3.1 "DPLLs Output
Clocks Parameters", and equivalent information from DRA75x, DRA72x
documentation(SPRUHP2E, SPRUHI2P).
.../devicetree/bindings/clock/ti/dpll.txt | 1 +
drivers/clk/ti/dpll.c | 21 ++++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index 30bfdb7..a4d0723 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -24,6 +24,7 @@ Required properties:
"ti,omap4-dpll-core-clock",
"ti,omap4-dpll-m4xen-clock",
"ti,omap4-dpll-j-type-clock",
+ "ti,omap5-mpu-dpll-clock",
"ti,am3-dpll-no-gate-clock",
"ti,am3-dpll-j-type-clock",
"ti,am3-dpll-no-gate-j-type-clock",
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a4..c06e94a 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -396,6 +396,27 @@ static void __init of_ti_omap4_dpll_setup(struct device_node *node)
CLK_OF_DECLARE(ti_omap4_dpll_clock, "ti,omap4-dpll-clock",
of_ti_omap4_dpll_setup);
+static void __init of_ti_omap5_mpu_dpll_setup(struct device_node *node)
+{
+ const struct dpll_data dd = {
+ .idlest_mask = 0x1,
+ .enable_mask = 0x7,
+ .autoidle_mask = 0x7,
+ .mult_mask = 0x7ff << 8,
+ .div1_mask = 0x7f,
+ .max_multiplier = 2047,
+ .max_divider = 128,
+ .dcc_mask = BIT(22),
+ .dcc_rate = 1400000000, /* DCC beyond 1.4GHz */
+ .min_divider = 1,
+ .modes = (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
+ };
+
+ of_ti_dpll_setup(node, &dpll_ck_ops, &dd, DPLL_HAS_AUTOIDLE);
+}
+CLK_OF_DECLARE(of_ti_omap5_mpu_dpll_clock, "ti,omap5-mpu-dpll-clock",
+ of_ti_omap5_mpu_dpll_setup);
+
static void __init of_ti_omap4_core_dpll_setup(struct device_node *node)
{
const struct dpll_data dd = {
Nishanth Menon
May 16, 2014, 6:50:02 AM5/16/14
to
Hi,
This patch series has been carried over in vendor kernel for quiet
few years now.
Unfortunately, it was very recently re-discovered and upstream kernel
is noticed to be broken for OMAP5 1.5GHz - at least we are operating
DPLL at frequency higher than what it was intended to be when CPUFreq
is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
upstream for the mentioned platforms) and margins in trimming, we
have so far not crashed - but I strongly suspect this might be some
boundary case survival.
Verified on the following impacted platforms using 3.15-rc4 based
vendor kernel.
Before:
OMAP5432: http://slexy.org/view/s20cs0qQFg
DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock)
DRA75x: http://slexy.org/view/s20AW8MU5c
After:
OMAP5432: http://slexy.org/view/s21iAfWxpu
DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly)
DRA75x: http://slexy.org/view/s21ehw8WQn
Hopefully, we can get these into some kernel revision in some form.
NOTE: Support for 4470(which is the only other platform requiring
DCC) is not present in upstream kernel and there are no plans to
support that SoC, even if it is added at a later point, support can be
extended as needed.
Series based on v3.15-rc5 tag.
Also available on my tree:
https://github.com/nmenon/linux-2.6-playground/
branch: push/clock/dcc
weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc
Verification:
3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm
3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm)
Andrii Tseglytskyi (1):
ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC)
Nishanth Menon (2):
clk: dpll: support OMAP5 MPU DPLL that need special handling for
higher frequencies
ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing
with higher frequencies
.../devicetree/bindings/clock/ti/dpll.txt | 1 +
drivers/clk/ti/dpll.c | 21 ++++++++++++++++++++
include/linux/clk/ti.h | 4 ++++
6 files changed, 37 insertions(+), 2 deletions(-)
Regards,
Nishanth Menon
This patch series has been carried over in vendor kernel for quiet
few years now.
Unfortunately, it was very recently re-discovered and upstream kernel
is noticed to be broken for OMAP5 1.5GHz - at least we are operating
DPLL at frequency higher than what it was intended to be when CPUFreq
is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
upstream for the mentioned platforms) and margins in trimming, we
have so far not crashed - but I strongly suspect this might be some
boundary case survival.
Verified on the following impacted platforms using 3.15-rc4 based
vendor kernel.
Before:
OMAP5432: http://slexy.org/view/s20cs0qQFg
DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock)
DRA75x: http://slexy.org/view/s20AW8MU5c
After:
OMAP5432: http://slexy.org/view/s21iAfWxpu
DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly)
DRA75x: http://slexy.org/view/s21ehw8WQn
Hopefully, we can get these into some kernel revision in some form.
NOTE: Support for 4470(which is the only other platform requiring
DCC) is not present in upstream kernel and there are no plans to
support that SoC, even if it is added at a later point, support can be
extended as needed.
Series based on v3.15-rc5 tag.
Also available on my tree:
https://github.com/nmenon/linux-2.6-playground/
branch: push/clock/dcc
weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc
Verification:
3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm
3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm)
Andrii Tseglytskyi (1):
ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC)
Nishanth Menon (2):
clk: dpll: support OMAP5 MPU DPLL that need special handling for
higher frequencies
ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing
with higher frequencies
.../devicetree/bindings/clock/ti/dpll.txt | 1 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
arch/arm/mach-omap2/dpll3xxx.c | 9 +++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
drivers/clk/ti/dpll.c | 21 ++++++++++++++++++++
include/linux/clk/ti.h | 4 ++++
6 files changed, 37 insertions(+), 2 deletions(-)
Regards,
Nishanth Menon
Tero Kristo
May 23, 2014, 7:30:02 AM5/23/14
to
On 05/16/2014 01:45 PM, Nishanth Menon wrote:
> Hi,
>
> This patch series has been carried over in vendor kernel for quiet
> few years now.
>
> Unfortunately, it was very recently re-discovered and upstream kernel
> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
> DPLL at frequency higher than what it was intended to be when CPUFreq
> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
> upstream for the mentioned platforms) and margins in trimming, we
> have so far not crashed - but I strongly suspect this might be some
> boundary case survival.
>
> Verified on the following impacted platforms using 3.15-rc4 based
> vendor kernel.
>
> Before:
> OMAP5432: http://slexy.org/view/s20cs0qQFg
> DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock)
> DRA75x: http://slexy.org/view/s20AW8MU5c
> After:
> OMAP5432: http://slexy.org/view/s21iAfWxpu
> DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly)
> DRA75x: http://slexy.org/view/s21ehw8WQn
>
> Hopefully, we can get these into some kernel revision in some form.
Thanks, queued for 3.16/ti-clk-drv. Anybody on the delivery feel free to
> Hi,
>
> This patch series has been carried over in vendor kernel for quiet
> few years now.
>
> Unfortunately, it was very recently re-discovered and upstream kernel
> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
> DPLL at frequency higher than what it was intended to be when CPUFreq
> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
> upstream for the mentioned platforms) and margins in trimming, we
> have so far not crashed - but I strongly suspect this might be some
> boundary case survival.
>
> Verified on the following impacted platforms using 3.15-rc4 based
> vendor kernel.
>
> Before:
> OMAP5432: http://slexy.org/view/s20cs0qQFg
> DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock)
> DRA75x: http://slexy.org/view/s20AW8MU5c
> After:
> OMAP5432: http://slexy.org/view/s21iAfWxpu
> DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly)
> DRA75x: http://slexy.org/view/s21ehw8WQn
>
> Hopefully, we can get these into some kernel revision in some form.
yell if you got any complaints.
-Tero
Mike Turquette
May 23, 2014, 5:10:01 PM5/23/14
to
Quoting Nishanth Menon (2014-05-16 03:45:57)
cases we just ran the PLL way out of spec and the mpu_clk would divide
by 2.
Is this broken for OMAP4 as well?
Regards,
Mike
> Hi,
>
> This patch series has been carried over in vendor kernel for quiet
> few years now.
>
> Unfortunately, it was very recently re-discovered and upstream kernel
> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
> DPLL at frequency higher than what it was intended to be when CPUFreq
> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
> upstream for the mentioned platforms) and margins in trimming, we
> have so far not crashed - but I strongly suspect this might be some
> boundary case survival.
DCC also exists in OMAP4. In some cases customers used it, in other
>
> This patch series has been carried over in vendor kernel for quiet
> few years now.
>
> Unfortunately, it was very recently re-discovered and upstream kernel
> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
> DPLL at frequency higher than what it was intended to be when CPUFreq
> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
> upstream for the mentioned platforms) and margins in trimming, we
> have so far not crashed - but I strongly suspect this might be some
> boundary case survival.
cases we just ran the PLL way out of spec and the mpu_clk would divide
by 2.
Is this broken for OMAP4 as well?
Regards,
Mike
Tero Kristo
May 26, 2014, 2:40:02 AM5/26/14
to
On 05/24/2014 12:07 AM, Mike Turquette wrote:
> Quoting Nishanth Menon (2014-05-16 03:45:57)
>> Hi,
>>
>> This patch series has been carried over in vendor kernel for quiet
>> few years now.
>>
>> Unfortunately, it was very recently re-discovered and upstream kernel
>> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
>> DPLL at frequency higher than what it was intended to be when CPUFreq
>> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
>> upstream for the mentioned platforms) and margins in trimming, we
>> have so far not crashed - but I strongly suspect this might be some
>> boundary case survival.
>
> DCC also exists in OMAP4. In some cases customers used it, in other
> cases we just ran the PLL way out of spec and the mpu_clk would divide
> by 2.
>
> Is this broken for OMAP4 as well?
Yes, its broken. This series does not address the OMAP4 needs for it,
> Quoting Nishanth Menon (2014-05-16 03:45:57)
>> Hi,
>>
>> This patch series has been carried over in vendor kernel for quiet
>> few years now.
>>
>> Unfortunately, it was very recently re-discovered and upstream kernel
>> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
>> DPLL at frequency higher than what it was intended to be when CPUFreq
>> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
>> upstream for the mentioned platforms) and margins in trimming, we
>> have so far not crashed - but I strongly suspect this might be some
>> boundary case survival.
>
> DCC also exists in OMAP4. In some cases customers used it, in other
> cases we just ran the PLL way out of spec and the mpu_clk would divide
> by 2.
>
> Is this broken for OMAP4 as well?
but can be expanded later by just defining a proper clock type with
OMAP4 specific DCC rate limits etc. for it. We would need properly
functioning DVFS for OMAP4 panda first though I guess... (support for
the TPS regulator.)
-Tero
Nishanth Menon
May 28, 2014, 9:00:03 AM5/28/14
to
On Mon 26 May 2014 01:32:08 AM CDT, Tero Kristo wrote:
> On 05/24/2014 12:07 AM, Mike Turquette wrote:
>> Quoting Nishanth Menon (2014-05-16 03:45:57)
>>> Hi,
>>>
>>> This patch series has been carried over in vendor kernel for quiet
>>> few years now.
>>>
>>> Unfortunately, it was very recently re-discovered and upstream kernel
>>> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
>>> DPLL at frequency higher than what it was intended to be when CPUFreq
>>> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
>>> upstream for the mentioned platforms) and margins in trimming, we
>>> have so far not crashed - but I strongly suspect this might be some
>>> boundary case survival.
>>
>> DCC also exists in OMAP4. In some cases customers used it, in other
>> cases we just ran the PLL way out of spec and the mpu_clk would divide
>> by 2.
>>
>> Is this broken for OMAP4 as well?
>
> Yes, its broken. This series does not address the OMAP4 needs for it,
> but can be expanded later by just defining a proper clock type with
> OMAP4 specific DCC rate limits etc. for it. We would need properly
> functioning DVFS for OMAP4 panda first though I guess... (support for
> the TPS regulator.)
Panda does not need DCC. Panda uses 4430 and Panda-ES uses 4460.
> On 05/24/2014 12:07 AM, Mike Turquette wrote:
>> Quoting Nishanth Menon (2014-05-16 03:45:57)
>>> Hi,
>>>
>>> This patch series has been carried over in vendor kernel for quiet
>>> few years now.
>>>
>>> Unfortunately, it was very recently re-discovered and upstream kernel
>>> is noticed to be broken for OMAP5 1.5GHz - at least we are operating
>>> DPLL at frequency higher than what it was intended to be when CPUFreq
>>> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
>>> upstream for the mentioned platforms) and margins in trimming, we
>>> have so far not crashed - but I strongly suspect this might be some
>>> boundary case survival.
>>
>> DCC also exists in OMAP4. In some cases customers used it, in other
>> cases we just ran the PLL way out of spec and the mpu_clk would divide
>> by 2.
>>
>> Is this broken for OMAP4 as well?
>
> Yes, its broken. This series does not address the OMAP4 needs for it,
> but can be expanded later by just defining a proper clock type with
> OMAP4 specific DCC rate limits etc. for it. We would need properly
> functioning DVFS for OMAP4 panda first though I guess... (support for
> the TPS regulator.)
neither of which need DCC (DPLLs are trimmed for required frequencies
there) - 4430 never had DCC, 4460 had broken DCC. 4470 (which is not
upstream and does not have a panda variant) is the only one needing DCC
at higher frequencies, and that needs an entirely different
scheme(compared to OMAP5+) as mentioned by Tero if 4470 ever gets
supported upstream.
--
Regards,
Nishanth Menon
0 new messages