linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
Date: Tue, 24 Apr 2018 09:25:49 +0530	[thread overview]
Message-ID: <20180424035548.GA6014@localhost> (raw)
In-Reply-To: <8c7a5ac8-0747-9dad-f6e5-74890b64f618@ti.com>

On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote:
> 
> On 2018-04-18 16:06, Lars-Peter Clausen wrote:
> >> Hrm, true, but it is hardly the metadata use case. It is more like
> >> different DMA transfer type.
> > 
> > When I look at this with my astronaut architect view from high high up above
> > I do not see a difference between metadata and multi-planar data.
> 
> I tend to disagree.

and we will love to hear more :)

> > Both split the data that is sent to the peripheral into multiple
> > sub-streams, each carrying part of the data. I'm sure there are peripherals
> > that interleave data and metadata on the same data stream. Similar to how we
> > have left and right channel interleaved in a audio stream.
> 
> Slimbus, S/PDIF?
> 
> > What about metadata that is not contiguous and split into multiple segments.
> > How do you handle passing a sgl to the metadata interface? And then it
> > suddenly looks quite similar to the normal DMA descriptor interface.
> 
> Well, the metadata is for the descriptor. The descriptor describe the
> data transfer _and_ can convey additional information. Nothing is
> interleaved, the data and the descriptor are different things. It is
> more like TCP headers detached from the data (but pointing to it).
> 
> > But maybe that's just one abstraction level to high.
> 
> I understand your point, but at the end the metadata needs to end up in
> the descriptor which is describing the data that is going to be moved.
> 
> The descriptor is not sent as a separate DMA trasnfer, it is part of the
> DMA transfer, it is handled internally by the DMA.

That is bit confusing to me. I thought DMA was transparent to meta data and
would blindly collect and transfer along with the descriptor. So at high
level we are talking about two transfers (probably co-joined at hip and you
want to call one transfer) but why can't we visualize this as just a DMA
transfers. maybe you want to signal/attach to transfer, cant we do that with
additional flag DMA_METADATA etc..?

-- 
~Vinod

  reply	other threads:[~2018-04-24  3:55 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-02 10:39 [RFC 0/6] Xilinx DMA enhancements and optimization 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-11  9:05   ` Vinod Koul
2018-04-17 10:54     ` 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-11  9:08   ` Vinod Koul
2018-04-17 11:43     ` Radhey Shyam Pandey
2018-04-17 12:54       ` Lars-Peter Clausen
2018-04-17 13:46         ` Peter Ujfalusi
2018-04-17 13:58           ` Lars-Peter Clausen
2018-04-17 14:53             ` Peter Ujfalusi
2018-04-17 15:54               ` Lars-Peter Clausen
2018-04-18  6:31                 ` Peter Ujfalusi
2018-04-18 13:06                   ` Lars-Peter Clausen
2018-04-19 11:40                     ` Peter Ujfalusi
2018-04-24  3:55                       ` Vinod Koul [this message]
2018-04-24  9:50                         ` Peter Ujfalusi
2018-05-17  6:39                           ` Radhey Shyam Pandey
2018-05-29 15:04                             ` Peter Ujfalusi
2018-05-30 17:29                               ` Radhey Shyam Pandey
2018-06-01 10:17                                 ` Peter Ujfalusi
2018-06-01 10:24                                   ` [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor Peter Ujfalusi
2018-07-02  6:59                                     ` Radhey Shyam Pandey
2018-07-10  5:52                                     ` Vinod
2018-07-18 10:06                                       ` Peter Ujfalusi
2018-07-19  9:22                                         ` Vinod
2018-07-20 13:42                                           ` Peter Ujfalusi
2018-07-24 11:14                                             ` Vinod
2018-07-30  9:46                                               ` Peter Ujfalusi
2018-07-31  4:29                                                 ` Vinod
2018-04-17 15:42           ` [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Vinod Koul
2018-04-17 15:44             ` Lars-Peter Clausen
2018-04-18  6:39             ` Peter Ujfalusi
2018-04-18  7:03               ` Peter Ujfalusi
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 4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Radhey Shyam Pandey
2018-04-11  9:11   ` Vinod Koul
2018-04-17 12:28     ` Radhey Shyam Pandey
2018-04-23  5:23       ` Vinod Koul
2018-04-02 10:39 ` [RFC 5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Radhey Shyam Pandey
2018-04-11  9:11   ` Vinod Koul
2018-04-17 12:48     ` Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 6/6] dmaengine: xilinx_dma: Use tasklet_hi_schedule for timing critical usecase 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=20180424035548.GA6014@localhost \
    --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).