diff mbox

OMAP3 clock: Access only available clock bits

Message ID 4d34a0a70903192015j4ea44b1fn4f7bb045da32d218@mail.gmail.com (mailing list archive)
State Not Applicable
Delegated to: Kevin Hilman
Headers show

Commit Message

kim kyuwon March 20, 2009, 3:15 a.m. UTC
Hi All,

I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
OMAP_RESET_CLOCKS feature.
In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
prcm interrupt is generated and its handler can't exit loop at next
statement!

while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));

I also found that sad2d_ick is available only OMAP3430 ES1. I fixed
this problem with below patch.

Your better solutions or comments appreciated.

Sincerely,
Kyuwon
--
This patch prevents setting or clearing reserved bits of 'Clock Enable
Register', in the clk_disable_unused() function. Especially, this
patch prevents using the sad2d_ick which doesn't exist in OMAP3430
ES2+.

Signed-off-by: Kim Kyuwon <q1.kim@samsung.com>
---
 arch/arm/mach-omap2/clock34xx.h |    2 +-
 arch/arm/plat-omap/clock.c      |   10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletions(-)

Comments

Paul Walmsley March 20, 2009, 9:48 p.m. UTC | #1
Hello Kyuwon,

On Fri, 20 Mar 2009, Kim Kyuwon wrote:

> I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
> OMAP_RESET_CLOCKS feature.
> In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
> prcm interrupt is generated and its handler can't exit loop at next
> statement!
> 
> while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));

We encountered a similar problem a few months ago.  The problem is 
probably the pad mux settings on the d2d_mstdby and d2d_swakeup pads.  
These are usually configured by the bootloader.  My recollection is that 
they should be pulled up, but I don't recall for sure.  Yes, we should 
have a patch in the PM branch to at least detect whether these pads are 
configured incorrectly...

> I also found that sad2d_ick is available only OMAP3430 ES1. I fixed
> this problem with below patch.

Thanks for your patch, but, sad2d_ick is indeed present on ES2+. TI 
removed the documenation from the main TRM and moved it to the "OMAP34xx 
Stacked Mode Addendum" (SWCU048).  Ill-advised, in my opinion!


- Paul

> 
> Your better solutions or comments appreciated.
> 
> Sincerely,
> Kyuwon
> --
> This patch prevents setting or clearing reserved bits of 'Clock Enable
> Register', in the clk_disable_unused() function. Especially, this
> patch prevents using the sad2d_ick which doesn't exist in OMAP3430
> ES2+.
> 
> Signed-off-by: Kim Kyuwon <q1.kim@samsung.com>
> ---
>  arch/arm/mach-omap2/clock34xx.h |    2 +-
>  arch/arm/plat-omap/clock.c      |   10 ++++++++++
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
> index e0dd7f3..039f7dd 100644
> --- a/arch/arm/mach-omap2/clock34xx.h
> +++ b/arch/arm/mach-omap2/clock34xx.h
> @@ -1279,7 +1279,7 @@ static struct clk sad2d_ick = {
>  	.prcm_mod	= CORE_MOD,
>  	.enable_reg	= CM_ICLKEN1,
>  	.enable_bit	= OMAP3430_EN_SAD2D_SHIFT,
> -	.flags		= CLOCK_IN_OMAP343X,
> +	.flags		= CLOCK_IN_OMAP3430ES1,
>  	.clkdm		= { .name = "d2d_clkdm" },
>  	.recalc		= &followparent_recalc,
>  };
> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> index 2eed047..b16c6c3 100644
> --- a/arch/arm/plat-omap/clock.c
> +++ b/arch/arm/plat-omap/clock.c
> @@ -775,6 +775,16 @@ static int __init clk_disable_unused(void)
>  		if (cpu_class_is_omap1() && ck->enable_reg == 0)
>  			continue;
> 
> +		if (cpu_is_omap34xx()) {
> +			if ((omap_rev() == OMAP3430_REV_ES1_0) &&
> +					(ck->flags & CLOCK_IN_OMAP3430ES2))
> +				continue;
> +
> +			/* In this case, board Rev. is greater then ES1 */
> +			if (ck->flags & CLOCK_IN_OMAP3430ES1)
> +				continue;
> +		}
> +
>  		spin_lock_irqsave(&clockfw_lock, flags);
>  		if (arch_clock->clk_disable_unused)
>  			arch_clock->clk_disable_unused(ck);
> -- 
> 1.5.2.5
> --
> 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
> 


- Paul
--
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
Paul Walmsley March 20, 2009, 9:56 p.m. UTC | #2
On Fri, 20 Mar 2009, Paul Walmsley wrote:

