Messages in this thread | | | Date | Sat, 30 Jul 2011 20:30:07 +0530 | Subject | Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id | From | Jaswinder Singh <> |
| |
On 30 July 2011 19:52, Russell King <rmk@arm.linux.org.uk> wrote: > On Sat, Jul 30, 2011 at 06:39:13PM +0530, Jaswinder Singh wrote: >> On 29 July 2011 04:10, Russell King <rmk@arm.linux.org.uk> wrote: >> >> >> > Board 3 has the MMCI connected through an external FPGA mux, which can route the >> >> > MMCI requests to DMA request signals #1, #2 or #3. >> >> Say >> >> Board3 >> >> MMCI_RX -> #{1,2,3} >> >> MMCI_TX -> #{1,2,3} >> >> And you can't change the route(mapping) after the dmac driver has >> >> been loaded. >> > >> > No. You have to change it dynamically at run time according to the >> > DMA activity, because DMA request signals #1, #2 and #3 are shared >> > between 6 devices. To make matters worse, it's not six on any of >> > RQ#1 RQ#2 RQ#3, but some on a couple, some on another couple, and >> > some on all three. >> > >> > BTW, we do support this with Linus W's code (which he's posted to >> > this thread.) >> >> In case you missed my reply to these runtime switching cases, >> please have a look at https://lkml.org/lkml/2011/7/29/211 > > Stop pointing me at archives. I'm not reading links during an email > discussion. It's bad enough the mass of words that you include in > your replies to work out what you're saying. > > And actually now, I'm completely lost over exactly what provides what > with your idea. > > Could you please put together a _complete_ example of how you see my > board examples #1, #2 and #3 working, covering your _entire_ idea in > one _single_ _concise_ email with no references elsewhere, covering > in each case: > > - how a peripheral device driver obtains, is allocated, or is provided with > this 'capability' mask. > - how a DMA engine driver is told which 'capability' masks from peripheral > drivers it is to match. > - how that is translated to a DMA device channels. > - how that translates to DMA request signals attached directly to the DMA > device. > - how that translates to DMA request signals attached to some kind of MUX > which in turn is attached to a DMA request signal attached to the DMA > device. > > Better still, do it in pseudo-C code, or real C code if you think that'll > help (there's nothing like seeing the actual code.) > > You have for reference: > 1. The AMBA drivers in the kernel tree (MMCI, PL011 UART). > drivers/tty/serial/amba-pl011.c > drivers/mmc/host/mmci.c > 2. The DMA engine code for PL080 in the kernel tree. > drivers/dma/amba-pl08x.c > 3. Linus' example code for the Versatile/Realview platforms. > (attached to his email.) > > This is enough to cover the cases I outlined in boards #1,#2,#3. > > To tie this down further, into real hardware, so lets say: > board #1: is Versatile PB926 with an on-board UART0 - so DMA controller > request signal #14 for receive and DMA controller request signal > #15 for transmit. > > board #2: is Realview EB with an on-board UART1 - so DMA controller > request signal #12 (RX) and #13 (TX). > > board #3: is Versatile PB926 with the FPGA-implemented MMCI1 - so > DMA controller request signals #0 to #2 inclusive may be used, > via three separate MUXes (one per request signal) requiring > the selected mux to be programmed with value '5'. This same > channel can be used for either DMA-to-device or DMA-from-device, > but the MMCI device driver may request two separate 'dma channels' > if they are available. > > To ensure all cases are covered, please assume that the AACI > is also using DMA continuously for a long time in this case, > which may be using any of #0 to #2 via the mux, and so how > the AACI's in-use DMA device request signal is avoided. > Would love to. But only after Linaro Connect of 1 week.. and then out of time not officially assigned to it. So it might be soon or late. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |