From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client From: Vinod Koul Message-Id: <20180424035548.GA6014@localhost> Date: Tue, 24 Apr 2018 09:25:49 +0530 To: Peter Ujfalusi Cc: Lars-Peter Clausen , Radhey Shyam Pandey , "michal.simek@xilinx.com" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , "dan.j.williams@intel.com" , Appana Durga Kedareswara Rao , "linux-arm-kernel@lists.infradead.org" List-ID: T24gVGh1LCBBcHIgMTksIDIwMTggYXQgMDI6NDA6MjZQTSArMDMwMCwgUGV0ZXIgVWpmYWx1c2kg d3JvdGU6Cj4gCj4gT24gMjAxOC0wNC0xOCAxNjowNiwgTGFycy1QZXRlciBDbGF1c2VuIHdyb3Rl Ogo+ID4+IEhybSwgdHJ1ZSwgYnV0IGl0IGlzIGhhcmRseSB0aGUgbWV0YWRhdGEgdXNlIGNhc2Uu IEl0IGlzIG1vcmUgbGlrZQo+ID4+IGRpZmZlcmVudCBETUEgdHJhbnNmZXIgdHlwZS4KPiA+IAo+ ID4gV2hlbiBJIGxvb2sgYXQgdGhpcyB3aXRoIG15IGFzdHJvbmF1dCBhcmNoaXRlY3QgdmlldyBm cm9tIGhpZ2ggaGlnaCB1cCBhYm92ZQo+ID4gSSBkbyBub3Qgc2VlIGEgZGlmZmVyZW5jZSBiZXR3 ZWVuIG1ldGFkYXRhIGFuZCBtdWx0aS1wbGFuYXIgZGF0YS4KPiAKPiBJIHRlbmQgdG8gZGlzYWdy ZWUuCgphbmQgd2Ugd2lsbCBsb3ZlIHRvIGhlYXIgbW9yZSA6KQoKPiA+IEJvdGggc3BsaXQgdGhl IGRhdGEgdGhhdCBpcyBzZW50IHRvIHRoZSBwZXJpcGhlcmFsIGludG8gbXVsdGlwbGUKPiA+IHN1 Yi1zdHJlYW1zLCBlYWNoIGNhcnJ5aW5nIHBhcnQgb2YgdGhlIGRhdGEuIEknbSBzdXJlIHRoZXJl IGFyZSBwZXJpcGhlcmFscwo+ID4gdGhhdCBpbnRlcmxlYXZlIGRhdGEgYW5kIG1ldGFkYXRhIG9u IHRoZSBzYW1lIGRhdGEgc3RyZWFtLiBTaW1pbGFyIHRvIGhvdyB3ZQo+ID4gaGF2ZSBsZWZ0IGFu ZCByaWdodCBjaGFubmVsIGludGVybGVhdmVkIGluIGEgYXVkaW8gc3RyZWFtLgo+IAo+IFNsaW1i dXMsIFMvUERJRj8KPiAKPiA+IFdoYXQgYWJvdXQgbWV0YWRhdGEgdGhhdCBpcyBub3QgY29udGln dW91cyBhbmQgc3BsaXQgaW50byBtdWx0aXBsZSBzZWdtZW50cy4KPiA+IEhvdyBkbyB5b3UgaGFu ZGxlIHBhc3NpbmcgYSBzZ2wgdG8gdGhlIG1ldGFkYXRhIGludGVyZmFjZT8gQW5kIHRoZW4gaXQK PiA+IHN1ZGRlbmx5IGxvb2tzIHF1aXRlIHNpbWlsYXIgdG8gdGhlIG5vcm1hbCBETUEgZGVzY3Jp cHRvciBpbnRlcmZhY2UuCj4gCj4gV2VsbCwgdGhlIG1ldGFkYXRhIGlzIGZvciB0aGUgZGVzY3Jp cHRvci4gVGhlIGRlc2NyaXB0b3IgZGVzY3JpYmUgdGhlCj4gZGF0YSB0cmFuc2ZlciBfYW5kXyBj YW4gY29udmV5IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uIE5vdGhpbmcgaXMKPiBpbnRlcmxlYXZl ZCwgdGhlIGRhdGEgYW5kIHRoZSBkZXNjcmlwdG9yIGFyZSBkaWZmZXJlbnQgdGhpbmdzLiBJdCBp cwo+IG1vcmUgbGlrZSBUQ1AgaGVhZGVycyBkZXRhY2hlZCBmcm9tIHRoZSBkYXRhIChidXQgcG9p bnRpbmcgdG8gaXQpLgo+IAo+ID4gQnV0IG1heWJlIHRoYXQncyBqdXN0IG9uZSBhYnN0cmFjdGlv biBsZXZlbCB0byBoaWdoLgo+IAo+IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LCBidXQgYXQgdGhl IGVuZCB0aGUgbWV0YWRhdGEgbmVlZHMgdG8gZW5kIHVwIGluCj4gdGhlIGRlc2NyaXB0b3Igd2hp Y2ggaXMgZGVzY3JpYmluZyB0aGUgZGF0YSB0aGF0IGlzIGdvaW5nIHRvIGJlIG1vdmVkLgo+IAo+ IFRoZSBkZXNjcmlwdG9yIGlzIG5vdCBzZW50IGFzIGEgc2VwYXJhdGUgRE1BIHRyYXNuZmVyLCBp dCBpcyBwYXJ0IG9mIHRoZQo+IERNQSB0cmFuc2ZlciwgaXQgaXMgaGFuZGxlZCBpbnRlcm5hbGx5 IGJ5IHRoZSBETUEuCgpUaGF0IGlzIGJpdCBjb25mdXNpbmcgdG8gbWUuIEkgdGhvdWdodCBETUEg d2FzIHRyYW5zcGFyZW50IHRvIG1ldGEgZGF0YSBhbmQKd291bGQgYmxpbmRseSBjb2xsZWN0IGFu ZCB0cmFuc2ZlciBhbG9uZyB3aXRoIHRoZSBkZXNjcmlwdG9yLiBTbyBhdCBoaWdoCmxldmVsIHdl IGFyZSB0YWxraW5nIGFib3V0IHR3byB0cmFuc2ZlcnMgKHByb2JhYmx5IGNvLWpvaW5lZCBhdCBo aXAgYW5kIHlvdQp3YW50IHRvIGNhbGwgb25lIHRyYW5zZmVyKSBidXQgd2h5IGNhbid0IHdlIHZp c3VhbGl6ZSB0aGlzIGFzIGp1c3QgYSBETUEKdHJhbnNmZXJzLiBtYXliZSB5b3Ugd2FudCB0byBz aWduYWwvYXR0YWNoIHRvIHRyYW5zZmVyLCBjYW50IHdlIGRvIHRoYXQgd2l0aAphZGRpdGlvbmFs IGZsYWcgRE1BX01FVEFEQVRBIGV0Yy4uPwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932834AbeDXDvO (ORCPT ); Mon, 23 Apr 2018 23:51:14 -0400 Received: from mga02.intel.com ([134.134.136.20]:6409 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932729AbeDXDvM (ORCPT ); Mon, 23 Apr 2018 23:51:12 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,321,1520924400"; d="scan'208";a="53133611" Date: Tue, 24 Apr 2018 09:25:49 +0530 From: Vinod Koul To: Peter Ujfalusi Cc: Lars-Peter Clausen , Radhey Shyam Pandey , "michal.simek@xilinx.com" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , "dan.j.williams@intel.com" , Appana Durga Kedareswara Rao , "linux-arm-kernel@lists.infradead.org" Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Message-ID: <20180424035548.GA6014@localhost> References: <20180411090854.GY6014@localhost> <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> <4ba085c7-5256-6c8a-5697-c0d5736a6e46@ti.com> <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> <78828d31-e4cd-5211-f1b6-8918ac38f599@ti.com> <8c7a5ac8-0747-9dad-f6e5-74890b64f618@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8c7a5ac8-0747-9dad-f6e5-74890b64f618@ti.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: vinod.koul@intel.com (Vinod Koul) Date: Tue, 24 Apr 2018 09:25:49 +0530 Subject: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client In-Reply-To: <8c7a5ac8-0747-9dad-f6e5-74890b64f618@ti.com> References: <20180411090854.GY6014@localhost> <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> <4ba085c7-5256-6c8a-5697-c0d5736a6e46@ti.com> <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> <78828d31-e4cd-5211-f1b6-8918ac38f599@ti.com> <8c7a5ac8-0747-9dad-f6e5-74890b64f618@ti.com> Message-ID: <20180424035548.GA6014@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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