> On Fri, 20 Mar 2009, Kim Kyuwon wrote:
> 
> > I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
> > OMAP_RESET_CLOCKS feature.
> > In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
> > prcm interrupt is generated and its handler can't exit loop at next
> > statement!
> > 
> > while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));
> 
> We encountered a similar problem a few months ago.  The problem is 
> probably the pad mux settings on the d2d_mstdby and d2d_swakeup pads.  
> These are usually configured by the bootloader.  My recollection is that 
> they should be pulled up, but I don't recall for sure.

On second thought, I believe swakeup should be pulled down and mstdby 
should be pulled up.


- Paul
--
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
kim kyuwon March 23, 2009, 1:23 a.m. UTC | #3
Hi Paul,

On Sat, Mar 21, 2009 at 6:48 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Kyuwon,
>
> On Fri, 20 Mar 2009, Kim Kyuwon wrote:
>
>> I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
>> OMAP_RESET_CLOCKS feature.
>> In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
>> prcm interrupt is generated and its handler can't exit loop at next
>> statement!
>>
>> while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));
>
> We encountered a similar problem a few months ago.  The problem is
> probably the pad mux settings on the d2d_mstdby and d2d_swakeup pads.
> These are usually configured by the bootloader.  My recollection is that
> they should be pulled up, but I don't recall for sure.  Yes, we should
> have a patch in the PM branch to at least detect whether these pads are
> configured incorrectly...

Thank you for letting me know the better solution. I confirmed that
this problem can be fixed by configuring the d2d_mstdby and
d2d_swakeup pads. (As you said, swakeup -> pulled down & mstdby ->
pulled up.)

>> I also found that sad2d_ick is available only OMAP3430 ES1. I fixed
>> this problem with below patch.
>
> Thanks for your patch, but, sad2d_ick is indeed present on ES2+. TI
> removed the documenation from the main TRM and moved it to the "OMAP34xx
> Stacked Mode Addendum" (SWCU048).  Ill-advised, in my opinion!
>

I have only the "OMAP34xx ES3.0 Stacked Mode Addendum" and I can see
EN_SAD2D is available in this document. ES3.1 is maybe same.
I think this patch is not needed anymore. Thank you so much for your help!

Regards,
Kyuwon
--
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
Paul Walmsley March 23, 2009, 6:40 a.m. UTC | #4
On Mon, 23 Mar 2009, Kim Kyuwon wrote:

> On Sat, Mar 21, 2009 at 6:48 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Fri, 20 Mar 2009, Kim Kyuwon wrote:
> >
> >> I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
> >> OMAP_RESET_CLOCKS feature.
> >> In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
> >> prcm interrupt is generated and its handler can't exit loop at next
> >> statement!
> >>
> >> while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));
> >
> > We encountered a similar problem a few months ago.  The problem is
> > probably the pad mux settings on the d2d_mstdby and d2d_swakeup pads.
> > These are usually configured by the bootloader.  My recollection is that
> > they should be pulled up, but I don't recall for sure.  Yes, we should
> > have a patch in the PM branch to at least detect whether these pads are
> > configured incorrectly...
> 
> Thank you for letting me know the better solution. I confirmed that
> this problem can be fixed by configuring the d2d_mstdby and
> d2d_swakeup pads. (As you said, swakeup -> pulled down & mstdby ->
> pulled up.)

Great, thanks for the confirmation.


- Paul
--
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
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index e0dd7f3..039f7dd 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1279,7 +1279,7 @@  static struct clk sad2d_ick = {
 	.prcm_mod	= CORE_MOD,
 	.enable_reg	= CM_ICLKEN1,
 	.enable_bit	= OMAP3430_EN_SAD2D_SHIFT,
-	.flags		= CLOCK_IN_OMAP343X,
+	.flags		= CLOCK_IN_OMAP3430ES1,
 	.clkdm		= { .name = "d2d_clkdm" },
 	.recalc		= &followparent_recalc,
 };
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2eed047..b16c6c3 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -775,6 +775,16 @@  static int __init clk_disable_unused(void)
 		if (cpu_class_is_omap1() && ck->enable_reg == 0)
 			continue;

+		if (cpu_is_omap34xx()) {
+			if ((omap_rev() == OMAP3430_REV_ES1_0) &&
+					(ck->flags & CLOCK_IN_OMAP3430ES2))
+				continue;
+
+			/* In this case, board Rev. is greater then ES1 */
+			if (ck->flags & CLOCK_IN_OMAP3430ES1)
+				continue;
+		}
+
 		spin_lock_irqsave(&clockfw_lock, flags);
 		if (arch_clock->clk_disable_unused)
 			arch_clock->clk_disable_unused(ck);