[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJe_ZhdTnRSzfRvnAaCy1M-LpAk0FqjNSXRLnQW2ksOS77A+=w@mail.gmail.com>
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/
Powered by blists - more mailing lists