This is the fifth iteration of this ever growing patch set
for PrimeCell DMA support, reposting the entire series.
This now depend on stuff pending in Dan Williams async_tx
(DMA Devices/Engine) tree and Andrew Mortons tree where
the new DMA40 driver for U8500 is queued.
I suggest putting these into Andrews tree now, since:
A) 4 of the patches it touches MMCI code which is hanled
by Andrew
B) It extends the DMA40 driver which is now pending in
his tree as well.
C) Since there doesn't seem to be any consensus of whether
this is the right way forward, it needs some wider
testing I believe.
OK?
Yours,
Linus Walleij
Hi Linus, back online now.
On Wed, Apr 7, 2010 at 4:12 PM, Linus Walleij
<[email protected]> wrote:
> This is the fifth iteration of this ever growing patch set
> for PrimeCell DMA support, reposting the entire series.
>
> This now depend on stuff pending in Dan Williams async_tx
> (DMA Devices/Engine) tree and Andrew Mortons tree where
> the new DMA40 driver for U8500 is queued.
>
> I suggest putting these into Andrews tree now, since:
>
> A) 4 of the patches it touches MMCI code which is hanled
> ? by Andrew
>
Ok, but it looks like they do not have a build dependency on dma bits
so they could be merged separately i.e. on top of the async_tx branch.
> B) It extends the DMA40 driver which is now pending in
> ? his tree as well.
>
> C) Since there doesn't seem to be any consensus of whether
> ? this is the right way forward, it needs some wider
> ? testing I believe.
No consensus with respect to which pieces, the Primecell driver or
something outside of drivers/dma? Forgive me for missing recent
conversations if this has been discussed to death already.
> OK?
I can go ahead and queue up the dma bits unless you would prefer, and
Andrew agrees, to take this all through the -mm tree?
--
Dan
[Dan]
> > I suggest putting these into Andrews tree now, since:
> >
> > A) 4 of the patches it touches MMCI code which is hanled
> > ? by Andrew
>
> Ok, but it looks like they do not have a build dependency on dma bits
> so they could be merged separately i.e. on top of the async_tx branch.
Well:
[PATCH 04/11] ARM: define the PrimeCell DMA API v5
Is independent. (One .h-file.)
[PATCH 05/11] ARM: add generic PrimeCell interface to COH 901 318 v5
[PATCH 06/11] ARM: add generic PrimeCell interface to DMA40 v1
Depends on 04 AND has a merge dependency on the recent patches for generic
channel control and status, and then the DMA40 driver which is now
Picked into Andrews -mm. So the whole thing does depend on async_tx
HEAD.
Is it possible to move the two DMA40 patches over from -mm to async_tx
to atleast lower the complexity a little bit? (Should be to just
apply them...)
If this is done, you could apply the above three patches to the
async_tx tree.
[PATCH 07/11] ARM: add PrimeCell generic DMA to MMCI/PL180 v5
This is where is starts to get complicated because this patch
Depends on 01, 02, 03, 04. So it has to be applied to a tree
which contains all of it.
[PATCH 08/11] ARM: add PrimeCell generic DMA to PL011 v5
Just depends on 04 (that's the idea, a generic PrimeCell interface)
so could be applied to the async_tx tree
if the others go in there.
[PATCH 09/11] ARM: add PrimeCell generic DMA to PL022 v5
Same thing, plus it is Acked-by: Grant and OK to merge into
async_tx if 04 is there.
[PATCH 10/11] ARM: config U300 PL180 PL011 PL022 for DMA v5
[PATCH 11/11] ARM: config Ux500 PL011 PL022 for DMA v1
These should go in through the ARM tree really, it's platform
data.
> > B) It extends the DMA40 driver which is now pending in
> > ? his tree as well.
> >
> > C) Since there doesn't seem to be any consensus of whether
> > ? this is the right way forward, it needs some wider
> > ? testing I believe.
>
> No consensus with respect to which pieces, the Primecell driver or
> something outside of drivers/dma? Forgive me for missing recent
> conversations if this has been discussed to death already.
Well, I'd want Russell to comment on that, I think from the
PrimeCell point of view it is important that the file we put
in place in <linux/amba/dma.h> is something that will really
be likely to a good path forward for all PrimeCell and derivates.
And I really would like Russell to ACK that first, he historically
watches over the PrimeCell stuff.
But that said I think we're pretty solid:
- Implementation for three vastly different PrimeCells
- Implementation for two vastly different DMA engines
- It works in these combos (we've had lots of internal testing on these)
> I can go ahead and queue up the dma bits unless you would prefer, and
> Andrew agrees, to take this all through the -mm tree?
If it's OK with Russell, putting 04-06 plus 09 through async_tx
tree is a good starter.
07 is problematic and require the entire series to be applied
in one go, 08 could be applied as well but needs Russells ACK.
Yours,
Linus Walleij
Russell,
are you OK with pushing these patches from this series:
patch 01 - <linux/amba/dma.h>
patch 08 - DMA for drivers/serial/amba-pl011.c
through Dan's async_tx / DMAengine tree?
I think those are the ones which need your Acked-by to proceed.
If you have some other idea of how these patches should be twisted
around please let me know!
Yours,
Linus Walleij
On Sun, Apr 11, 2010 at 04:13:39PM +0200, Linus Walleij wrote:
> Russell,
>
> are you OK with pushing these patches from this series:
>
> patch 01 - <linux/amba/dma.h>
> patch 08 - DMA for drivers/serial/amba-pl011.c
>
> through Dan's async_tx / DMAengine tree?
>
> I think those are the ones which need your Acked-by to proceed.
>
> If you have some other idea of how these patches should be twisted
> around please let me know!
I do think it would be of value for someone to try to get this working
on the Realview boards to ensure that these patches are well proven...
unfortunately I don't have the bandwidth to do that at present.
Hi Linus,
On Wed, Apr 7, 2010 at 11:35 PM, Linus WALLEIJ
<[email protected]> wrote:
> If it's OK with Russell, putting 04-06 plus 09 through async_tx
> tree is a good starter.
Getting closer... I have pushed out the dma40 driver (v3), 4, and 6.
The other patch in -mm I could take as well but that needs an ack from
Russell.
5 is pending the review comment and 9 does not apply cleanly (does it
depend on something in the spi tree?)
--
Dan
2010/4/15 Dan Williams <[email protected]>:
> Getting closer... I have pushed out the dma40 driver (v3), 4, and 6.
That's great!
> The other patch in -mm I could take as well but that needs an ack from
> Russell.
Nah, I'll push that in through Russells tree hopefully, it needs rebasing on
the latest board setup code anyway.
> 5 is pending the review comment and 9 does not apply cleanly (does it
> depend on something in the spi tree?)
OK I'm sending updated versions soon, along with a DMA40 bug fix
all on top of async_tx instead.
Number 9 fails since it is based on -next where all the #include <slab.h>
business has taken place, I don't know how that is resolved in the end
but it now includes that include and applies cleanly on async_tx.
I'll keep working on getting the PL011 and PL180 DMA tested on the
RealView somehow so those can also be accepted.
Your,
Linus Walleij
2010/4/22 Russell King - ARM Linux <[email protected]>:
>> I'll keep working on getting the PL011 and PL180 DMA tested on the
>> RealView somehow so those can also be accepted.
>
> So has this (which has now been applied to Dan's tree) been tested
> as I asked on Versatile platforms, or do we have something that could
> be incompatible with those platforms?
I tested them on U300 which has an unmodified PL011 block, both with
and without DMA support compiled in. I have tested the Pl180 mods
on the U300 as well, it has a slightly modified PL180 block.
I have no other hardware...
I will try too boot it up in the QEMU emulator, it has an emulated
PL011 atleast that should account for something? I don't think
it emulates the PL180 though. :-(
> I'm basically not acking or applying these patches until something
> along those lines has happened. ?(And unfortunately I don't have the
> resources to apply to this at present.)
I understand this. I will have to try to dig out some ARM reference
design from somewhere, I cannot afford one sadly.
ARM Ltd. people on this list: if you can send me a versatile
machine, mail me in private for post address...
Yours,
Linus Walleij
On Sat, Apr 17, 2010 at 06:58:49AM +0200, Linus Walleij wrote:
> 2010/4/15 Dan Williams <[email protected]>:
>
> > Getting closer... I have pushed out the dma40 driver (v3), 4, and 6.
>
> That's great!
>
> > The other patch in -mm I could take as well but that needs an ack from
> > Russell.
>
> Nah, I'll push that in through Russells tree hopefully, it needs rebasing on
> the latest board setup code anyway.
>
> > 5 is pending the review comment and 9 does not apply cleanly (does it
> > depend on something in the spi tree?)
>
> OK I'm sending updated versions soon, along with a DMA40 bug fix
> all on top of async_tx instead.
>
> Number 9 fails since it is based on -next where all the #include <slab.h>
> business has taken place, I don't know how that is resolved in the end
> but it now includes that include and applies cleanly on async_tx.
>
> I'll keep working on getting the PL011 and PL180 DMA tested on the
> RealView somehow so those can also be accepted.
So has this (which has now been applied to Dan's tree) been tested
as I asked on Versatile platforms, or do we have something that could
be incompatible with those platforms?
I'm basically not acking or applying these patches until something
along those lines has happened. (And unfortunately I don't have the
resources to apply to this at present.)