Messages in this thread | | | Date | Sat, 30 Jul 2011 18:39:13 +0530 | Subject | Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id | From | Jaswinder Singh <> |
| |
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 Assuming you have read that, I write hence ...
A solution to Board-3 would work for Board-1,2 as well. Rather this is how every dmac driver should be written, imho.
For a dmac driver, allocating a channel should be purely a s/w thing i.e, just as a way for it to see what features the client needs and inform immediately if it is impossible. Successful return of channel must not be taken as a guarantee of any successful transfer by the clients. Nothing esoteric, but important to keep in mind nonetheless.
Since Board-3 has fpga-mux routing req-sigs, probably more number of peripherals could be reached on board-3. Anyways, the dmac driver would get every reachable h/w channel from board via platform and happily allot to clients as if every channel is available all the time.
As a design, your dmac driver should lock as less h/w resources as possible during channel allocation - ideally, zero, and it should be possible when afterall the dmac-driver can't guarantee success of xfers.
//Just before starting the xfers. if (plat->rs_activate) // NULL for board-1 and 2 err = plat->rs_activate(DMACd_RSs) else err = 0;
......do xfers .....
//After xfers-done 'irq' if (plat->rs_deactivate) // NULL for board-1 and 2 plat->rs_deactivate(DMACd_RSs)
Depending upon time taken by rs_activate, you might want to schedule rs_deactivate after sometime rather than calling it immediately.
This also indicates submitting xfers in batches, a good practice for clients.
All of the above is to prove that -- Runtime switching isn't as big a deal as is made out to be. It should be done _transparently_ to the Client drivers. So, shouldn't be a part of the DMAENGINE API.
So basically your setup should work just as fine as any other statically allocated req-signals. i.e, from the DMAENGINE API pov.
Thanks -- 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/
| |