ARM: OMAP2+: quick clock fixes for linux-next
Subsystems (6)
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
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.
--- 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
@@ -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
@@ -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
@@ -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
PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode
In reply to Tero KristoThe 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.
--- arch/arm/mach-omap2/cclock3xxx_data.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-)
arch/arm/mach-omap2/cclock3xxx_data.c +14 -9
@@ -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
PATCH 2/2 ARM: OMAP3: clock: fix boot breakage in legacy mode
Hi Tero,
Quoted 9 lines · Tero Kristo
The new usage of
determine_rateandset_rate_and_parentcalls 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.Signed-off-by Tero Kristo <[email protected]>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]
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_rateandset_rate_and_parentcalls 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.Signed-off-by Tero Kristo <[email protected]>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]
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_rateandset_rate_and_parentcalls 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.Signed-off-by Tero Kristo <[email protected]>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
Tony Lindgren
maintainerPATCH 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_rateandset_rate_and_parentcalls 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.Signed-off-by Tero Kristo <[email protected]>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
Tested-by Kevin Hilman <[email protected]>And, please add:
Reported-by Kevin Hilman <[email protected]>(c.f. Reported-by section in
Documentation/SubmittingPatches).
I'll queue the second one separately after Mike's clock changes hit mainline.
Thanks,
Tony
Tony Lindgren
maintainerPATCH 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_rateandset_rate_and_parentcalls 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.Signed-off-by Tero Kristo <[email protected]>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.
Tested-by Kevin Hilman <[email protected]>
Quoted 8 lines
Quoted 5 lines
And, please add:
Reported-by Kevin Hilman <[email protected]>(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
cover ARM: OMAP2+: quick clock fixes for linux-next
In reply to Tero KristoQuoted 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