* [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
@ 2010-05-06 6:28 Anand Gadiyar
2010-06-18 20:55 ` Gadiyar, Anand
2010-06-21 15:07 ` Kevin Hilman
0 siblings, 2 replies; 10+ messages in thread
From: Anand Gadiyar @ 2010-05-06 6:28 UTC (permalink / raw
To: linux-omap, Tony Lindgren; +Cc: Anand Gadiyar
We need to wait on the IDLEST bit after the clocks are enabled
before attempting to access any register.
Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
i-clock is enabled first, the clkops_omap2_dflt_wait is
short-circuited as the companion f-clock is not enabled.
This can cause a data abort if the IDLEST has not transitioned,
and we try to access a USBTLL register.
Since the USBTLL i-clock and f-clock could be enabled in any order,
this is a bug. Fix it by changing the clkops for the f-clock.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
---
arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
===================================================================
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c
+++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1484,7 +1484,7 @@ static struct clk ts_fck = {
static struct clk usbtll_fck = {
.name = "usbtll_fck",
- .ops = &clkops_omap2_dflt,
+ .ops = &clkops_omap2_dflt_wait,
.parent = &dpll5_m2_ck,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
.enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-05-06 6:28 [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk Anand Gadiyar
@ 2010-06-18 20:55 ` Gadiyar, Anand
2010-06-21 21:45 ` Paul Walmsley
2010-06-21 15:07 ` Kevin Hilman
1 sibling, 1 reply; 10+ messages in thread
From: Gadiyar, Anand @ 2010-06-18 20:55 UTC (permalink / raw
To: Gadiyar, Anand, linux-omap@vger.kernel.org, Tony Lindgren
Gadiyar, Anand wrote:
> We need to wait on the IDLEST bit after the clocks are enabled
> before attempting to access any register.
>
> Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> i-clock is enabled first, the clkops_omap2_dflt_wait is
> short-circuited as the companion f-clock is not enabled.
> This can cause a data abort if the IDLEST has not transitioned,
> and we try to access a USBTLL register.
>
> Since the USBTLL i-clock and f-clock could be enabled in any order,
> this is a bug. Fix it by changing the clkops for the f-clock.
>
> Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Ping?
> ---
>
> arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
> ===================================================================
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c
> +++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -1484,7 +1484,7 @@ static struct clk ts_fck = {
>
> static struct clk usbtll_fck = {
> .name = "usbtll_fck",
> - .ops = &clkops_omap2_dflt,
> + .ops = &clkops_omap2_dflt_wait,
> .parent = &dpll5_m2_ck,
> .enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
> .enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-05-06 6:28 [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk Anand Gadiyar
2010-06-18 20:55 ` Gadiyar, Anand
@ 2010-06-21 15:07 ` Kevin Hilman
1 sibling, 0 replies; 10+ messages in thread
From: Kevin Hilman @ 2010-06-21 15:07 UTC (permalink / raw
To: Anand Gadiyar; +Cc: linux-omap, Tony Lindgren
Anand Gadiyar <gadiyar@ti.com> writes:
> We need to wait on the IDLEST bit after the clocks are enabled
> before attempting to access any register.
>
> Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> i-clock is enabled first, the clkops_omap2_dflt_wait is
> short-circuited as the companion f-clock is not enabled.
> This can cause a data abort if the IDLEST has not transitioned,
> and we try to access a USBTLL register.
>
> Since the USBTLL i-clock and f-clock could be enabled in any order,
> this is a bug. Fix it by changing the clkops for the f-clock.
>
> Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>
> arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
> ===================================================================
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c
> +++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -1484,7 +1484,7 @@ static struct clk ts_fck = {
>
> static struct clk usbtll_fck = {
> .name = "usbtll_fck",
> - .ops = &clkops_omap2_dflt,
> + .ops = &clkops_omap2_dflt_wait,
> .parent = &dpll5_m2_ck,
> .enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
> .enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
> --
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-06-18 20:55 ` Gadiyar, Anand
@ 2010-06-21 21:45 ` Paul Walmsley
2010-06-22 16:46 ` Gadiyar, Anand
2010-06-24 0:20 ` Paul Walmsley
0 siblings, 2 replies; 10+ messages in thread
From: Paul Walmsley @ 2010-06-21 21:45 UTC (permalink / raw
To: Gadiyar, Anand; +Cc: linux-omap@vger.kernel.org, Tony Lindgren
On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
> Gadiyar, Anand wrote:
> > We need to wait on the IDLEST bit after the clocks are enabled
> > before attempting to access any register.
> >
> > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> > i-clock is enabled first, the clkops_omap2_dflt_wait is
> > short-circuited as the companion f-clock is not enabled.
> > This can cause a data abort if the IDLEST has not transitioned,
> > and we try to access a USBTLL register.
> >
> > Since the USBTLL i-clock and f-clock could be enabled in any order,
> > this is a bug. Fix it by changing the clkops for the f-clock.
> >
> > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
It looks fine to me. I will queue it for a -rc branch.
> Ping?
Generally it is helpful if you have a patch for a subsystem that I
maintain, to cc me directly.
- Paul
>
>
> > ---
> >
> > arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
> > ===================================================================
> > --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c
> > +++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
> > @@ -1484,7 +1484,7 @@ static struct clk ts_fck = {
> >
> > static struct clk usbtll_fck = {
> > .name = "usbtll_fck",
> > - .ops = &clkops_omap2_dflt,
> > + .ops = &clkops_omap2_dflt_wait,
> > .parent = &dpll5_m2_ck,
> > .enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
> > .enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
> > --
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-06-21 21:45 ` Paul Walmsley
@ 2010-06-22 16:46 ` Gadiyar, Anand
2010-06-24 0:20 ` Paul Walmsley
1 sibling, 0 replies; 10+ messages in thread
From: Gadiyar, Anand @ 2010-06-22 16:46 UTC (permalink / raw
To: Paul Walmsley; +Cc: linux-omap@vger.kernel.org, Tony Lindgren
Paul Walmsley wrote:
> Generally it is helpful if you have a patch for a subsystem that I
> maintain, to cc me directly.
Will do. Thanks.
- Anand
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-06-21 21:45 ` Paul Walmsley
2010-06-22 16:46 ` Gadiyar, Anand
@ 2010-06-24 0:20 ` Paul Walmsley
2010-06-24 6:08 ` Gadiyar, Anand
1 sibling, 1 reply; 10+ messages in thread
From: Paul Walmsley @ 2010-06-24 0:20 UTC (permalink / raw
To: Gadiyar, Anand; +Cc: linux-omap@vger.kernel.org, Tony Lindgren
On Mon, 21 Jun 2010, Paul Walmsley wrote:
> On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
>
> > Gadiyar, Anand wrote:
> > > We need to wait on the IDLEST bit after the clocks are enabled
> > > before attempting to access any register.
> > >
> > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> > > i-clock is enabled first, the clkops_omap2_dflt_wait is
> > > short-circuited as the companion f-clock is not enabled.
> > > This can cause a data abort if the IDLEST has not transitioned,
> > > and we try to access a USBTLL register.
> > >
> > > Since the USBTLL i-clock and f-clock could be enabled in any order,
> > > this is a bug. Fix it by changing the clkops for the f-clock.
> > >
> > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
>
> It looks fine to me. I will queue it for a -rc branch.
Will requeue this for 2.6.36 merge window since it is not a regression,
and it seems that Linus wants regression fixes for the -rc series...
- Paul
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-06-24 0:20 ` Paul Walmsley
@ 2010-06-24 6:08 ` Gadiyar, Anand
2010-06-24 6:28 ` Paul Walmsley
0 siblings, 1 reply; 10+ messages in thread
From: Gadiyar, Anand @ 2010-06-24 6:08 UTC (permalink / raw
To: Paul Walmsley; +Cc: linux-omap@vger.kernel.org, Tony Lindgren
Paul Walmsley wrote:
> On Mon, 21 Jun 2010, Paul Walmsley wrote:
> > On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
> > > Gadiyar, Anand wrote:
> > > > We need to wait on the IDLEST bit after the clocks are enabled
> > > > before attempting to access any register.
> > > >
> > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> > > > i-clock is enabled first, the clkops_omap2_dflt_wait is
> > > > short-circuited as the companion f-clock is not enabled.
> > > > This can cause a data abort if the IDLEST has not transitioned,
> > > > and we try to access a USBTLL register.
> > > >
> > > > Since the USBTLL i-clock and f-clock could be enabled in any order,
> > > > this is a bug. Fix it by changing the clkops for the f-clock.
> > > >
> > > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> >
> > It looks fine to me. I will queue it for a -rc branch.
>
> Will requeue this for 2.6.36 merge window since it is not a regression,
> and it seems that Linus wants regression fixes for the -rc series...
>
I received a bug-report last Friday from some user of the recently-merged
ohci-omap3 driver about a data-abort caused at driver load. This patch
fixes that issue.
This wasn't known to me when I originally submitted the patch, but looks
like this is a problem caused in a driver that went in in the last merge
window. So maybe this patch can go in in the -rc series. ;)
It's your call. I'm not particular.
- Anand
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-06-24 6:08 ` Gadiyar, Anand
@ 2010-06-24 6:28 ` Paul Walmsley
2010-07-01 10:53 ` Tony Lindgren
0 siblings, 1 reply; 10+ messages in thread
From: Paul Walmsley @ 2010-06-24 6:28 UTC (permalink / raw
To: Tony Lindgren; +Cc: Gadiyar, Anand, linux-omap@vger.kernel.org
Hi Tony,
what do you think on this one? -rc or .36?
- Paul
On Thu, 24 Jun 2010, Gadiyar, Anand wrote:
> Paul Walmsley wrote:
> > On Mon, 21 Jun 2010, Paul Walmsley wrote:
> > > On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
> > > > Gadiyar, Anand wrote:
> > > > > We need to wait on the IDLEST bit after the clocks are enabled
> > > > > before attempting to access any register.
> > > > >
> > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> > > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> > > > > i-clock is enabled first, the clkops_omap2_dflt_wait is
> > > > > short-circuited as the companion f-clock is not enabled.
> > > > > This can cause a data abort if the IDLEST has not transitioned,
> > > > > and we try to access a USBTLL register.
> > > > >
> > > > > Since the USBTLL i-clock and f-clock could be enabled in any order,
> > > > > this is a bug. Fix it by changing the clkops for the f-clock.
> > > > >
> > > > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> > >
> > > It looks fine to me. I will queue it for a -rc branch.
> >
> > Will requeue this for 2.6.36 merge window since it is not a regression,
> > and it seems that Linus wants regression fixes for the -rc series...
> >
>
> I received a bug-report last Friday from some user of the recently-merged
> ohci-omap3 driver about a data-abort caused at driver load. This patch
> fixes that issue.
>
> This wasn't known to me when I originally submitted the patch, but looks
> like this is a problem caused in a driver that went in in the last merge
> window. So maybe this patch can go in in the -rc series. ;)
>
> It's your call. I'm not particular.
- Paul
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-06-24 6:28 ` Paul Walmsley
@ 2010-07-01 10:53 ` Tony Lindgren
2010-07-01 16:48 ` Paul Walmsley
0 siblings, 1 reply; 10+ messages in thread
From: Tony Lindgren @ 2010-07-01 10:53 UTC (permalink / raw
To: Paul Walmsley; +Cc: Gadiyar, Anand, linux-omap@vger.kernel.org
* Paul Walmsley <paul@pwsan.com> [100624 09:22]:
> Hi Tony,
>
> what do you think on this one? -rc or .36?
If we want to try to get it into the -rc cycle, the description
should mention what it fixes and show the error. Otherwise it might
be hard to argue this is a real fix or a regression.
Regards,
Tony
>
> - Paul
>
> On Thu, 24 Jun 2010, Gadiyar, Anand wrote:
>
> > Paul Walmsley wrote:
> > > On Mon, 21 Jun 2010, Paul Walmsley wrote:
> > > > On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
> > > > > Gadiyar, Anand wrote:
> > > > > > We need to wait on the IDLEST bit after the clocks are enabled
> > > > > > before attempting to access any register.
> > > > > >
> > > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> > > > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> > > > > > i-clock is enabled first, the clkops_omap2_dflt_wait is
> > > > > > short-circuited as the companion f-clock is not enabled.
> > > > > > This can cause a data abort if the IDLEST has not transitioned,
> > > > > > and we try to access a USBTLL register.
> > > > > >
> > > > > > Since the USBTLL i-clock and f-clock could be enabled in any order,
> > > > > > this is a bug. Fix it by changing the clkops for the f-clock.
> > > > > >
> > > > > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> > > >
> > > > It looks fine to me. I will queue it for a -rc branch.
> > >
> > > Will requeue this for 2.6.36 merge window since it is not a regression,
> > > and it seems that Linus wants regression fixes for the -rc series...
> > >
> >
> > I received a bug-report last Friday from some user of the recently-merged
> > ohci-omap3 driver about a data-abort caused at driver load. This patch
> > fixes that issue.
> >
> > This wasn't known to me when I originally submitted the patch, but looks
> > like this is a problem caused in a driver that went in in the last merge
> > window. So maybe this patch can go in in the -rc series. ;)
> >
> > It's your call. I'm not particular.
>
>
>
> - Paul
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
2010-07-01 10:53 ` Tony Lindgren
@ 2010-07-01 16:48 ` Paul Walmsley
0 siblings, 0 replies; 10+ messages in thread
From: Paul Walmsley @ 2010-07-01 16:48 UTC (permalink / raw
To: Tony Lindgren; +Cc: Gadiyar, Anand, linux-omap@vger.kernel.org
On Thu, 1 Jul 2010, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [100624 09:22]:
> > Hi Tony,
> >
> > what do you think on this one? -rc or .36?
>
> If we want to try to get it into the -rc cycle, the description
> should mention what it fixes and show the error. Otherwise it might
> be hard to argue this is a real fix or a regression.
Thanks, I'll queue it for .36.
- Paul
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-07-01 16:48 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-06 6:28 [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk Anand Gadiyar
2010-06-18 20:55 ` Gadiyar, Anand
2010-06-21 21:45 ` Paul Walmsley
2010-06-22 16:46 ` Gadiyar, Anand
2010-06-24 0:20 ` Paul Walmsley
2010-06-24 6:08 ` Gadiyar, Anand
2010-06-24 6:28 ` Paul Walmsley
2010-07-01 10:53 ` Tony Lindgren
2010-07-01 16:48 ` Paul Walmsley
2010-06-21 15:07 ` Kevin Hilman
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.