* [PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next @ 2014-12-12 13:21 ` Tero Kristo 0 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-12 13:21 UTC (permalink / raw) To: linux-omap; +Cc: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next @ 2014-12-12 13:21 ` Tero Kristo 0 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-12 13:21 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 1/2] ARM: OMAP2+: clock: fix DPLL code to use new determine rate APIs 2014-12-12 13:21 ` Tero Kristo @ 2014-12-12 13:22 ` Tero Kristo -1 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-12 13:22 UTC (permalink / raw) To: linux-omap; +Cc: linux-arm-kernel, Tomeu Vizoso, Mike Turquette, Tony Lindgren 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. Signed-off-by: Tero Kristo <t-kristo@ti.com> Fixes: 646cafc6aa ("clk: Change clk_ops->determine_rate") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mike Turquette <mturquette@linaro.org> Cc: Tony Lindgren <tony@atomide.com> --- 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(-) diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 20e120d..c2da2a0 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -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; diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c index 535822f..0e58e5a 100644 --- a/arch/arm/mach-omap2/dpll44xx.c +++ b/arch/arm/mach-omap2/dpll44xx.c @@ -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; diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h index 74e5341..55ef529 100644 --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h @@ -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, -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 1/2] ARM: OMAP2+: clock: fix DPLL code to use new determine rate APIs @ 2014-12-12 13:22 ` Tero Kristo 0 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-12 13:22 UTC (permalink / raw) To: linux-arm-kernel 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. Signed-off-by: Tero Kristo <t-kristo@ti.com> Fixes: 646cafc6aa ("clk: Change clk_ops->determine_rate") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mike Turquette <mturquette@linaro.org> Cc: Tony Lindgren <tony@atomide.com> --- 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(-) diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 20e120d..c2da2a0 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -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; diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c index 535822f..0e58e5a 100644 --- a/arch/arm/mach-omap2/dpll44xx.c +++ b/arch/arm/mach-omap2/dpll44xx.c @@ -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; diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h index 74e5341..55ef529 100644 --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h @@ -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, -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode 2014-12-12 13:21 ` Tero Kristo @ 2014-12-12 13:22 ` Tero Kristo -1 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-12 13:22 UTC (permalink / raw) To: linux-omap; +Cc: linux-arm-kernel, Kevin Hilman, Paul Walmsley, Tony Lindgren 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. Signed-off-by: Tero Kristo <t-kristo@ti.com> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") Cc: Kevin Hilman <khilman@kernel.org> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> --- arch/arm/mach-omap2/cclock3xxx_data.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c index 5c5ebb4..644ff32 100644 --- a/arch/arm/mach-omap2/cclock3xxx_data.c +++ b/arch/arm/mach-omap2/cclock3xxx_data.c @@ -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; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode @ 2014-12-12 13:22 ` Tero Kristo 0 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-12 13:22 UTC (permalink / raw) To: linux-arm-kernel 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. Signed-off-by: Tero Kristo <t-kristo@ti.com> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") Cc: Kevin Hilman <khilman@kernel.org> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> --- arch/arm/mach-omap2/cclock3xxx_data.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c index 5c5ebb4..644ff32 100644 --- a/arch/arm/mach-omap2/cclock3xxx_data.c +++ b/arch/arm/mach-omap2/cclock3xxx_data.c @@ -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; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode 2014-12-12 13:22 ` Tero Kristo @ 2014-12-12 19:07 ` Kevin Hilman -1 siblings, 0 replies; 18+ messages in thread From: Kevin Hilman @ 2014-12-12 19:07 UTC (permalink / raw) To: Tero Kristo; +Cc: linux-omap, linux-arm-kernel, Paul Walmsley, Tony Lindgren Hi Tero, Tero Kristo <t-kristo@ti.com> writes: > 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. > > Signed-off-by: Tero Kristo <t-kristo@ti.com> > Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") > Cc: Kevin Hilman <khilman@kernel.org> 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] ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode @ 2014-12-12 19:07 ` Kevin Hilman 0 siblings, 0 replies; 18+ messages in thread From: Kevin Hilman @ 2014-12-12 19:07 UTC (permalink / raw) To: linux-arm-kernel Hi Tero, Tero Kristo <t-kristo@ti.com> writes: > 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. > > Signed-off-by: Tero Kristo <t-kristo@ti.com> > Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") > Cc: Kevin Hilman <khilman@kernel.org> 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] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode 2014-12-12 19:07 ` Kevin Hilman @ 2014-12-15 7:56 ` Tero Kristo -1 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-15 7:56 UTC (permalink / raw) To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, Paul Walmsley, Tony Lindgren On 12/12/2014 09:07 PM, Kevin Hilman wrote: > Hi Tero, > > Tero Kristo <t-kristo@ti.com> writes: > >> 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. >> >> Signed-off-by: Tero Kristo <t-kristo@ti.com> >> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") >> Cc: Kevin Hilman <khilman@kernel.org> > > 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 > > 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] > ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode @ 2014-12-15 7:56 ` Tero Kristo 0 siblings, 0 replies; 18+ messages in thread From: Tero Kristo @ 2014-12-15 7:56 UTC (permalink / raw) To: linux-arm-kernel On 12/12/2014 09:07 PM, Kevin Hilman wrote: > Hi Tero, > > Tero Kristo <t-kristo@ti.com> writes: > >> 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. >> >> Signed-off-by: Tero Kristo <t-kristo@ti.com> >> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") >> Cc: Kevin Hilman <khilman@kernel.org> > > 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 > > 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] > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode 2014-12-15 7:56 ` Tero Kristo @ 2014-12-15 18:23 ` Kevin Hilman -1 siblings, 0 replies; 18+ messages in thread From: Kevin Hilman @ 2014-12-15 18:23 UTC (permalink / raw) To: Tero Kristo; +Cc: linux-omap, linux-arm-kernel, Paul Walmsley, Tony Lindgren Tero Kristo <t-kristo@ti.com> writes: > On 12/12/2014 09:07 PM, Kevin Hilman wrote: >> Hi Tero, >> >> Tero Kristo <t-kristo@ti.com> writes: >> >>> 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. >>> >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") >>> Cc: Kevin Hilman <khilman@kernel.org> >> >> 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. > 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 <khilman@linaro.org> And, please add: Reported-by: Kevin Hilman <khilman@linaro.org> (c.f. Reported-by section in Documentation/SubmittingPatches). Thanks, Kevin ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode @ 2014-12-15 18:23 ` Kevin Hilman 0 siblings, 0 replies; 18+ messages in thread From: Kevin Hilman @ 2014-12-15 18:23 UTC (permalink / raw) To: linux-arm-kernel Tero Kristo <t-kristo@ti.com> writes: > On 12/12/2014 09:07 PM, Kevin Hilman wrote: >> Hi Tero, >> >> Tero Kristo <t-kristo@ti.com> writes: >> >>> 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. >>> >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") >>> Cc: Kevin Hilman <khilman@kernel.org> >> >> 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. > 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 <khilman@linaro.org> And, please add: Reported-by: Kevin Hilman <khilman@linaro.org> (c.f. Reported-by section in Documentation/SubmittingPatches). Thanks, Kevin ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode 2014-12-15 18:23 ` Kevin Hilman @ 2014-12-15 22:58 ` Tony Lindgren -1 siblings, 0 replies; 18+ messages in thread From: Tony Lindgren @ 2014-12-15 22:58 UTC (permalink / raw) To: Kevin Hilman; +Cc: Tero Kristo, linux-omap, linux-arm-kernel, Paul Walmsley * Kevin Hilman <khilman@kernel.org> [141215 10:26]: > Tero Kristo <t-kristo@ti.com> writes: > > > On 12/12/2014 09:07 PM, Kevin Hilman wrote: > >> Hi Tero, > >> > >> Tero Kristo <t-kristo@ti.com> writes: > >> > >>> 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. > >>> > >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> > >>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") > >>> Cc: Kevin Hilman <khilman@kernel.org> > >> > >> 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. The first one Mike is alredy fixing in his clock branch AFAIK. > > 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 <khilman@linaro.org> > > And, please add: > > Reported-by: Kevin Hilman <khilman@linaro.org> > > (c.f. Reported-by section in Documentation/SubmittingPatches). I'll queue the second one separately after Mike's clock changes hit mainline. Thanks, Tony ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode @ 2014-12-15 22:58 ` Tony Lindgren 0 siblings, 0 replies; 18+ messages in thread From: Tony Lindgren @ 2014-12-15 22:58 UTC (permalink / raw) To: linux-arm-kernel * Kevin Hilman <khilman@kernel.org> [141215 10:26]: > Tero Kristo <t-kristo@ti.com> writes: > > > On 12/12/2014 09:07 PM, Kevin Hilman wrote: > >> Hi Tero, > >> > >> Tero Kristo <t-kristo@ti.com> writes: > >> > >>> 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. > >>> > >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> > >>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") > >>> Cc: Kevin Hilman <khilman@kernel.org> > >> > >> 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. The first one Mike is alredy fixing in his clock branch AFAIK. > > 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 <khilman@linaro.org> > > And, please add: > > Reported-by: Kevin Hilman <khilman@linaro.org> > > (c.f. Reported-by section in Documentation/SubmittingPatches). I'll queue the second one separately after Mike's clock changes hit mainline. Thanks, Tony ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode 2014-12-15 22:58 ` Tony Lindgren @ 2014-12-16 0:52 ` Tony Lindgren -1 siblings, 0 replies; 18+ messages in thread From: Tony Lindgren @ 2014-12-16 0:52 UTC (permalink / raw) To: Kevin Hilman; +Cc: Tero Kristo, linux-omap, linux-arm-kernel, Paul Walmsley * Tony Lindgren <tony@atomide.com> [141215 15:04]: > * Kevin Hilman <khilman@kernel.org> [141215 10:26]: > > Tero Kristo <t-kristo@ti.com> writes: > > > > > On 12/12/2014 09:07 PM, Kevin Hilman wrote: > > >> Hi Tero, > > >> > > >> Tero Kristo <t-kristo@ti.com> writes: > > >> > > >>> 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. > > >>> > > >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> > > >>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") > > >>> Cc: Kevin Hilman <khilman@kernel.org> > > >> > > >> 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. > > The first one Mike is alredy fixing in his clock branch AFAIK. > > > > 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 <khilman@linaro.org> > > > > And, please add: > > > > Reported-by: Kevin Hilman <khilman@linaro.org> > > > > (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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode @ 2014-12-16 0:52 ` Tony Lindgren 0 siblings, 0 replies; 18+ messages in thread From: Tony Lindgren @ 2014-12-16 0:52 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [141215 15:04]: > * Kevin Hilman <khilman@kernel.org> [141215 10:26]: > > Tero Kristo <t-kristo@ti.com> writes: > > > > > On 12/12/2014 09:07 PM, Kevin Hilman wrote: > > >> Hi Tero, > > >> > > >> Tero Kristo <t-kristo@ti.com> writes: > > >> > > >>> 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. > > >>> > > >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> > > >>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...") > > >>> Cc: Kevin Hilman <khilman@kernel.org> > > >> > > >> 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. > > The first one Mike is alredy fixing in his clock branch AFAIK. > > > > 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 <khilman@linaro.org> > > > > And, please add: > > > > Reported-by: Kevin Hilman <khilman@linaro.org> > > > > (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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next 2014-12-12 13:21 ` Tero Kristo @ 2014-12-15 4:35 ` Vignesh R -1 siblings, 0 replies; 18+ messages in thread From: Vignesh R @ 2014-12-15 4:35 UTC (permalink / raw) To: Tero Kristo, linux-omap; +Cc: linux-arm-kernel On Friday 12 December 2014 06:51 PM, Tero Kristo wrote: > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next @ 2014-12-15 4:35 ` Vignesh R 0 siblings, 0 replies; 18+ messages in thread From: Vignesh R @ 2014-12-15 4:35 UTC (permalink / raw) To: linux-arm-kernel On Friday 12 December 2014 06:51 PM, Tero Kristo wrote: > 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 > > -- > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-12-16 0:55 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-12-12 13:21 [PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next Tero Kristo 2014-12-12 13:21 ` Tero Kristo 2014-12-12 13:22 ` [PATCH 1/2] ARM: OMAP2+: clock: fix DPLL code to use new determine rate APIs Tero Kristo 2014-12-12 13:22 ` Tero Kristo 2014-12-12 13:22 ` [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode Tero Kristo 2014-12-12 13:22 ` Tero Kristo 2014-12-12 19:07 ` Kevin Hilman 2014-12-12 19:07 ` Kevin Hilman 2014-12-15 7:56 ` Tero Kristo 2014-12-15 7:56 ` Tero Kristo 2014-12-15 18:23 ` Kevin Hilman 2014-12-15 18:23 ` Kevin Hilman 2014-12-15 22:58 ` Tony Lindgren 2014-12-15 22:58 ` Tony Lindgren 2014-12-16 0:52 ` Tony Lindgren 2014-12-16 0:52 ` Tony Lindgren 2014-12-15 4:35 ` [PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next Vignesh R 2014-12-15 4:35 ` Vignesh R
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.