Skip to contentSkip to conversation

ARM: OMAP2+: quick clock fixes for linux-next

PATCH New Tero Kristo 4 participants 9 messages Dec 12, 2014 – Dec 16, 2014

Subsystems (6)
lore
Share & tools
lore
#0 lore raw

cover ARM: OMAP2+: quick clock fixes for linux-next

Hi,

These patches fix a couple of bugs in linux-next. I didn't see official patch for #1 anywhere so posted here, was discussed under a thread on linux-omap list though.

-Tero

#1 lore raw

PATCH 1/2 ARM: OMAP2+: clock: fix DPLL code to use new determine rate APIs

While the change for determine_rate clock operation was merged, the OMAP counterpart using these calls was overlooked for some reason, and caused boot failures on at least OMAP4 platforms. Fixed by updating the DPLL API calls to use the new parameters.

Fixes 646cafc6aa ("clk: Change clk_ops->determine_rate")
Cc Tomeu Vizoso <[email protected]>
Cc Mike Turquette <[email protected]>
Cc Tony Lindgren <[email protected]>
---
 arch/arm/mach-omap2/dpll3xxx.c |    6 +++---
 arch/arm/mach-omap2/dpll44xx.c |    6 +++---
 include/linux/clk/ti.h         |    4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/dpll3xxx.c +3 -3
index 20e120d..c2da2a0 100644
@@ -474,7 +474,7 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
  */
 long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
 				       unsigned long *best_parent_rate,
-				       struct clk **best_parent_clk)
+				       struct clk_hw **best_parent_clk)
 {
 	struct clk_hw_omap *clk = to_clk_hw_omap(hw);
 	struct dpll_data *dd;
@@ -488,10 +488,10 @@ long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
 
 	if (__clk_get_rate(dd->clk_bypass) == rate &&
 	    (dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
-		*best_parent_clk = dd->clk_bypass;
+		*best_parent_clk = __clk_get_hw(dd->clk_bypass);
 	} else {
 		rate = omap2_dpll_round_rate(hw, rate, best_parent_rate);
-		*best_parent_clk = dd->clk_ref;
+		*best_parent_clk = __clk_get_hw(dd->clk_ref);
 	}
 
 	*best_parent_rate = rate;
arch/arm/mach-omap2/dpll44xx.c +3 -3
index 535822f..0e58e5a 100644
@@ -223,7 +223,7 @@ out:
  */
 long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
 					unsigned long *best_parent_rate,
-					struct clk **best_parent_clk)
+					struct clk_hw **best_parent_clk)
 {
 	struct clk_hw_omap *clk = to_clk_hw_omap(hw);
 	struct dpll_data *dd;
@@ -237,11 +237,11 @@ long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
 
 	if (__clk_get_rate(dd->clk_bypass) == rate &&
 	    (dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
-		*best_parent_clk = dd->clk_bypass;
+		*best_parent_clk = __clk_get_hw(dd->clk_bypass);
 	} else {
 		rate = omap4_dpll_regm4xen_round_rate(hw, rate,
 						      best_parent_rate);
-		*best_parent_clk = dd->clk_ref;
+		*best_parent_clk = __clk_get_hw(dd->clk_ref);
 	}
 
 	*best_parent_rate = rate;
include/linux/clk/ti.h +2 -2
index 74e5341..55ef529 100644
@@ -264,7 +264,7 @@ int omap3_noncore_dpll_set_rate_and_parent(struct clk_hw *hw,
 long omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
 				       unsigned long rate,
 				       unsigned long *best_parent_rate,
-				       struct clk **best_parent_clk);
+				       struct clk_hw **best_parent_clk);
 unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
 					 unsigned long parent_rate);
 long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
@@ -273,7 +273,7 @@ long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
 long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
 					unsigned long rate,
 					unsigned long *best_parent_rate,
-					struct clk **best_parent_clk);
+					struct clk_hw **best_parent_clk);
 u8 omap2_init_dpll_parent(struct clk_hw *hw);
 unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate);
 long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
Signature · 1 line
1.7.9.5
#2 lore raw

PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode

In reply to Tero Kristo

The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks.

Fixes 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc Kevin Hilman <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Tony Lindgren <[email protected]>
---
 arch/arm/mach-omap2/cclock3xxx_data.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
