* [PATCH 00/11] ARM: PrimeCell DMA Interface v5 @ 2010-04-07 23:12 Linus Walleij 2010-04-07 23:45 ` Dan Williams 0 siblings, 1 reply; 20+ messages in thread From: Linus Walleij @ 2010-04-07 23:12 UTC (permalink / raw) To: akpm, Russell King - ARM Linux, Grant Likely, Dan Williams Cc: linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel, Linus Walleij 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-07 23:12 [PATCH 00/11] ARM: PrimeCell DMA Interface v5 Linus Walleij @ 2010-04-07 23:45 ` Dan Williams 2010-04-08 6:35 ` Linus WALLEIJ 0 siblings, 1 reply; 20+ messages in thread From: Dan Williams @ 2010-04-07 23:45 UTC (permalink / raw) To: Linus Walleij Cc: akpm, Russell King - ARM Linux, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel Hi Linus, back online now. On Wed, Apr 7, 2010 at 4:12 PM, Linus Walleij <linus.walleij@stericsson.com> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-07 23:45 ` Dan Williams @ 2010-04-08 6:35 ` Linus WALLEIJ 2010-04-11 14:13 ` Linus Walleij 2010-04-15 1:15 ` Dan Williams 0 siblings, 2 replies; 20+ messages in thread From: Linus WALLEIJ @ 2010-04-08 6:35 UTC (permalink / raw) To: Dan Williams Cc: akpm, Russell King - ARM Linux, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel [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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-08 6:35 ` Linus WALLEIJ @ 2010-04-11 14:13 ` Linus Walleij 2010-04-12 19:23 ` Russell King - ARM Linux 2010-04-15 1:15 ` Dan Williams 1 sibling, 1 reply; 20+ messages in thread From: Linus Walleij @ 2010-04-11 14:13 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Dan Williams, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-11 14:13 ` Linus Walleij @ 2010-04-12 19:23 ` Russell King - ARM Linux 0 siblings, 0 replies; 20+ messages in thread From: Russell King - ARM Linux @ 2010-04-12 19:23 UTC (permalink / raw) To: Linus Walleij Cc: Dan Williams, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-08 6:35 ` Linus WALLEIJ 2010-04-11 14:13 ` Linus Walleij @ 2010-04-15 1:15 ` Dan Williams 2010-04-17 4:58 ` Linus Walleij 1 sibling, 1 reply; 20+ messages in thread From: Dan Williams @ 2010-04-15 1:15 UTC (permalink / raw) To: Linus WALLEIJ Cc: akpm, Russell King - ARM Linux, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel Hi Linus, On Wed, Apr 7, 2010 at 11:35 PM, Linus WALLEIJ <linus.walleij@stericsson.com> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-15 1:15 ` Dan Williams @ 2010-04-17 4:58 ` Linus Walleij 2010-04-22 11:00 ` Russell King - ARM Linux 0 siblings, 1 reply; 20+ messages in thread From: Linus Walleij @ 2010-04-17 4:58 UTC (permalink / raw) To: Dan Williams Cc: Linus WALLEIJ, akpm, Russell King - ARM Linux, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 2010/4/15 Dan Williams <dan.j.williams@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-17 4:58 ` Linus Walleij @ 2010-04-22 11:00 ` Russell King - ARM Linux 2010-04-30 18:30 ` Linus Walleij 2010-05-01 22:00 ` Dan Williams 0 siblings, 2 replies; 20+ messages in thread From: Russell King - ARM Linux @ 2010-04-22 11:00 UTC (permalink / raw) To: Linus Walleij Cc: Dan Williams, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Sat, Apr 17, 2010 at 06:58:49AM +0200, Linus Walleij wrote: > 2010/4/15 Dan Williams <dan.j.williams@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.) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-22 11:00 ` Russell King - ARM Linux @ 2010-04-30 18:30 ` Linus Walleij 2010-05-01 22:00 ` Dan Williams 1 sibling, 0 replies; 20+ messages in thread From: Linus Walleij @ 2010-04-30 18:30 UTC (permalink / raw) To: Russell King - ARM Linux, Catalin Marinas Cc: Dan Williams, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 2010/4/22 Russell King - ARM Linux <linux@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-04-22 11:00 ` Russell King - ARM Linux 2010-04-30 18:30 ` Linus Walleij @ 2010-05-01 22:00 ` Dan Williams 2010-05-01 22:27 ` Linus Walleij 2010-05-01 22:44 ` Russell King - ARM Linux 1 sibling, 2 replies; 20+ messages in thread From: Dan Williams @ 2010-05-01 22:00 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Linus Walleij, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Thu, Apr 22, 2010 at 4:00 AM, Russell King - ARM Linux <linux@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@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 22:00 ` Dan Williams @ 2010-05-01 22:27 ` Linus Walleij 2010-05-01 22:44 ` Russell King - ARM Linux 1 sibling, 0 replies; 20+ messages in thread From: Linus Walleij @ 2010-05-01 22:27 UTC (permalink / raw) To: Dan Williams, Russell King - ARM Linux Cc: Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 2010/5/2 Dan Williams <dan.j.williams@intel.com>: > On Thu, Apr 22, 2010 at 4:00 AM, Russell King - ARM Linux > <linux@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 22:00 ` Dan Williams 2010-05-01 22:27 ` Linus Walleij @ 2010-05-01 22:44 ` Russell King - ARM Linux 2010-05-01 23:04 ` Linus Walleij 2010-05-01 23:25 ` Dan Williams 1 sibling, 2 replies; 20+ messages in thread From: Russell King - ARM Linux @ 2010-05-01 22:44 UTC (permalink / raw) To: Dan Williams Cc: Linus Walleij, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Sat, May 01, 2010 at 03:00:09PM -0700, Dan Williams wrote: > 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? What I don't want to do is to get into the situation where we throw this patchset into the kernel and then find that we have to invent a whole new implementation in the various primecell drivers to support the Versatile hardware. Versatile has some MUXing on three of the DMA signals, so (eg) we really don't want UARTs claiming DMAs just because they're in existence and not in use - that would prevent DMAs from being used for (eg) AACI or MMC. The alternative is that we could just take the attitude that Versatile/ Realview will never have DMA support implemented, but that seems rather silly, as they've tended to be the first platforms I get new CPU architectures for. (This is why DMA coherency stuff on new architectures tends to be left for others to do...) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 22:44 ` Russell King - ARM Linux @ 2010-05-01 23:04 ` Linus Walleij 2010-05-01 23:28 ` Russell King - ARM Linux 2010-05-01 23:28 ` Dan Williams 2010-05-01 23:25 ` Dan Williams 1 sibling, 2 replies; 20+ messages in thread From: Linus Walleij @ 2010-05-01 23:04 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Dan Williams, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 2010/5/2 Russell King - ARM Linux <linux@arm.linux.org.uk>: > Versatile has some MUXing on three of the DMA signals, so (eg) we > really don't want UARTs claiming DMAs just because they're in existence > and not in use - that would prevent DMAs from being used for (eg) AACI > or MMC. As long as Versatile doesn't specify any filter function or data for the channel allocation function (it currently doesn't and defaults to NULL) it won't even try to call the DMA engine to allocate a channel for say the UART. There is nothing blocking some other peripheral from grabbing a muxed channel in that case. But the implementation of the DMA engine would be better of handling the muxing dynamically I believe, so when the PL011 driver (say) requests a DMA channel, it doesn't mean it requests the *physical* channel and holds it (unless the driver is very naïvely implemented) it nominally means it reserves a placeholder in the DMA engine. When the driver issues a request to perform a DMA transfer, it will pull out a physical channel and use that, then return it. If there is too much combat about the physical channels, you configure out DMA for the least wanted PrimeCells. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 23:04 ` Linus Walleij @ 2010-05-01 23:28 ` Russell King - ARM Linux 2010-05-02 0:21 ` Linus Walleij 2010-05-01 23:28 ` Dan Williams 1 sibling, 1 reply; 20+ messages in thread From: Russell King - ARM Linux @ 2010-05-01 23:28 UTC (permalink / raw) To: Linus Walleij Cc: Dan Williams, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Sun, May 02, 2010 at 01:04:37AM +0200, Linus Walleij wrote: > 2010/5/2 Russell King - ARM Linux <linux@arm.linux.org.uk>: > > > Versatile has some MUXing on three of the DMA signals, so (eg) we > > really don't want UARTs claiming DMAs just because they're in existence > > and not in use - that would prevent DMAs from being used for (eg) AACI > > or MMC. > > As long as Versatile doesn't specify any filter function or > data for the channel allocation function (it currently doesn't and defaults > to NULL) it won't even try to call the DMA engine to allocate a channel > for say the UART. But when we _do_ want to support DMA? > There is nothing blocking some other peripheral from grabbing a > muxed channel in that case. > > But the implementation of the DMA engine would be better of > handling the muxing dynamically I believe, so when the PL011 > driver (say) requests a DMA channel, it doesn't mean it requests the > *physical* channel and holds it (unless the driver is very naïvely > implemented) it nominally means it reserves a placeholder in the > DMA engine. So what happens if we try to use DMA with the PL011 but the physical channels are already in use? From what I can see, it assumes that it always has access to the transmit channel, and there's no recovery if it doesn't. Plus if we can't get DMA for the RX path, it _permanently_ disables all DMA for the device. > When the driver issues a request to perform a DMA transfer, it will pull > out a physical channel and use that, then return it. If there is too > much combat about the physical channels, you configure out DMA > for the least wanted PrimeCells. Three physical channels shared between: AACI Tx, AACI Rx, MMCI 0, MMCI 1, UART3 Tx, UART3 Rx. (USB and smartcard/SIM which we don't implement.) In total there's 10 valid settings for the MUX for each channel, so contention is going to happen. All you need is to load both the AACI and MMCI drivers, and if they want to use the DMA channels, you're already wanting 4 channels with only 3 available. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 23:28 ` Russell King - ARM Linux @ 2010-05-02 0:21 ` Linus Walleij 2010-05-02 8:18 ` Russell King - ARM Linux 0 siblings, 1 reply; 20+ messages in thread From: Linus Walleij @ 2010-05-02 0:21 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Dan Williams, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 2010/5/2 Russell King - ARM Linux <linux@arm.linux.org.uk>: >> But the implementation of the DMA engine would be better of >> handling the muxing dynamically I believe, so when the PL011 >> driver (say) requests a DMA channel, it doesn't mean it requests the >> *physical* channel and holds it (unless the driver is very naďvely >> implemented) it nominally means it reserves a placeholder in the >> DMA engine. > > So what happens if we try to use DMA with the PL011 but the physical > channels are already in use? From what I can see, it assumes that it > always has access to the transmit channel, and there's no recovery if > it doesn't. > > Plus if we can't get DMA for the RX path, it _permanently_ disables > all DMA for the device. OK now I get it.. the point of crux is that you need the drivers to be coded to switch seamlessly back to interrupt mode and retry with DMA on next transaction nevertheless if possible. That is definately possible with the current API, so it's nothing blocking the stuff pending in Dan's tree. However when it comes to the PL011/PL180 drivers you got me there, it surely does assume you either have the channel and can use it or else there is some permanent error on it. I'll twist these patches around a bit, it shouldn't be too hard to come up with some convincing code. > Three physical channels shared between: AACI Tx, AACI Rx, MMCI 0, MMCI 1, > UART3 Tx, UART3 Rx. > (...) > All you need is to load both the AACI > and MMCI drivers, and if they want to use the DMA channels, you're > already wanting 4 channels with only 3 available. Yep, that's where it kicks in. (What's the name of this DMA controller BTW? Is that PL080?) (I read it as MMCI is bidirectional also on the Versatile, as it is on the U300.) However: this way of using the DMA dynamically instead of statically leads to the situation where a UART or two MMCs are using up the DMA channels and AACI cannot use it, and need to fall back to interrupts. Since the Audio traffic is likely to be more important, this is perhaps not so optimal, so a static assignment of DMA channels may be desired after all in a practical scenario. But I'll surely make a try to make all DMA allocation from the PrimeCells dynamic! Yours, Linus Walleij ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-02 0:21 ` Linus Walleij @ 2010-05-02 8:18 ` Russell King - ARM Linux 2010-05-04 13:05 ` Linus WALLEIJ 0 siblings, 1 reply; 20+ messages in thread From: Russell King - ARM Linux @ 2010-05-02 8:18 UTC (permalink / raw) To: Linus Walleij Cc: Dan Williams, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Sun, May 02, 2010 at 02:21:13AM +0200, Linus Walleij wrote: > Yep, that's where it kicks in. (What's the name of this DMA controller > BTW? Is that PL080?) It's one of the standard ARM primecells, with a FPGA controlling the routing of the first three channels. > (I read it as MMCI is bidirectional also on the Versatile, as it is > on the U300.) There are two MMCIs on Versatile. > However: this way of using the DMA dynamically instead of statically > leads to the situation where a UART or two MMCs are using up the > DMA channels and AACI cannot use it, and need to fall back to > interrupts. Since the Audio traffic is likely to be more important, this > is perhaps not so optimal, so a static assignment of DMA channels > may be desired after all in a practical scenario. Such a scenario leads to two of the three channels assigned to AACI (one for playback and the other for record - remember, it's full duplex), leaving one to be shared between the UART Tx and Rx, and two MMCIs. I'd disagree with you and say that MMCI would be more important than AACI. The data rate for MMCI is far higher than AACI - and remember ARM MMCIs overflow if you don't read the data fast enough. The MMCI fmax parameter only exists to put a cap on the rate of the transfer so that the CPU can read the data fast enough in PIO mode. However, you only need DMA for MMCI if there's a card inserted in the slot. If there's no card in the slot, there's no point starving AACI of a DMA channel if that's what is being used. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-02 8:18 ` Russell King - ARM Linux @ 2010-05-04 13:05 ` Linus WALLEIJ 0 siblings, 0 replies; 20+ messages in thread From: Linus WALLEIJ @ 2010-05-04 13:05 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Dan Williams, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel The latest patchset is now also tested on the ARM-RealView PB11MPCore. My best friends over at Ericsson AB helped me out by lending me their board for a short session. See bootlog below... - UART console comes up fine and is interactive - MMCI card mounts and you can list and copy files No DMA in use since the PL081 in this machine does not have a driver yet, but no regressions in sight. This should be similar to Versatile or Integrator. Is this OK now Russell? Yours, Linus Walleij Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-rc6-next-20100503-00033-gc482e92 (linus@fecusia) (gcc vers0 CPU: ARMv6-compatible processor [410fb020] revision 0 (ARMv7), cr=00c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: ARM-RealView PB11MPCore Ignoring unrecognised tag 0x00000000 Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/nfs nfsroot=192.168.0.3:/export/rootfs/rootfs-ant PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 120360k/120360k available, 10712k reserved, 0K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xffc00000 - 0xffe00000 ( 2 MB) vmalloc : 0xc8800000 - 0xf8000000 ( 760 MB) lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc0672000 (6568 kB) .text : 0xc0672000 - 0xc0909000 (2652 kB) .data : 0xc0922000 - 0xc093d400 ( 109 kB) Hierarchical RCU implementation. NR_IRQS:128 Console: colour dummy device 80x30 Calibrating delay loop... 83.76 BogoMIPS (lpj=418816) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 L2X0 cache controller enabled Serial: AMBA PL011 UART driver dev:uart0: ttyAMA0 at MMIO 0x10009000 (irq = 36) is a AMBA/PL011 console [ttyAMA0] enabled dev:uart1: ttyAMA1 at MMIO 0x1000a000 (irq = 37) is a AMBA/PL011 dev:uart2: ttyAMA2 at MMIO 0x1000b000 (irq = 78) is a AMBA/PL011 fpga:uart3: ttyAMA3 at MMIO 0x1000c000 (irq = 79) is a AMBA/PL011 bio: create slab <bio-0> at 0 Advanced Linux Sound Architecture Driver Version 1.0.23. Switching to clocksource timer3 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. msgmni has been set to 235 io scheduler noop registered io scheduler deadline registered (default) CLCD: RealView hardware, XVGA display Console: switching to colour frame buffer device 128x48 armflash.0-0: Found 2 x16 devices at 0x0 in 32-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled armflash.0-1: Found 2 x16 devices at 0x0 in 32-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Concatenating MTD devices: (0): "armflash.0-0" (1): "armflash.0-1" into device "armflash.0" RedBoot partition parsing not available afs partition parsing not available smsc911x: Driver version 2008-10-21. smsc911x-mdio: probed eth0: attached PHY driver [SMSC LAN911x Internal PHY] (mii_bus:phy_addr=0:01, i) net eth0: MAC Address: 00:02:f7:00:3a:80 mice: PS/2 mouse device common for all mice mmci-pl18x fpga:mmc0: mmc0: MMCI/PL180 manf 41 rev 0 cfg 00 at 0x000000001000500 mmci-pl18x fpga:mmc0: IRQ 46, 47 (pio) aaci-pl041 fpga:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 32, fifo 52 ALSA device list: #0: ARM AC'97 Interface at 0x0000000010004000, irq 32 TCP cubic registered NET: Registered protocol family 17 VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 3 mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address e624 mmcblk0: mmc0:e624 SU256 241 MiB mmcblk0: p1 net eth0: SMSC911x/921x identified at 0xc8880000, IRQ: 41 atkbd serio0: keyboard reset failed on fpga:kmi0 IP-Config: Complete: device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.1, host=arm11mpcore, domain=, nis-domain=(none), bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath= Warning: unable to open an initial console. Freeing init memory: 6568K input: AT Raw Set 2 keyboard as /class/input/input0 Please press Enter to activate this console. starting pid 342, tty '/dev/ttyAMA0': '/bin/sh -sc ". /etc/profile"' root@ME:/ root@ME:/ Yours, Linus Walleij ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 23:04 ` Linus Walleij 2010-05-01 23:28 ` Russell King - ARM Linux @ 2010-05-01 23:28 ` Dan Williams 2010-05-01 23:48 ` Linus Walleij 1 sibling, 1 reply; 20+ messages in thread From: Dan Williams @ 2010-05-01 23:28 UTC (permalink / raw) To: Linus Walleij Cc: Russell King - ARM Linux, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Sat, May 1, 2010 at 4:04 PM, Linus Walleij <linus.ml.walleij@gmail.com> wrote: > 2010/5/2 Russell King - ARM Linux <linux@arm.linux.org.uk>: > >> Versatile has some MUXing on three of the DMA signals, so (eg) we >> really don't want UARTs claiming DMAs just because they're in existence >> and not in use - that would prevent DMAs from being used for (eg) AACI >> or MMC. > > As long as Versatile doesn't specify any filter function or > data for the channel allocation function (it currently doesn't and defaults > to NULL) it won't even try to call the DMA engine to allocate a channel > for say the UART. > > There is nothing blocking some other peripheral from grabbing a > muxed channel in that case. > > But the implementation of the DMA engine would be better of > handling the muxing dynamically I believe, so when the PL011 > driver (say) requests a DMA channel, it doesn't mean it requests the > *physical* channel and holds it (unless the driver is very naďvely > implemented) it nominally means it reserves a placeholder in the > DMA engine. > > When the driver issues a request to perform a DMA transfer, it will pull > out a physical channel and use that, then return it. If there is too > much combat about the physical channels, you configure out DMA > for the least wanted PrimeCells. > Could you simulate this by publishing more struct dma_chans than are physically present, and then handle the muxing internal to the driver? Or am I misunderstanding the usage model? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 23:28 ` Dan Williams @ 2010-05-01 23:48 ` Linus Walleij 0 siblings, 0 replies; 20+ messages in thread From: Linus Walleij @ 2010-05-01 23:48 UTC (permalink / raw) To: Dan Williams Cc: Russell King - ARM Linux, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel 2010/5/2 Dan Williams <dan.j.williams@intel.com>: > On Sat, May 1, 2010 at 4:04 PM, Linus Walleij >> When the driver issues a request to perform a DMA transfer, it will pull >> out a physical channel and use that, then return it. If there is too >> much combat about the physical channels, you configure out DMA >> for the least wanted PrimeCells. >> > > Could you simulate this by publishing more struct dma_chans than are > physically present, and then handle the muxing internal to the driver? > Or am I misunderstanding the usage model? Yes exactly that way. What I had in mind atleast. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/11] ARM: PrimeCell DMA Interface v5 2010-05-01 22:44 ` Russell King - ARM Linux 2010-05-01 23:04 ` Linus Walleij @ 2010-05-01 23:25 ` Dan Williams 1 sibling, 0 replies; 20+ messages in thread From: Dan Williams @ 2010-05-01 23:25 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Linus Walleij, Linus WALLEIJ, akpm, Grant Likely, linux-arm-kernel, linux-mmc, STEricsson_nomadik_linux, linux-kernel On Sat, May 1, 2010 at 3:44 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Sat, May 01, 2010 at 03:00:09PM -0700, Dan Williams wrote: >> 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? > > What I don't want to do is to get into the situation where we throw > this patchset into the kernel and then find that we have to invent a > whole new implementation in the various primecell drivers to support > the Versatile hardware. > > Versatile has some MUXing on three of the DMA signals, so (eg) we > really don't want UARTs claiming DMAs just because they're in existence > and not in use - that would prevent DMAs from being used for (eg) AACI > or MMC. > > The alternative is that we could just take the attitude that Versatile/ > Realview will never have DMA support implemented, but that seems rather > silly, as they've tended to be the first platforms I get new CPU > architectures for. (This is why DMA coherency stuff on new architectures > tends to be left for others to do...) Ok, it will be good to have this approach vetted on a challenging arch. We'll see where things stand when the merge window opens. -- Dan ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-05-04 13:06 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-07 23:12 [PATCH 00/11] ARM: PrimeCell DMA Interface v5 Linus Walleij 2010-04-07 23:45 ` Dan Williams 2010-04-08 6:35 ` Linus WALLEIJ 2010-04-11 14:13 ` Linus Walleij 2010-04-12 19:23 ` Russell King - ARM Linux 2010-04-15 1:15 ` Dan Williams 2010-04-17 4:58 ` Linus Walleij 2010-04-22 11:00 ` Russell King - ARM Linux 2010-04-30 18:30 ` Linus Walleij 2010-05-01 22:00 ` Dan Williams 2010-05-01 22:27 ` Linus Walleij 2010-05-01 22:44 ` Russell King - ARM Linux 2010-05-01 23:04 ` Linus Walleij 2010-05-01 23:28 ` Russell King - ARM Linux 2010-05-02 0:21 ` Linus Walleij 2010-05-02 8:18 ` Russell King - ARM Linux 2010-05-04 13:05 ` Linus WALLEIJ 2010-05-01 23:28 ` Dan Williams 2010-05-01 23:48 ` Linus Walleij 2010-05-01 23:25 ` Dan Williams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).