All of lore.kernel.org
 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...

WARNING: multiple messages have this Message-ID (diff)
From: Vinod <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: Re: [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)
In-Reply-To: <e5112c28-a010-827b-c1fd-ecf00036412a@ti.com>

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...

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: vkoul@kernel.org (Vinod)
To: 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)
In-Reply-To: <e5112c28-a010-827b-c1fd-ecf00036412a@ti.com>

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...

-- 
~Vinod

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

Thread overview: 128+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31  4:29 Vinod Koul [this message]
2018-07-31  4:29 ` [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor Vinod
2018-07-31  4:29 ` Vinod
  -- strict thread matches above, loose matches on Subject: below --
2018-07-30  9:46 Peter Ujfalusi
2018-07-30  9:46 ` Peter Ujfalusi
2018-07-30  9:46 ` Peter Ujfalusi
2018-07-24 11:14 Vinod Koul
2018-07-24 11:14 ` Vinod
2018-07-24 11:14 ` Vinod
2018-07-20 13:42 Peter Ujfalusi
2018-07-20 13:42 ` Peter Ujfalusi
2018-07-20 13:42 ` Peter Ujfalusi
2018-07-19  9:22 Vinod Koul
2018-07-19  9:22 ` Vinod
2018-07-19  9:22 ` Vinod
2018-07-18 10:06 Peter Ujfalusi
2018-07-18 10:06 ` Peter Ujfalusi
2018-07-18 10:06 ` Peter Ujfalusi
2018-07-10  5:52 Vinod Koul
2018-07-10  5:52 ` Vinod
2018-07-10  5:52 ` Vinod
2018-07-02  6:59 Radhey Shyam Pandey
2018-07-02  6:59 ` Radhey Shyam Pandey
2018-07-02  6:59 ` Radhey Shyam Pandey
2018-06-01 10:24 Peter Ujfalusi
2018-06-01 10:24 ` Peter Ujfalusi
2018-06-01 10:24 ` Peter Ujfalusi
2018-06-01 10:17 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Peter Ujfalusi
2018-06-01 10:17 ` [RFC 2/6] " Peter Ujfalusi
2018-06-01 10:17 ` Peter Ujfalusi
2018-05-30 17:29 [RFC,2/6] " Radhey Shyam Pandey
2018-05-30 17:29 ` [RFC 2/6] " Radhey Shyam Pandey
2018-05-30 17:29 ` Radhey Shyam Pandey
2018-05-29 15:04 [RFC,2/6] " Peter Ujfalusi
2018-05-29 15:04 ` [RFC 2/6] " Peter Ujfalusi
2018-05-29 15:04 ` Peter Ujfalusi
2018-05-17  6:39 [RFC,2/6] " Radhey Shyam Pandey
2018-05-17  6:39 ` [RFC 2/6] " Radhey Shyam Pandey
2018-05-17  6:39 ` Radhey Shyam Pandey
2018-04-24  9:50 [RFC,2/6] " Peter Ujfalusi
2018-04-24  9:50 ` [RFC 2/6] " Peter Ujfalusi
2018-04-24  9:50 ` Peter Ujfalusi
2018-04-24  3:55 [RFC,2/6] " Vinod Koul
2018-04-24  3:55 ` [RFC 2/6] " Vinod Koul
2018-04-24  3:55 ` Vinod Koul
2018-04-23  5:23 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Vinod Koul
2018-04-23  5:23 ` [RFC 4/6] " Vinod Koul
2018-04-23  5:23 ` Vinod Koul
2018-04-19 11:40 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Peter Ujfalusi
2018-04-19 11:40 ` [RFC 2/6] " Peter Ujfalusi
2018-04-19 11:40 ` Peter Ujfalusi
2018-04-18 13:06 [RFC,2/6] " Lars-Peter Clausen
2018-04-18 13:06 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-18 13:06 ` Lars-Peter Clausen
2018-04-18  7:03 [RFC,2/6] " Peter Ujfalusi
2018-04-18  7:03 ` [RFC 2/6] " Peter Ujfalusi
2018-04-18  7:03 ` Peter Ujfalusi
2018-04-18  6:39 [RFC,2/6] " Peter Ujfalusi
2018-04-18  6:39 ` [RFC 2/6] " Peter Ujfalusi
2018-04-18  6:39 ` Peter Ujfalusi
2018-04-18  6:31 [RFC,2/6] " Peter Ujfalusi
2018-04-18  6:31 ` [RFC 2/6] " Peter Ujfalusi
2018-04-18  6:31 ` Peter Ujfalusi
2018-04-17 15:54 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 15:54 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 15:54 ` Lars-Peter Clausen
2018-04-17 15:44 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 15:44 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 15:44 ` Lars-Peter Clausen
2018-04-17 15:42 [RFC,2/6] " Vinod Koul
2018-04-17 15:42 ` [RFC 2/6] " Vinod Koul
2018-04-17 15:42 ` Vinod Koul
2018-04-17 14:53 [RFC,2/6] " Peter Ujfalusi
2018-04-17 14:53 ` [RFC 2/6] " Peter Ujfalusi
2018-04-17 14:53 ` Peter Ujfalusi
2018-04-17 13:58 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 13:58 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 13:58 ` Lars-Peter Clausen
2018-04-17 13:46 [RFC,2/6] " Peter Ujfalusi
2018-04-17 13:46 ` [RFC 2/6] " Peter Ujfalusi
2018-04-17 13:46 ` Peter Ujfalusi
2018-04-17 12:54 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 12:54 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 12:54 ` Lars-Peter Clausen
2018-04-17 12:48 [RFC,5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Radhey Shyam Pandey
2018-04-17 12:48 ` [RFC 5/6] " Radhey Shyam Pandey
2018-04-17 12:48 ` Radhey Shyam Pandey
2018-04-17 12:28 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Radhey Shyam Pandey
2018-04-17 12:28 ` [RFC 4/6] " Radhey Shyam Pandey
2018-04-17 12:28 ` Radhey Shyam Pandey
2018-04-17 11:43 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Radhey Shyam Pandey
2018-04-17 11:43 ` [RFC 2/6] " Radhey Shyam Pandey
2018-04-17 11:43 ` Radhey Shyam Pandey
2018-04-17 10:54 [RFC,1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected Radhey Shyam Pandey
2018-04-17 10:54 ` [RFC 1/6] " Radhey Shyam Pandey
2018-04-17 10:54 ` Radhey Shyam Pandey
2018-04-11  9:11 [RFC,5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Vinod Koul
2018-04-11  9:11 ` [RFC 5/6] " Vinod Koul
2018-04-11  9:11 ` Vinod Koul
2018-04-11  9:11 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Vinod Koul
2018-04-11  9:11 ` [RFC 4/6] " Vinod Koul
2018-04-11  9:11 ` Vinod Koul
2018-04-11  9:08 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Vinod Koul
2018-04-11  9:08 ` [RFC 2/6] " Vinod Koul
2018-04-11  9:08 ` Vinod Koul
2018-04-11  9:05 [RFC,1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected Vinod Koul
2018-04-11  9:05 ` [RFC 1/6] " Vinod Koul
2018-04-11  9:05 ` Vinod Koul
2018-04-02 10:39 [RFC,6/6] dmaengine: xilinx_dma: Use tasklet_hi_schedule for timing critical usecase Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 6/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 5/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 4/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,3/6] dmaengine: xilinx_dma: Increase AXI DMA transaction segment count Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 3/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 2/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 1/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC 0/6] Xilinx DMA enhancements and optimization Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.