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: Russell King - ARM Linux on 1 May 2010 18:50 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...) -- 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 19:10 2010/5/2 Russell King - ARM Linux <linux(a)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 -- 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 19:30 On Sat, May 1, 2010 at 4:04 PM, Linus Walleij <linus.ml.walleij(a)gmail.com> wrote: > 2010/5/2 Russell King - ARM Linux <linux(a)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? -- 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 1 May 2010 19:30 On Sun, May 02, 2010 at 01:04:37AM +0200, Linus Walleij wrote: > 2010/5/2 Russell King - ARM Linux <linux(a)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. -- 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 19:30
On Sat, May 1, 2010 at 3:44 PM, Russell King - ARM Linux <linux(a)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 -- 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/ |