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
--
next prev parent 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).