[PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[Gadiyar, Anand]

From: Anand Gadiyar <gadiyar@ti.com>

Bug in existing code causes synchro control to be set +32 if request
line greater than 63 is used.

Reported by Wenbiao Wang

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
---
Patch generated against OMAPZOOM tree. Will apply against
linux-omap as well with an offset of 8 lines.

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 562089e..b38a362 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -287,10 +287,7 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count,
 
 		val = dma_read(CCR(lch));
 		val &= ~(3 << 19);
-		if (dma_trigger > 63)
-			val |= 1 << 20;
-		if (dma_trigger > 31)
-			val |= 1 << 19;
+		val |= ((dma_trigger & ~(0x1f)) << 14);
 
 		val &= ~(0x1f);
 		val |= (dma_trigger & 0x1f);

RE: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[Pandita, Vikram]

Pushed to zoom tree.

>-----Original Message-----
>From: Gadiyar, Anand
>Sent: Monday, November 10, 2008 5:08 AM
>To: linux-omap@vger.kernel.org
>Cc: Pandita, Vikram; tony@atomide.com
>Subject: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63
>
>From: Anand Gadiyar <gadiyar@ti.com>
>
>Bug in existing code causes synchro control to be set +32 if request
>line greater than 63 is used.
>
>Reported by Wenbiao Wang
>
>Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
>---
>Patch generated against OMAPZOOM tree. Will apply against
>linux-omap as well with an offset of 8 lines.
>
>diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
>index 562089e..b38a362 100644
>--- a/arch/arm/plat-omap/dma.c
>+++ b/arch/arm/plat-omap/dma.c
>@@ -287,10 +287,7 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count,
>
> 		val = dma_read(CCR(lch));
> 		val &= ~(3 << 19);
>-		if (dma_trigger > 63)
>-			val |= 1 << 20;
>-		if (dma_trigger > 31)
>-			val |= 1 << 19;
>+		val |= ((dma_trigger & ~(0x1f)) << 14);
>
> 		val &= ~(0x1f);
> 		val |= (dma_trigger & 0x1f);

Re: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[Tony Lindgren]

* Pandita, Vikram <vikram.pandita@ti.com> [081111 15:34]:
> Pushed to zoom tree.

Sorry for the long delay with this. Pushing to l-o tree and
added to omap-fixes queue.

Tony


> >-----Original Message-----
> >From: Gadiyar, Anand
> >Sent: Monday, November 10, 2008 5:08 AM
> >To: linux-omap@vger.kernel.org
> >Cc: Pandita, Vikram; tony@atomide.com
> >Subject: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63
> >
> >From: Anand Gadiyar <gadiyar@ti.com>
> >
> >Bug in existing code causes synchro control to be set +32 if request
> >line greater than 63 is used.
> >
> >Reported by Wenbiao Wang
> >
> >Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> >---
> >Patch generated against OMAPZOOM tree. Will apply against
> >linux-omap as well with an offset of 8 lines.
> >
> >diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> >index 562089e..b38a362 100644
> >--- a/arch/arm/plat-omap/dma.c
> >+++ b/arch/arm/plat-omap/dma.c
> >@@ -287,10 +287,7 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count,
> >
> > 		val = dma_read(CCR(lch));
> > 		val &= ~(3 << 19);
> >-		if (dma_trigger > 63)
> >-			val |= 1 << 20;
> >-		if (dma_trigger > 31)
> >-			val |= 1 << 19;
> >+		val |= ((dma_trigger & ~(0x1f)) << 14);
> >
> > 		val &= ~(0x1f);
> > 		val |= (dma_trigger & 0x1f);
> --
> 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

Re: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[twebb]

>
> Sorry for the long delay with this. Pushing to l-o tree and
> added to omap-fixes queue.
>

Probably understood by most of you, but what is the difference between
"pushing to l-o tree" and "adding to omap-fixes queue"?  What are the
omap-fixes queued for if not the l-o tree?  I'm trying to understand
the flow of fixes/changes in the l-o tree, but it's obviously not
clear to me yet.

Thanks.

Re: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[Tony Lindgren]

* twebb <taliaferro62@gmail.com> [090108 15:40]:
> >
> > Sorry for the long delay with this. Pushing to l-o tree and
> > added to omap-fixes queue.
> >
> 
> Probably understood by most of you, but what is the difference between
> "pushing to l-o tree" and "adding to omap-fixes queue"?  What are the
> omap-fixes queued for if not the l-o tree?  I'm trying to understand
> the flow of fixes/changes in the l-o tree, but it's obviously not
> clear to me yet.

Well l-o tree is short for the linux-omap tree. Then I have various
queues of stuff going into the mainline kernel:

omap-fixes
omap-upstream
omap1-upstream
omap2-upstream
omap3-upstream
...

Out of these queues omap-fixes will be sent out as needed during the
-rc cycle, while omap*-upstream queues are stuff for the next merge
window.

These branches show up at the git web interface at the bottom:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary

Not that many patches in these queues right now, btw.

Tony

Re: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[twebb]

>
> Well l-o tree is short for the linux-omap tree. Then I have various
> queues of stuff going into the mainline kernel:
>
> omap-fixes
> omap-upstream
> omap1-upstream
> omap2-upstream
> omap3-upstream
> ...
>
> Out of these queues omap-fixes will be sent out as needed during the
> -rc cycle, while omap*-upstream queues are stuff for the next merge
> window.
>
> These branches show up at the git web interface at the bottom:
>
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
>
> Not that many patches in these queues right now, btw.
>

That's very helpful.  Would you mind confirming/answering a few more questions?

1.  Generally, are all fixes/changes that go to any of the queues
headed to the mainline always pushed into the l-o tree?  If not, why
not?
2.  How about the reverse - are all l-o fixes/changes eventually
queued to mainline?  Or is there certain l-o functionality that won't
ever go to mainline?
3.  By "merge window" do you mean times that you pull mainline updates
down into l-o tree?

Thanks.

Re: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[Tony Lindgren]

* twebb <taliaferro62@gmail.com> [090108 16:08]:
> >
> > Well l-o tree is short for the linux-omap tree. Then I have various
> > queues of stuff going into the mainline kernel:
> >
> > omap-fixes
> > omap-upstream
> > omap1-upstream
> > omap2-upstream
> > omap3-upstream
> > ...
> >
> > Out of these queues omap-fixes will be sent out as needed during the
> > -rc cycle, while omap*-upstream queues are stuff for the next merge
> > window.
> >
> > These branches show up at the git web interface at the bottom:
> >
> > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
> >
> > Not that many patches in these queues right now, btw.
> >
> 
> That's very helpful.  Would you mind confirming/answering a few more questions?
> 
> 1.  Generally, are all fixes/changes that go to any of the queues
> headed to the mainline always pushed into the l-o tree?  If not, why
> not?

If something is updated with the patches going into the mainline, they
may not get updated in the l-o tree until the changes fall down during
the next merge with mainline.

> 2.  How about the reverse - are all l-o fixes/changes eventually
> queued to mainline?  Or is there certain l-o functionality that won't
> ever go to mainline?

Only the ones that apply and are ready to go. Ideally we would just
have everything in sync with the mainline tree so everything in l-o
tree would be going to mainline tree. But we still carry around quite
a bit of code that still needs work before submitting to mainline. Some
examples are the clock and PM changes.

> 3.  By "merge window" do you mean times that you pull mainline updates
> down into l-o tree?

Merge window = About two weeks after Linus tags a major release and
before -rc1 is tagged. Since the omap core stuff gets merged via
Russell, we need to have patches going to mainline ready around -rc5
so Russell has enough time to look at them.

Regards,

Tony