arch/arm/mach-omap2/cclock3xxx_data.c +14 -9
index 5c5ebb4..644ff32 100644
@@ -111,6 +111,7 @@ static struct clk dpll3_ck;
 
 static const char *dpll3_ck_parent_names[] = {
 	"sys_ck",
+	"sys_ck",
 };
 
 static const struct clk_ops dpll3_ck_ops = {
@@ -733,6 +734,10 @@ static const char *corex2_fck_parent_names[] = {
 DEFINE_STRUCT_CLK_HW_OMAP(corex2_fck, NULL);
 DEFINE_STRUCT_CLK(corex2_fck, corex2_fck_parent_names, core_ck_ops);
 
+static const char *cpefuse_fck_parent_names[] = {
+	"sys_ck",
+};
+
 static struct clk cpefuse_fck;
 
 static struct clk_hw_omap cpefuse_fck_hw = {
@@ -744,7 +749,7 @@ static struct clk_hw_omap cpefuse_fck_hw = {
 	.clkdm_name	= "core_l4_clkdm",
 };
 
-DEFINE_STRUCT_CLK(cpefuse_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(cpefuse_fck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk csi2_96m_fck;
 
@@ -775,7 +780,7 @@ static struct clk_hw_omap d2d_26m_fck_hw = {
 	.clkdm_name	= "d2d_clkdm",
 };
 
-DEFINE_STRUCT_CLK(d2d_26m_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(d2d_26m_fck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk des1_ick;
 
@@ -1046,7 +1051,7 @@ static struct clk_hw_omap dss2_alwon_fck_hw = {
 	.clkdm_name	= "dss_clkdm",
 };
 
-DEFINE_STRUCT_CLK(dss2_alwon_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(dss2_alwon_fck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk dss_96m_fck;
 
@@ -1368,7 +1373,7 @@ DEFINE_STRUCT_CLK(gpio1_dbck, gpio1_dbck_parent_names, aes2_ick_ops);
 static struct clk wkup_l4_ick;
 
 DEFINE_STRUCT_CLK_HW_OMAP(wkup_l4_ick, "wkup_clkdm");
-DEFINE_STRUCT_CLK(wkup_l4_ick, dpll3_ck_parent_names, core_l4_ick_ops);
+DEFINE_STRUCT_CLK(wkup_l4_ick, cpefuse_fck_parent_names, core_l4_ick_ops);
 
 static struct clk gpio1_ick;
 
@@ -1862,7 +1867,7 @@ static struct clk_hw_omap hecc_ck_hw = {
 	.clkdm_name	= "core_l3_clkdm",
 };
 
-DEFINE_STRUCT_CLK(hecc_ck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(hecc_ck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk hsotgusb_fck_am35xx;
 
@@ -1875,7 +1880,7 @@ static struct clk_hw_omap hsotgusb_fck_am35xx_hw = {
 	.clkdm_name	= "core_l3_clkdm",
 };
 
-DEFINE_STRUCT_CLK(hsotgusb_fck_am35xx, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(hsotgusb_fck_am35xx, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk hsotgusb_ick_3430es1;
 
@@ -2411,7 +2416,7 @@ static struct clk_hw_omap modem_fck_hw = {
 	.clkdm_name	= "d2d_clkdm",
 };
 
-DEFINE_STRUCT_CLK(modem_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(modem_fck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk mspro_fck;
 
@@ -2710,7 +2715,7 @@ static struct clk_hw_omap sr1_fck_hw = {
 	.clkdm_name	= "wkup_clkdm",
 };
 
-DEFINE_STRUCT_CLK(sr1_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(sr1_fck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk sr2_fck;
 
@@ -2724,7 +2729,7 @@ static struct clk_hw_omap sr2_fck_hw = {
 	.clkdm_name	= "wkup_clkdm",
 };
 
-DEFINE_STRUCT_CLK(sr2_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(sr2_fck, cpefuse_fck_parent_names, aes2_ick_ops);
 
 static struct clk sr_l4_ick;
 
Signature · 1 line
1.7.9.5
#3 lore raw

PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode

Hi Tero,

Quoted 9 lines · Tero Kristo

The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks.

Fixes 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc Kevin Hilman <[email protected]>

I tested this on linux-next (next-20141210, same version where I found the bug) and this doesn't fix the boot problem.

BTW, in testing this, I noticed that the OMAP clock code is still spitting out compile warnings[1]. These should cleaned up too.

Kevin

[1]
../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: initialization from incompatible pointer type [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: (near initialization for 'dpll1_ck_ops.determine_rate') [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: initialization from incompatible pointer type [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: (near initialization for 'dpll4_ck_ops.determine_rate') [enabled by default]

#4 lore raw

PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode

Quoted 14 lines · Kevin Hilman

Hi Tero,

Quoted 9 lines · Tero Kristo

The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks.

Fixes 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc Kevin Hilman <[email protected]>
Quoted 5 lines

I tested this on linux-next (next-20141210, same version where I found the bug) and this doesn't fix the boot problem.

BTW, in testing this, I noticed that the OMAP clock code is still spitting out compile warnings[1]. These should cleaned up too.

Did you apply both of my patches from this set?

I think the DPLL fix might be required also to get this working properly on OMAP3 legacy.

-Tero

Quoted 9 lines

Kevin

[1]
../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: initialization from incompatible pointer type [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: (near initialization for 'dpll1_ck_ops.determine_rate') [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: initialization from incompatible pointer type [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: (near initialization for 'dpll4_ck_ops.determine_rate') [enabled by default]

#5 lore raw

PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode

Quoted 15 lines · Tero Kristo
Quoted 14 lines · Kevin Hilman

Hi Tero,

Quoted 9 lines · Tero Kristo

The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks.

Fixes 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc Kevin Hilman <[email protected]>
Quoted 7 lines
Quoted 5 lines

I tested this on linux-next (next-20141210, same version where I found the bug) and this doesn't fix the boot problem.

BTW, in testing this, I noticed that the OMAP clock code is still spitting out compile warnings[1]. These should cleaned up too.

Did you apply both of my patches from this set?

No, I didn't. That wasn't clear (to me) from the changelogs.

Quoted 2 lines

I think the DPLL fix might be required also to get this working properly on OMAP3 legacy.

Yup, with both applied, it's now booting fine on omap3-beagle-xm legacy mode.

And, please add:

(c.f. Reported-by section in Documentation/SubmittingPatches).

Thanks,

Kevin

maintainer
#6 lore raw

PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode

Quoted 20 lines · Kevin Hilman
Quoted 18 lines · Tero Kristo
Quoted 17 lines · Kevin Hilman

Hi Tero,

Quoted 9 lines · Tero Kristo

The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks.

Fixes 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc Kevin Hilman <[email protected]>

I tested this on linux-next (next-20141210, same version where I found the bug) and this doesn't fix the boot problem.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

BTW, in testing this, I noticed that the OMAP clock code is still spitting out compile warnings[1]. These should cleaned up too.

Did you apply both of my patches from this set?

No, I didn't. That wasn't clear (to me) from the changelogs.

The first one Mike is alredy fixing in his clock branch AFAIK.

Quoted 6 lines
Quoted 2 lines

I think the DPLL fix might be required also to get this working properly on OMAP3 legacy.

Yup, with both applied, it's now booting fine on omap3-beagle-xm legacy mode.

Quoted 7 lines

And, please add:

(c.f. Reported-by section in Documentation/SubmittingPatches).

I'll queue the second one separately after Mike's clock changes hit mainline.

Thanks,

Tony

maintainer
#7 lore raw

PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode

Quoted 38 lines · Tony Lindgren
Quoted 20 lines · Kevin Hilman
Quoted 18 lines · Tero Kristo
Quoted 17 lines · Kevin Hilman

Hi Tero,

Quoted 9 lines · Tero Kristo

The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks.

Fixes 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc Kevin Hilman <[email protected]>

I tested this on linux-next (next-20141210, same version where I found the bug) and this doesn't fix the boot problem.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

BTW, in testing this, I noticed that the OMAP clock code is still spitting out compile warnings[1]. These should cleaned up too.

Did you apply both of my patches from this set?

No, I didn't. That wasn't clear (to me) from the changelogs.

The first one Mike is alredy fixing in his clock branch AFAIK.

Quoted 8 lines
Quoted 2 lines

I think the DPLL fix might be required also to get this working properly on OMAP3 legacy.

Yup, with both applied, it's now booting fine on omap3-beagle-xm legacy mode.

Quoted 8 lines
Quoted 5 lines

And, please add:

(c.f. Reported-by section in Documentation/SubmittingPatches).

I'll queue the second one separately after Mike's clock changes hit mainline.

Just to update the status, Mike has applied this as it applies to his tree now too.

Regards,

Tony

#8 lore raw

cover ARM: OMAP2+: quick clock fixes for linux-next

In reply to Tero Kristo
Quoted 6 lines · Tero Kristo

Hi,

These patches fix a couple of bugs in linux-next. I didn't see official patch for #1 anywhere so posted here, was discussed under a thread on linux-omap list though.

Quoted 7 lines

-Tero

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

Thanks, these clk fixes helped me in testing pcie on dra7.

Regards
Vignesh