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: <99581088-7ef8-6fac-c934-91eadddfb04e@ti.com> Date: Tue, 29 May 2018 18:04:34 +0300 To: Radhey Shyam Pandey , Vinod Koul Cc: Lars-Peter Clausen , "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: SGksCgpPbiAyMDE4LTA1LTE3IDA5OjM5LCBSYWRoZXkgU2h5YW0gUGFuZGV5IHdyb3RlOgo+PiBX ZWxsLCBsZXQncyBzZWUgd2hlcmUgdGhpcyBpcyBnb2luZyB0byBnbyB3aGVuIEkgY2FuIHNlbmQg dGhlIHBhdGNoZXMKPj4gZm9yIHJldmlldy4KPiBUaGFua3MgYWxsLiBAUGV0ZXI6IElmIHdlIGhh dmUgbWV0YWRhdGEgcGF0Y2hzZXQgcmVhZHkgbWF5IGJlIGdvb2QKPiB0byBzZW5kIGFuIFJGQz8K ClNvcnJ5IGZvciB0aGUgZGVsYXksIEkgZ290IGRpc3RyYWN0ZWQgYnkgdGhpczoKaHR0cDovL3d3 dy50aS5jb20vbGl0L3BkZi9zcHJ1aWQ3IENoYXB0ZXIgMTAuCgpJIGhhdmUgZ2l2ZW4gc29tZSB0 b3VnaCB0byB0aGUgbWV0YWRhdGEgYXR0YWNoIHBhdGNoZXMuCkluIG15IGNhc2UgdGhlICdtZXRh ZGF0YScgaXMgbW9yZSBsaWtlIHByaXZhdGUgZGF0YSBzZWN0aW9uIHdpdGhpbiB0aGUKRE1BIGRl c2NyaXB0b3IgKDEwLjEuMi4yLjEpIHdoaWNoIGlzIHVzZWQgYnkgdGhlIHJlbW90ZSBwZXJpcGhl cmFsIGFuZAp0aGUgZHJpdmVyIGZvciB0aGUgZ2l2ZW4gcGVyaXBoZXJhbCBhbmQgaXQgaXMgb3B0 aW9uYWwuCgpJIGxpa2VkIHRoZSBpZGVhIG9mIHRyZWF0aW5nIGl0IGFzIG1ldGFkYXRhIGFzIGl0 IGdpdmVzIG1vcmUgZ2VuZXJpYyBBUEkKd2hpY2ggY2FuIGJlIGFkb3B0ZWQgYnkgb3RoZXIgZHJp dmVycyBpZiB0aGV5IG5lZWQgc29tZXRoaW5nIHNpbWlsYXIuCgpBbm90aGVyIGlzc3VlIEkgaGF2 ZSB3aXRoIHRoZSBhdHRhY2ggbWV0YWRhdGEgd2F5IGlzIHRoYXQgaXQgd291bGQKcmVxdWlyZSBv bmUgbWVtY3B5IHRvIGNvcHkgdGhlIGRhdGEgdG8gdGhlIERNQSBkZXNjcmlwdG9yIGFuZCBpbiBo aWdoCnRocm91Z2hwdXQgY2FzZSBpdCBpcyBub3QgYWNjZXB0YWJsZS4KCkZvciBtZSBwcm9iYWJs eSBhIC5nZXRfcHJpdmF0ZV9hcmVhIC8gLnB1dF9wcml2YXRlX2FyZWEgbGlrZSBBUEkgd291bGQK YmUgZGVzaXJhYmxlIHdoZXJlIEkgY2FuIGdpdmUgdGhlIHBvaW50ZXIgb2YgdGhlICdtZXRhZGF0 YScgYXJlIChhbmQKc2l6ZSkgdG8gdGhlIHVzZXIuCgpCdXQgdGhlc2UgY2FuIGNvLWV4aXN0IGlu IG15IG9waW5pb24gYW5kIERNQSBkcml2ZXJzIGNhbiBvcHQgdG8KaW1wbGVtZW50IG5vbmUsIGVp dGhlciBvciBib3RoIG9mIHRoZSBjYWxsYmFja3MuCgpJbiBjb3VwbGUgb2YgZGF5cyBJIGNhbiB1 cGRhdGUgdGhlIG1ldGFkYXRhIHBhdGNoZXMgSSBoYXZlIGF0bSBhbmQgc2VuZAphcyBSRkMuCgpJ cyB0aGVyZSBhbnl0aGluZyBmcm9tIHlvdXIgc2lkZSBJIHNob3VsZCB0YWtlIGludG8gYWNjb3Vu dCB3aGVuIGRvaW5nIHRoYXQ/CgotIFDDqXRlcgoKVGV4YXMgSW5zdHJ1bWVudHMgRmlubGFuZCBP eSwgUG9ya2thbGFua2F0dSAyMiwgMDAxODAgSGVsc2lua2kuClktdHVubnVzL0J1c2luZXNzIElE OiAwNjE1NTIxLTQuIEtvdGlwYWlra2EvRG9taWNpbGU6IEhlbHNpbmtpCi0tLQpUbyB1bnN1YnNj cmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgZG1hZW5naW5l IiBpbgp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZwpN b3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1p bmZvLmh0bWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936718AbeE2PEd (ORCPT ); Tue, 29 May 2018 11:04:33 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:29162 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965033AbeE2PEV (ORCPT ); Tue, 29 May 2018 11:04:21 -0400 Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client To: Radhey Shyam Pandey , Vinod Koul CC: Lars-Peter Clausen , "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" 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> <20180424035548.GA6014@localhost> From: Peter Ujfalusi Message-ID: <99581088-7ef8-6fac-c934-91eadddfb04e@ti.com> Date: Tue, 29 May 2018 18:04:34 +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: 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 Hi, On 2018-05-17 09:39, Radhey Shyam Pandey wrote: >> Well, let's see where this is going to go when I can send the patches >> for review. > Thanks all. @Peter: If we have metadata patchset ready may be good > to send an RFC? Sorry for the delay, I got distracted by this: http://www.ti.com/lit/pdf/spruid7 Chapter 10. I have given some tough to the metadata attach patches. In my case the 'metadata' is more like private data section within the DMA descriptor (10.1.2.2.1) which is used by the remote peripheral and the driver for the given peripheral and it is optional. I liked the idea of treating it as metadata as it gives more generic API which can be adopted by other drivers if they need something similar. Another issue I have with the attach metadata way is that it would require one memcpy to copy the data to the DMA descriptor and in high throughput case it is not acceptable. For me probably a .get_private_area / .put_private_area like API would be desirable where I can give the pointer of the 'metadata' are (and size) to the user. But these can co-exist in my opinion and DMA drivers can opt to implement none, either or both of the callbacks. In couple of days I can update the metadata patches I have atm and send as RFC. Is there anything from your side I should take into account when doing that? - 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: Tue, 29 May 2018 18:04:34 +0300 Subject: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client In-Reply-To: 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> <20180424035548.GA6014@localhost> Message-ID: <99581088-7ef8-6fac-c934-91eadddfb04e@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, On 2018-05-17 09:39, Radhey Shyam Pandey wrote: >> Well, let's see where this is going to go when I can send the patches >> for review. > Thanks all. @Peter: If we have metadata patchset ready may be good > to send an RFC? Sorry for the delay, I got distracted by this: http://www.ti.com/lit/pdf/spruid7 Chapter 10. I have given some tough to the metadata attach patches. In my case the 'metadata' is more like private data section within the DMA descriptor (10.1.2.2.1) which is used by the remote peripheral and the driver for the given peripheral and it is optional. I liked the idea of treating it as metadata as it gives more generic API which can be adopted by other drivers if they need something similar. Another issue I have with the attach metadata way is that it would require one memcpy to copy the data to the DMA descriptor and in high throughput case it is not acceptable. For me probably a .get_private_area / .put_private_area like API would be desirable where I can give the pointer of the 'metadata' are (and size) to the user. But these can co-exist in my opinion and DMA drivers can opt to implement none, either or both of the callbacks. In couple of days I can update the metadata patches I have atm and send as RFC. Is there anything from your side I should take into account when doing that? - P?ter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki