DMA Engine development
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: radheys@xilinx.com, vinod.koul@intel.com, lars@metafoo.de,
	michal.simek@xilinx.com, linux-kernel@vger.kernel.org,
	dmaengine@vger.kernel.org, dan.j.williams@intel.com,
	appanad@xilinx.com, linux-arm-kernel@lists.infradead.org
Subject: [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor
Date: Tue, 31 Jul 2018 09:59:03 +0530	[thread overview]
Message-ID: <20180731042903.GC16775@vkoul-mobl> (raw)

On 30-07-18, 12:46, Peter Ujfalusi wrote:
> Vinod,
> 
> On 2018-07-24 14:14, Vinod wrote:
> >>>> Clients must not mix the two way of handling the metadata.
> >>>> The set_len() is intended to tell the DMA driver the client provided
> >>>> metadata size (in MEM_TO_DEV case mostly).
> >>>>
> >>>> MEM_TO_DEV flow on client side:
> >>>> get_ptr()
> >>>> fill in the metadata to the pointer (not exceeding max_len)
> >>>> set_len() to tell the DMA driver the amount of valid bytes written
> >>>>
> >>>> DEV_TO_MEM flow on client side:
> >>>> In the completion callback, get_ptr()
> >>>> the metadata is payload_len bytes and can be accessed in the return pointer.
> >>>
> >>> I would think to unify this..
> >>
> >> I have tried it, but the attach mode and the pointer mode is hard to
> >> handle with a generic API.
> >> I will try to find a way to unify things in a sane way.
> > 
> > Hmmm, looking from the description they will be for different methods,
> > so lets make them orthogonal and not allow driver to register both.
> 
> I would allow DMA drivers to register both, but somehow enforce that
> clients are not mixing the two distinct way of dealing with the metadata.
> 
> The reason for that is for example the attach mode is the simplest (I
> implemented it first and I have a client using it), but if the pointer
> mode is found to be more efficient and feasible for the DMA then the DMA
> driver can implement that mode and the client can move as well w/o
> breaking anything.

Sounds reasonable...

             reply	other threads:[~2018-07-31  4:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31  4:29 Vinod Koul [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-07-30  9:46 [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor Peter Ujfalusi
2018-07-24 11:14 Vinod Koul
2018-07-20 13:42 Peter Ujfalusi
2018-07-19  9:22 Vinod Koul
2018-07-18 10:06 Peter Ujfalusi
2018-07-10  5:52 Vinod Koul
2018-07-02  6:59 Radhey Shyam Pandey
2018-06-01 10:24 Peter Ujfalusi

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=20180731042903.GC16775@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=appanad@xilinx.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=radheys@xilinx.com \
    --cc=vinod.koul@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