ARM: PrimeCell DMA Interface v5
in [Kernel]
|
Prev: Failed to initialize MSI interrupts && ioremap reserve_memtype failed -22
Next: x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32
From: Linus Walleij on 17 Apr 2010 01:00 2010/4/15 Dan Williams <dan.j.williams(a)intel.com>: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Walleij on 30 Apr 2010 14:40 2010/4/22 Russell King - ARM Linux <linux(a)arm.linux.org.uk>: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 30 Apr 2010 16:10 On Sat, Apr 17, 2010 at 06:58:49AM +0200, Linus Walleij wrote: > 2010/4/15 Dan Williams <dan.j.williams(a)intel.com>: > > > 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.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Williams on 1 May 2010 18:10 On Thu, Apr 22, 2010 at 4:00 AM, Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > On Sat, Apr 17, 2010 at 06:58:49AM +0200, Linus Walleij wrote: >> 2010/4/15 Dan Williams <dan.j.williams(a)intel.com>: >> >> > 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.) Just to clarify are you nak'ing these patches for upstream inclusion until this testing occurs? Or do we just need a !ARCH_VERSATILE somewhere to allow any incompatibilities to be worked out later in-tree? I am not convinced this is the long term approach we want to follow for architecture specific extensions to dmaengine, but it is has the nice property of being minimally obtrusive and the best proposal of the moment. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Walleij on 1 May 2010 18:30
2010/5/2 Dan Williams <dan.j.williams(a)intel.com>: > On Thu, Apr 22, 2010 at 4:00 AM, Russell King - ARM Linux > <linux(a)arm.linux.org.uk> wrote: >> 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.) > > Just to clarify are you nak'ing these patches for upstream inclusion > until this testing occurs? �Or do we just need a !ARCH_VERSATILE > somewhere to allow any incompatibilities to be worked out later > in-tree? None of the stuff you have applied is included in the objects compiled for Versatile boards. The PL022 driver probably works with Versatile but noone has tested it and it's not included in any defconfigs. What I though Russell was worried about was the PL011 and PL180 drivers which *are* in use by Versatile. So to be clear: none of the stuff that touches the Versatile platform has been applied so far. Only the U300/U8500 specific stuff has been patched in, and I'm suggesting also the PL022 driver which is currently only used by U300 and U8500 to be patched. That said I hope to bring in help, run QEMU or similar ASAP so that also the PL011 and PL180 can be cleanly applied for 2.6.35... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |