linux-kernel - Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 30 Jul 2011 18:39:13 +0530
From:	Jaswinder Singh <jaswinder.singh@...aro.org>
To:	Russell King <rmk@....linux.org.uk>
Cc:	"Koul, Vinod" <vinod.koul@...el.com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, linus.walleij@...ricsson.com,
	per.friden@...ricsson.com, wei.zhang@...escale.com,
	ebony.zhu@...escale.com, iws@...o.caltech.edu,
	s.hauer@...gutronix.de, maciej.sosnowski@...el.com,
	saeed@...vell.com, shawn.guo@...escale.com, yur@...raft.com,
	agust@...x.de, iwamatsu.nobuhiro@...esas.com,
	per.forlin@...ricsson.com, jonas.aberg@...ricsson.com,
	anemo@....ocn.ne.jp
Subject: Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id

On 29 July 2011 04:10, Russell King <rmk@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/