lkml.org 
[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id
From
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/

\
 
 \ /
  Last update: 2011-07-30 15:11    [W:0.115 / U:1.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site