linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: sirf: add dmaengine_prep_slave_single/sg support
Date: Tue, 3 Sep 2013 17:38:38 +0530	[thread overview]
Message-ID: <20130903120838.GG15824@intel.com> (raw)
In-Reply-To: <CAJe_Zhfo0502tvd-0Rt-0kEKn+Z_S-B+JSAVd4=UNpneQ5GSvw@mail.gmail.com>

On Tue, Sep 03, 2013 at 05:25:40PM +0530, Jassi Brar wrote:
> > for example, if someone wants to do a 16Kbytes single transfer. how
> > will interleaved dma set transfer length and interval between every
> > row?
> > if it sets the transfer length to 16KB directly, the dma hardware
> > might not support such long a transfer at all.
> > so it might want to set as two 8KB transfer without interval between them.
> > 0~8KB                empty interval
> > 8KB-16KB          empty interval
> > or four 4KB transfer as
> > 0~4KB                empty interval
> > 4KB-8KB          empty interval
> > 8KB-12KB          empty interval
> > 12KB-16KB          empty interval
> >
> > the problem is we don't know the hardware limitation of every dma
> > controllers for transferring length of each row.
> >
> A client is only interested in transferring the total amount data and
> if/when it wants notified. How the dma controller divides the big
> transfer, shouldn't matter to the client. In fact it would be bad for
> a client to care about the working of a dma controller.
> IOW, the 16KB transfer could be divided into 4 parts by the dmac that
> supports max 4KB transfers, into 8 parts if max is 2KB and so on...
> the client shouldn't care.
That is also a correct approach. I agree that dma driver should be able to
handle any lengths and split that to multiple descriptors. 

But I think in interleaved API, clients should know the capablity otherwise dma
driver will have redo the whole list again...

~Vinod
-- 

  reply	other threads:[~2013-09-03 12:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-25 12:57 [PATCH] dmaengine: sirf: add dmaengine_prep_slave_single/sg support Barry Song
2013-08-26  8:56 ` Vinod Koul
2013-09-01 13:02   ` Barry Song
2013-09-02  6:25     ` Vinod Koul
2013-09-03 10:06       ` Barry Song
2013-09-03 11:39         ` Vinod Koul
2013-09-03 12:42           ` Barry Song
2013-09-03 12:12             ` Vinod Koul
2013-09-03 11:55         ` Jassi Brar
2013-09-03 12:08           ` Vinod Koul [this message]
2013-09-03 13:15             ` Jassi Brar
2013-09-03 12:38           ` Barry Song
2013-09-03 12:54             ` Jassi Brar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130903120838.GG15824@intel.com \
    --to=vinod.koul@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).