[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)

[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)

[Nishanth Menon]

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 +
 arch/arm/boot/dts/dra7xx-clocks.dtsi               |    2 +-
 arch/arm/boot/dts/omap54xx-clocks.dtsi             |    2 +-
 arch/arm/mach-omap2/dpll3xxx.c                     |    9 +++++++++
 drivers/clk/ti/dpll.c                              |   21 ++++++++++++++++++++
 include/linux/clk/ti.h                             |    4 ++++
 6 files changed, 37 insertions(+), 2 deletions(-)

Regards,
Nishanth Menon
-- 
1.7.9.5

[PATCH 1/3] ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC)

[Nishanth Menon]

From: Andrii Tseglytskyi <andrii.tseglytskyi@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.tseglytskyi@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
[t-kristo at ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo <t-kristo@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;
-- 
1.7.9.5

[PATCH 2/3] clk: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies

[Nishanth Menon]

MPU DPLL on OMAP5, DRA75x, DRA72x 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)).

So provide support to setup required data to handle Duty cycle by
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).

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 .../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 = {
-- 
1.7.9.5

[PATCH 3/3] ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies

[Nishanth Menon]

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 <nm@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

[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)

[Tero Kristo]

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 
yell if you got any complaints.

-Tero

>
> 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 +++++++++
>   drivers/clk/ti/dpll.c                              |   21 ++++++++++++++++++++
>   include/linux/clk/ti.h                             |    4 ++++
>   6 files changed, 37 insertions(+), 2 deletions(-)
>
> Regards,
> Nishanth Menon
>

[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)

[Mike Turquette]

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?

Regards,
Mike

> 
> 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 +++++++++
>  drivers/clk/ti/dpll.c                              |   21 ++++++++++++++++++++
>  include/linux/clk/ti.h                             |    4 ++++
>  6 files changed, 37 insertions(+), 2 deletions(-)
> 
> Regards,
> Nishanth Menon
> -- 
> 1.7.9.5
> 

[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)

[Tero Kristo]

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

-Tero

>
> Regards,
> Mike
>
>>
>> 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 +++++++++
>>   drivers/clk/ti/dpll.c                              |   21 ++++++++++++++++++++
>>   include/linux/clk/ti.h                             |    4 ++++
>>   6 files changed, 37 insertions(+), 2 deletions(-)
>>
>> Regards,
>> Nishanth Menon
>> --
>> 1.7.9.5
>>

[PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)

[Nishanth Menon]

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