dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Dave Jiang <dave.jiang@intel.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	dmaengine@vger.kernel.org, swathi.kovvuri@intel.com
Subject: Re: [PATCH v4] dmaengine: cookie bypass for out of order completion
Date: Tue, 19 May 2020 22:29:59 +0530	[thread overview]
Message-ID: <20200519165959.GR374218@vkoul-mobl.Dlink> (raw)
In-Reply-To: <4e17fbe4-62cc-d596-f15c-5d3a7105cdcb@intel.com>

On 15-05-20, 09:21, Dave Jiang wrote:
> 
> 
> On 5/14/2020 11:48 PM, Vinod Koul wrote:
> > On 13-05-20, 09:35, Dave Jiang wrote:
> > > 
> > > 
> > > On 5/13/2020 12:30 AM, Peter Ujfalusi wrote:
> > > > 
> > > > 
> > > > On 12/05/2020 2.47, Dave Jiang wrote:
> > > > > The cookie tracking in dmaengine expects all submissions completed in
> > > > > order. Some DMA devices like Intel DSA can complete submissions out of
> > > > > order, especially if configured with a work queue sharing multiple DMA
> > > > > engines. Add a status DMA_OUT_OF_ORDER that tx_status can be returned for
> > > > > those DMA devices. The user should use callbacks to track the completion
> > > > > rather than the DMA cookie. This would address the issue of dmatest
> > > > > complaining that descriptors are "busy" when the cookie count goes
> > > > > backwards due to out of order completion. Add DMA_COMPLETION_NO_ORDER
> > > > > DMA capability to allow the driver to flag the device's ability to complete
> > > > > operations out of order.
> > > > 
> > > > I'm still a bit hesitant around this.
> > > > If the DMA only support out of order completion then it is mandatory
> > > > that each descriptor must have unique callback parameter in order the
> > > > client could know which transfer has been completed.
> > 
> > Maybe we can still use the cookie to indicate that, or leave it to users
> > to manage? They can add an id in the callback params?
> > 
> > Using former is easy, but still user needs to keep track... later can be
> > possibly more suited here?
> > 
> 
> Is there anything else I need to do with this patch?

Not really atm, but i am going to defer this after merge window.

-- 
~Vinod

  reply	other threads:[~2020-05-19 17:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 23:47 [PATCH v4] dmaengine: cookie bypass for out of order completion Dave Jiang
2020-05-13  7:30 ` Peter Ujfalusi
2020-05-13 16:35   ` Dave Jiang
2020-05-15  6:48     ` Vinod Koul
2020-05-15 16:21       ` Dave Jiang
2020-05-19 16:59         ` Vinod Koul [this message]
2020-05-19 17:02           ` Dave Jiang

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=20200519165959.GR374218@vkoul-mobl.Dlink \
    --to=vkoul@kernel.org \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=swathi.kovvuri@intel.com \
    /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).