[PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next

[PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next

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

-Tero

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

[Tero Kristo]

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

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

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

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

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

[Kevin Hilman]

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]

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

[Tero Kristo]

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

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

[Kevin Hilman]

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

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

[Tony Lindgren]

* 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

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

[Tony Lindgren]

* 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

[PATCH 0/2] ARM: OMAP2+: quick clock fixes for linux-next

[Vignesh R]

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