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: Peter Ujfalusi Message-Id: <43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com> Date: Wed, 18 Apr 2018 10:03:45 +0300 To: Vinod Koul Cc: Lars-Peter Clausen , Radhey Shyam Pandey , "linux-kernel@vger.kernel.org" , "michal.simek@xilinx.com" , "dmaengine@vger.kernel.org" , "dan.j.williams@intel.com" , Appana Durga Kedareswara Rao , "linux-arm-kernel@lists.infradead.org" List-ID: T24gMjAxOC0wNC0xOCAwOTozOSwgUGV0ZXIgVWpmYWx1c2kgd3JvdGU6Cj4gCj4gCj4gT24gMjAx OC0wNC0xNyAxODo0MiwgVmlub2QgS291bCB3cm90ZToKPj4gT24gVHVlLCBBcHIgMTcsIDIwMTgg YXQgMDQ6NDY6NDNQTSArMDMwMCwgUGV0ZXIgVWpmYWx1c2kgd3JvdGU6Cj4+Cj4+PiBAQCAtNzA5 LDYgKzcwOSwxMSBAQCBzdHJ1Y3QgZG1hX2ZpbHRlciB7Cj4+PiAgICoJYmUgY2FsbGVkIGFmdGVy IHBlcmlvZF9sZW4gYnl0ZXMgaGF2ZSBiZWVuIHRyYW5zZmVycmVkLgo+Pj4gICAqIEBkZXZpY2Vf cHJlcF9pbnRlcmxlYXZlZF9kbWE6IFRyYW5zZmVyIGV4cHJlc3Npb24gaW4gYSBnZW5lcmljIHdh eS4KPj4+ICAgKiBAZGV2aWNlX3ByZXBfZG1hX2ltbV9kYXRhOiBETUEncyA4IGJ5dGUgaW1tZWRp YXRlIGRhdGEgdG8gdGhlIGRzdCBhZGRyZXNzCj4+PiArICogQGRldmljZV9hdHRhY2hfbWV0YWRh dGE6IFNvbWUgRE1BIGVuZ2luZXMgY2FuIHNlbmQgYW5kIHJlY2VpdmUgc2lkZSBiYW5kCj4+PiAr ICoJaW5mb3JtYXRpb24sIGNvbW1hbmRzIG9yIHBhcmFtZXRlcnMgd2hpY2ggaXMgbm90IHRyYW5z ZmVycmVkIHdpdGhpbiB0aGUKPj4+ICsgKglkYXRhIHN0cmVhbSBpdHNlbGYuIEluIHN1Y2ggY2Fz ZSBjbGllbnRzIGNhbiBzZXQgdGhlIG1ldGFkYXRhIHRvIHRoZQo+Pj4gKyAqCWdpdmVuIGRlc2Ny aXB0b3IgYW5kIGl0IGlzIGdvaW5nIHRvIGJlIHNlbnQgdG8gdGhlIHBlcmlwaGVyYWwsIG9yIGlu Cj4+PiArICoJY2FzZSBvZiBERVZfVE9fTUVNIHRoZSBwcm92aWRlZCBidWZmZXIgd2lsbCByZWNl aXZlIHRoZSBtZXRhZGF0YS4KPj4+ICAgKiBAZGV2aWNlX2NvbmZpZzogUHVzaGVzIGEgbmV3IGNv bmZpZ3VyYXRpb24gdG8gYSBjaGFubmVsLCByZXR1cm4gMCBvciBhbiBlcnJvcgo+Pj4gICAqCWNv ZGUKPj4+ICAgKiBAZGV2aWNlX3BhdXNlOiBQYXVzZXMgYW55IHRyYW5zZmVyIGhhcHBlbmluZyBv biBhIGNoYW5uZWwuIFJldHVybnMKPj4+IEBAIC03OTYsNiArODAxLDkgQEAgc3RydWN0IGRtYV9k ZXZpY2Ugewo+Pj4gIAkJc3RydWN0IGRtYV9jaGFuICpjaGFuLCBkbWFfYWRkcl90IGRzdCwgdTY0 IGRhdGEsCj4+PiAgCQl1bnNpZ25lZCBsb25nIGZsYWdzKTsKPj4+ICAKPj4+ICsJaW50ICgqZGV2 aWNlX2F0dGFjaF9tZXRhZGF0YSkoc3RydWN0IGRtYV9hc3luY190eF9kZXNjcmlwdG9yICpkZXNj LAo+Pj4gKwkJCQkgICAgICB2b2lkICpkYXRhLCBzaXplX3QgbGVuKTsKPj4KPj4gd2hpbGUgaSBh bSBva2F5IHdpdGggdGhlIGNvbmNlcHQsIEkgd291bGQgbm90IHdhbnQgdG8gZ28gYWdhaW4gdGhl IGN1c3RvbQo+PiBwb2ludGVyIHJvdXRlLCB0aGlzIGlzIGEgbm8tZ28gZm9yIG1lLgo+Pgo+PiBJ bnN0ZWFkIGxldHMgYWRkIHRoZSB2ZW5kb3IgZGF0YSwgZGVmaW5lIHRoYXQgZXhwbGljaXRseS4g V2UgY2FuIHVzZSBzdHJ1Y3QsCj4+IHRva2VucyBvciBzb21ldGhpbmcgZWxzZSB0byBkZWZpbmUg dGhlc2UuIEJ1dCBsZXRzIHRyeSB0byBzdGF5IGF3YXkgZnJvbQo+PiBvcGFxdWUgb2JqZWN0cyBw bGVhc2UgOi0pCj4gCj4gVGhlIERNQSBkb2VzIG5vdCBpbnRlcnByZXQgdGhlIG1ldGFkYXRhLCBp dCBpcyBpbmZvcm1hdGlvbiB3aGljaCBjYW4gYmUKPiBvbmx5IHVuZGVyc3Rvb2QgYnkgdGhlIGNs aWVudCBkcml2ZXIgYW5kIHRoZSByZW1vdGUgcGVyaXBoZXJhbC4gSXQgaXMKPiBqdXN0IGNodW5r IG9mIGRhdGEgKHBhcmFtZXRlcnMsIHRpbWVzdGFtcHMsIGtleXMsIGV0YykgdGhhdCBuZWVkcyB0 bwo+IHRyYXZlbCBhbG9uZyB3aXRoIHRoZSBwYXlsb2FkLgo+IAo+IFRoZSBjb250ZW50IGlzIG5v dCByZWxldmFudCBmb3IgdGhlIERNQSBpdHNlbGYuCgpUbyBhZGQ6IGRpZmZlcmVudCBwZXJpcGhl cmFscyBuZWVkcyB0byBzZW5kIHJlY2VpdmUgZGlmZmVyZW50IG1ldGFkYXRhCmFuZCBldmVuIHRo ZSBzYW1lIHBlcmlwaGVyYWwgbWlnaHQgcGFzcyBkaWZmZXJlbnQgaW5mb3JtYXRpb24gYmFzZWQg b24KdGhlaXIgb3BlcmF0aW5nIG1vZGUuIFRoZSBzaXplIG9mIG1ldGFkYXRhIGNhbiBiZSBkaWZm ZXJlbnQgYXMgd2VsbC4KClNvIGl0IGlzIG5vdCByZWFsbHkgdmVuZG9yIHNwZWNpZmljIG1ldGFk YXRhLCBidXQgcGVyaXBoZXJhbCwgb3BlcmF0aW5nCm1vZGUgYW5kIG90aGVyIGZhY3RvcnMgYWZm ZWN0ZWQgY2h1bmsgb2YgZGF0YS4KCj4gCj4gLSBQw6l0ZXIKPiAKPiBUZXhhcyBJbnN0cnVtZW50 cyBGaW5sYW5kIE95LCBQb3Jra2FsYW5rYXR1IDIyLCAwMDE4MCBIZWxzaW5raS4KPiBZLXR1bm51 cy9CdXNpbmVzcyBJRDogMDYxNTUyMS00LiBLb3RpcGFpa2thL0RvbWljaWxlOiBIZWxzaW5raQo+ IAoKLSBQw6l0ZXIKClRleGFzIEluc3RydW1lbnRzIEZpbmxhbmQgT3ksIFBvcmtrYWxhbmthdHUg MjIsIDAwMTgwIEhlbHNpbmtpLgpZLXR1bm51cy9CdXNpbmVzcyBJRDogMDYxNTUyMS00LiBLb3Rp cGFpa2thL0RvbWljaWxlOiBIZWxzaW5raQotLS0KVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxp c3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGRtYWVuZ2luZSIgaW4KdGhlIGJvZHkgb2Yg YSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcKTW9yZSBtYWpvcmRvbW8gaW5m byBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752826AbeDRHDy (ORCPT ); Wed, 18 Apr 2018 03:03:54 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:41339 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752085AbeDRHDw (ORCPT ); Wed, 18 Apr 2018 03:03:52 -0400 Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client From: Peter Ujfalusi To: Vinod Koul CC: Lars-Peter Clausen , Radhey Shyam Pandey , "linux-kernel@vger.kernel.org" , "michal.simek@xilinx.com" , "dmaengine@vger.kernel.org" , "dan.j.williams@intel.com" , Appana Durga Kedareswara Rao , "linux-arm-kernel@lists.infradead.org" References: <1522665546-10035-1-git-send-email-radheys@xilinx.com> <1522665546-10035-3-git-send-email-radheys@xilinx.com> <20180411090854.GY6014@localhost> <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> <4ba085c7-5256-6c8a-5697-c0d5736a6e46@ti.com> <20180417154231.GV6014@localhost> <994c184c-e915-7735-5a8b-81a02c5449b0@ti.com> Message-ID: <43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com> Date: Wed, 18 Apr 2018 10:03:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <994c184c-e915-7735-5a8b-81a02c5449b0@ti.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-18 09:39, Peter Ujfalusi wrote: > > > On 2018-04-17 18:42, Vinod Koul wrote: >> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote: >> >>> @@ -709,6 +709,11 @@ struct dma_filter { >>> * be called after period_len bytes have been transferred. >>> * @device_prep_interleaved_dma: Transfer expression in a generic way. >>> * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address >>> + * @device_attach_metadata: Some DMA engines can send and receive side band >>> + * information, commands or parameters which is not transferred within the >>> + * data stream itself. In such case clients can set the metadata to the >>> + * given descriptor and it is going to be sent to the peripheral, or in >>> + * case of DEV_TO_MEM the provided buffer will receive the metadata. >>> * @device_config: Pushes a new configuration to a channel, return 0 or an error >>> * code >>> * @device_pause: Pauses any transfer happening on a channel. Returns >>> @@ -796,6 +801,9 @@ struct dma_device { >>> struct dma_chan *chan, dma_addr_t dst, u64 data, >>> unsigned long flags); >>> >>> + int (*device_attach_metadata)(struct dma_async_tx_descriptor *desc, >>> + void *data, size_t len); >> >> while i am okay with the concept, I would not want to go again the custom >> pointer route, this is a no-go for me. >> >> Instead lets add the vendor data, define that explicitly. We can use struct, >> tokens or something else to define these. But lets try to stay away from >> opaque objects please :-) > > The DMA does not interpret the metadata, it is information which can be > only understood by the client driver and the remote peripheral. It is > just chunk of data (parameters, timestamps, keys, etc) that needs to > travel along with the payload. > > The content is not relevant for the DMA itself. To add: different peripherals needs to send receive different metadata and even the same peripheral might pass different information based on their operating mode. The size of metadata can be different as well. So it is not really vendor specific metadata, but peripheral, operating mode and other factors affected chunk of data. > > - Péter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.ujfalusi@ti.com (Peter Ujfalusi) Date: Wed, 18 Apr 2018 10:03:45 +0300 Subject: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client In-Reply-To: <994c184c-e915-7735-5a8b-81a02c5449b0@ti.com> References: <1522665546-10035-1-git-send-email-radheys@xilinx.com> <1522665546-10035-3-git-send-email-radheys@xilinx.com> <20180411090854.GY6014@localhost> <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> <4ba085c7-5256-6c8a-5697-c0d5736a6e46@ti.com> <20180417154231.GV6014@localhost> <994c184c-e915-7735-5a8b-81a02c5449b0@ti.com> Message-ID: <43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2018-04-18 09:39, Peter Ujfalusi wrote: > > > On 2018-04-17 18:42, Vinod Koul wrote: >> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote: >> >>> @@ -709,6 +709,11 @@ struct dma_filter { >>> * be called after period_len bytes have been transferred. >>> * @device_prep_interleaved_dma: Transfer expression in a generic way. >>> * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address >>> + * @device_attach_metadata: Some DMA engines can send and receive side band >>> + * information, commands or parameters which is not transferred within the >>> + * data stream itself. In such case clients can set the metadata to the >>> + * given descriptor and it is going to be sent to the peripheral, or in >>> + * case of DEV_TO_MEM the provided buffer will receive the metadata. >>> * @device_config: Pushes a new configuration to a channel, return 0 or an error >>> * code >>> * @device_pause: Pauses any transfer happening on a channel. Returns >>> @@ -796,6 +801,9 @@ struct dma_device { >>> struct dma_chan *chan, dma_addr_t dst, u64 data, >>> unsigned long flags); >>> >>> + int (*device_attach_metadata)(struct dma_async_tx_descriptor *desc, >>> + void *data, size_t len); >> >> while i am okay with the concept, I would not want to go again the custom >> pointer route, this is a no-go for me. >> >> Instead lets add the vendor data, define that explicitly. We can use struct, >> tokens or something else to define these. But lets try to stay away from >> opaque objects please :-) > > The DMA does not interpret the metadata, it is information which can be > only understood by the client driver and the remote peripheral. It is > just chunk of data (parameters, timestamps, keys, etc) that needs to > travel along with the payload. > > The content is not relevant for the DMA itself. To add: different peripherals needs to send receive different metadata and even the same peripheral might pass different information based on their operating mode. The size of metadata can be different as well. So it is not really vendor specific metadata, but peripheral, operating mode and other factors affected chunk of data. > > - P?ter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > - P?ter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki