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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1315976837.26251.473.camel@vkoul-udesk3>
Date:	Wed, 14 Sep 2011 10:37:17 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	Barry Song <21cnbao@...il.com>, "arnd@...db.de" <arnd@...db.de>,
	"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 Mon, 2011-09-12 at 12:03 +0530, Jassi Brar wrote:
> 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.
I would agree that it makes sense to have it in API rather than config.


-- 
~Vinod

--
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/