linux-kernel - Re: [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 12 Sep 2011 12:03:01 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Vinod Koul <vkoul@...radead.org>
Cc:	Barry Song <21cnbao@...il.com>, "arnd@...db.de" <arnd@...db.de>,
	vinod.koul@...el.com,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	Jassi Brar <jassisinghbrar@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"workgroup.linux@....com" <workgroup.linux@....com>,
	"rongjun.ying@....com" <rongjun.ying@....com>,
	"Baohua.Song@....com" <Baohua.Song@....com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver

On 11 September 2011 21:32, Vinod Koul <vkoul@...radead.org> wrote:
> On Fri, 2011-09-09 at 16:18 +0800, Barry Song wrote:

>> Jassi prefer to use a transfer type instead of a control command.
>> though we will not really change the interleaved setting for every
>> transfer(it is more possible for one device, we will not change the
>> xlen/ylen/dma_width setting in the whole life period), i do believe
>> the transfer type is enough flexible for my possible applications to
>> change xlen, ylen and dma_width in different transfers.

> Is this usually the assumption or yours is a special case, how about
> your's Jassi?

1) Having type per transfer is more flexible than having to set the type
     for a channel using a control command. The overhead is negligible
     because the client reuses the same descriptors with only changed
     source/destination addresses.
2) DMA_SLAVE_CONFIG is meant for slave (Mem<->Dev) channels,
    whereas it is very likely(for multimedia drives) to have such operations
    Mem->Mem as well.
3) Someday if people realize we can fold many, if not all, transfer types into
    one, this api has the potential to be the survivor.

That was where my mind was grazing when I chose to do what I did.
--
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/