From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: pl330: Set residue in tx_status callback
Date: Mon, 8 Dec 2014 18:37:27 +0530 [thread overview]
Message-ID: <20141208130727.GK16827@intel.com> (raw)
In-Reply-To: <CAJe_ZhfDsfehCXHB6pCuQ6672kXBYFxh687cZT1qaSCOyLy76g@mail.gmail.com>
On Sat, Dec 06, 2014 at 12:31:01PM +0530, Jassi Brar wrote:
> It does, though, create an "awkward situation" when a channel is
> active while new requests are submitted - why would the channel want
> to stop after current transfer and await fresh issue_pending()? It's
> not that the request can be modified after submission.
>
> And it isn't that tx_submit() is meant for 'sleepable' preparation for
> the transfer and we need another call to be issued from atomic
> context. From what I see most drivers don't need to sleep in
> tx_submit(). In fact, from a quick look most clients seem to suffer
> from the ritual i.e, there's nothing between tx_submit() and
> issue_pending() calls. And when there is indeed some code, it seems
> that can be moved just before tx_submit().
>
> Last and apparently the least of all, we can never enforce the same
> behavior of the api on Async dma and have uniform behavior over the
> api.
>
> So, if all tx_submit() does is put the request in controller driver's
> internal queue and the client can't touch the request after
> tx_submit(), why not merge the tx_submit() and issue_pending()?
You are thinking from an API point and not what can be done with this API.
Today this API allows you to collate all pending txn and start while
dmaengine driver can collate and submit as a batch to hardware and not waste
time in getting irq and then setting next one. Sadly none of the drivers use
this feature...
I actually like the split model, you can also prepare txn ahead of time and
submit them when needed. If you don't like this, then please do as most
implementation do today, call prepare and submit in series. Flexiblity in
API is a better option IMO
Thanks
--
~Vinod
next prev parent reply other threads:[~2014-12-08 13:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 9:44 [PATCH] dmaengine: pl330: Set residue in tx_status callback Padmavathi Venna
2014-12-02 5:38 ` Padma Venkat
2014-12-02 17:25 ` Lars-Peter Clausen
2014-12-03 4:47 ` Padma Venkat
2014-12-03 7:51 ` Jassi Brar
2014-12-05 15:15 ` Vinod Koul
2014-12-05 15:18 ` Russell King - ARM Linux
2014-12-06 7:01 ` Jassi Brar
2014-12-08 13:07 ` Vinod Koul [this message]
2014-12-08 14:23 ` Russell King - ARM Linux
2014-12-09 6:10 ` Vinod Koul
2014-12-09 15:18 ` Jassi Brar
2014-12-11 4:47 ` Vinod Koul
2014-12-11 6:12 ` Jassi Brar
2015-03-12 8:47 ` Jassi Brar
2014-12-04 20:15 ` Lars-Peter Clausen
2014-12-05 15:10 ` Vinod Koul
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=20141208130727.GK16827@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).