From: Vinod Koul <vinod.koul@intel.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Radhey Shyam Pandey <radheys@xilinx.com>,
"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
Appana Durga Kedareswara Rao <appanad@xilinx.com>,
"linux-arm-kernel@lists.infradead.org"
<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)
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..?
next reply other threads:[~2018-04-24 3:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 3:55 Vinod Koul [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-06-01 10:17 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Peter Ujfalusi
2018-05-30 17:29 Radhey Shyam Pandey
2018-05-29 15:04 Peter Ujfalusi
2018-05-17 6:39 Radhey Shyam Pandey
2018-04-24 9:50 Peter Ujfalusi
2018-04-19 11:40 Peter Ujfalusi
2018-04-18 13:06 Lars-Peter Clausen
2018-04-18 7:03 Peter Ujfalusi
2018-04-18 6:39 Peter Ujfalusi
2018-04-18 6:31 Peter Ujfalusi
2018-04-17 15:54 Lars-Peter Clausen
2018-04-17 15:44 Lars-Peter Clausen
2018-04-17 15:42 Vinod Koul
2018-04-17 14:53 Peter Ujfalusi
2018-04-17 13:58 Lars-Peter Clausen
2018-04-17 13:46 Peter Ujfalusi
2018-04-17 12:54 Lars-Peter Clausen
2018-04-17 11:43 Radhey Shyam Pandey
2018-04-11 9:08 Vinod Koul
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=20180424035548.GA6014@localhost \
--to=vinod.koul@intel.com \
--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 \
/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).