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: <78828d31-e4cd-5211-f1b6-8918ac38f599@ti.com> Date: Tue, 17 Apr 2018 17:53:51 +0300 To: Lars-Peter Clausen , Radhey Shyam Pandey , Vinod Koul Cc: "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: T24gMjAxOC0wNC0xNyAxNjo1OCwgTGFycy1QZXRlciBDbGF1c2VuIHdyb3RlOgo+Pj4gVGhlcmUg YXJlIHR3byBvcHRpb25zLgo+Pj4KPj4+IEVpdGhlciB5b3UgZXh0ZW5kIHRoZSBnZW5lcmljIGlu dGVyZmFjZXMgc28gaXQgY2FuIGNvdmVyIHlvdXIgdXNlY2FzZSBpbiBhCj4+PiBnZW5lcmljIHdh eS4gRS5nLiB0aGUgYWJpbGl0eSB0byBhdHRhY2ggbWV0YSBkYXRhIHRvIHRyYW5zZmVyLgo+Pgo+ PiBGd2l3IEkgaGF2ZSB0aGlzIHBhdGNoIGFzIHBhcnQgb2YgYSBiaWdnZXIgd29yayB0byBhY2hp ZXZlIHNpbWlsYXIgcmVzdWx0czoKPiAKPiBUaGF0J3MgZ29vZCBzdHVmZi4gSXMgdGhpcyBpbiBh IHB1YmxpYyB0cmVlIHNvbWV3aGVyZT8KCk5vdCBhdG0uIEkgY2FuIG5vdCBzZW5kIHRoZSB1c2Vy IG9mIHRoZSBuZXcgQVBJIGFuZCBJIGRpZCBub3Qgd2FudGVkIHRvCnNlbmQgc29tZXRoaW5nIGxp a2UgdGhpcyBvdXQgb2YgdGhlIGJsdWUgdy9vIGNvbnRleHQuCgpCdXQgYXMgaXQgaXMgYSBnZW5l cmljIHBhdGNoLCBJIGNhbiBzZW5kIGl0IGFzIHdlbGwuIFRoZSBvbmx5IHRoaW5nIGlzCnRoYXQg dGhlIG5lZWQgZm9yIHRoZSBtZW1jcHksIHNvIEkgbWlnaHQgZW5kIHVwIHdpdGgKcHRyID0gZ2V0 X21ldGFkYXRhX3B0cihkZXNjLCAmc2l6ZSk7IC8qIHNpemU6IGluIFJYIHRoZSB2YWxpZCBzaXpl ICovCgphbmQgc2V0X21ldGFkYXRhX3NpemUoKTsgLyogaW4gVFggdG8gdGVsbCBob3cgdGhlIGNs aWVudCBwbGFjZWQgKi8KCk9yIHNvbWV0aGluZyBsaWtlIHRoYXQsIHRoZSBhdHRhY2hfbWV0YWRh dGEoKSBhcyBpdCBpcyB3b3JrcyBqdXN0IGZpbmUsCmJ1dCBoaWdoIHRocm91Z2hwdXQgbWlnaHQg bm90IGxpa2UgdGhlIG1lbWNweS4KCj4+PiBPciB5b3UgY2FuIGltcGxlbWVudCBhIGludGVyZmFj ZSB0aGF0IGlzIHNwZWNpZmljIHRvIHlvdXIgRE1BIGNvbnRyb2xsZXIgYW5kCj4+PiBhbnkgY2xp ZW50IHVzaW5nIHRoaXMgaW50ZXJmYWNlIGtub3dzIGl0IGlzIHRhbGtpbmcgdG8geW91ciBETUEg Y29udHJvbGxlci4KPj4KPj4gSHJtLCBzbyB3ZSBjYW4gaGF2ZSBETUEgZHJpdmVyIHNwZWNpZmlj IGNhbGxzPyBUaGUgcmVhc29uIHdoeSBUSSdzIGtleXN0b25lIDIKPj4gbmF2aWdhdG9yIERNQSBz dXBwb3J0IHdhcyByZWplY3RlZCB0aGF0IGl0IHdhcyBpbnRyb2R1Y2luZyBOQVYgc3BlY2lmaWMg Y2FsbHMKPj4gZm9yIGNsaWVudHMgdG8gY29uZmlndXJlIGZlYXR1cmVzIG5vdCB5ZXQgc3VwcG9y dGVkIGJ5IHRoZSBmcmFtZXdvcmsuCj4gCj4gSW4gbXkgb3BpbmlvbiBpdCBpcyBPSywgc29tZWJv ZHkgZWxzZSBtaWdodCBoYXZlIGRpZmZlcmVudCBpZGVhcy4gSSBtZWFuIGl0Cj4gaXMgbm90IG5p Y2UsIGJ1dCBpdCBpcyBiZXR0ZXIgdGhhbiB0aGUgYWx0ZXJuYXRpdmUgb2Ygb3ZlcmxvYWRpbmcg dGhlCj4gZ2VuZXJpYyBBUEkgd2l0aCBkcml2ZXIgc3BlY2lmaWMgc2VtYW50aWNzIG9yIGludHJv ZHVjaW5nIHNvbWUga2luZCBvZiBJT0NUTAo+IGNhdGNoIGFsbCBjYWxsYmFjay4KClRydWUsIGJ1 dCB0aGUgZ2VuZXJpYyBBUEkgY2FuIGJlIGV4dGVuZGVkIGFzIHdlbGwgdG8gY292ZXIgbmV3IGdy b3VuZHMsCmZlYXR1cmVzLiBMaWtlIHRoaXMgbWV0YWRhdGEgdGhpbmcuCgo+IElmIHRoZXJlIGlz IHRpZ2h0IGNvdXBsaW5nIGJldHdlZW4gdGhlIERNQSBjb3JlIGFuZCBjbGllbnQgYW5kIHRoZXJl IGlzIG5vCj4gaW50ZW50aW9uIG9mIHVzaW5nIGEgZ2VuZXJpYyBjbGllbnQgdGhlIGJlc3Qgc29s dXRpb24gbWlnaHQgZXZlbiBiZSB0byBubwo+IHVzZSBETUFlbmdpbmUgYXQgYWxsLgoKVGhpcyBp cyBob3cgdGhlIGtuYXYgc3R1ZmYgZW5kZWQgdXAuIFdlbGwgaXQgaXMgb25seSB1c2VkIGJ5IG5l dHdvcmtpbmcKYXRtLCBzbyBpdCBpcyAnZmluZScgdG8gaGF2ZSBjdXN0b20gQVBJLCBidXQgaXQg aXMgbm90IHBvcnRhYmxlLgoKPiAKCi0gUMOpdGVyCgpUZXhhcyBJbnN0cnVtZW50cyBGaW5sYW5k IE95LCBQb3Jra2FsYW5rYXR1IDIyLCAwMDE4MCBIZWxzaW5raS4KWS10dW5udXMvQnVzaW5lc3Mg SUQ6IDA2MTU1MjEtNC4gS290aXBhaWtrYS9Eb21pY2lsZTogSGVsc2lua2kKLS0tClRvIHVuc3Vi c2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBkbWFlbmdp bmUiIGluCnRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3Jn Ck1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21v LWluZm8uaHRtbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752503AbeDQOyE (ORCPT ); Tue, 17 Apr 2018 10:54:04 -0400 Received: from lelnx194.ext.ti.com ([198.47.27.80]:13022 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752043AbeDQOyC (ORCPT ); Tue, 17 Apr 2018 10:54:02 -0400 Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client To: Lars-Peter Clausen , Radhey Shyam Pandey , Vinod Koul CC: "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: <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> <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> From: Peter Ujfalusi Message-ID: <78828d31-e4cd-5211-f1b6-8918ac38f599@ti.com> Date: Tue, 17 Apr 2018 17:53:51 +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: <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> 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-17 16:58, Lars-Peter Clausen wrote: >>> There are two options. >>> >>> Either you extend the generic interfaces so it can cover your usecase in a >>> generic way. E.g. the ability to attach meta data to transfer. >> >> Fwiw I have this patch as part of a bigger work to achieve similar results: > > That's good stuff. Is this in a public tree somewhere? Not atm. I can not send the user of the new API and I did not wanted to send something like this out of the blue w/o context. But as it is a generic patch, I can send it as well. The only thing is that the need for the memcpy, so I might end up with ptr = get_metadata_ptr(desc, &size); /* size: in RX the valid size */ and set_metadata_size(); /* in TX to tell how the client placed */ Or something like that, the attach_metadata() as it is works just fine, but high throughput might not like the memcpy. >>> Or you can implement a interface that is specific to your DMA controller and >>> any client using this interface knows it is talking to your DMA controller. >> >> Hrm, so we can have DMA driver specific calls? The reason why TI's keystone 2 >> navigator DMA support was rejected that it was introducing NAV specific calls >> for clients to configure features not yet supported by the framework. > > In my opinion it is OK, somebody else might have different ideas. I mean it > is not nice, but it is better than the alternative of overloading the > generic API with driver specific semantics or introducing some kind of IOCTL > catch all callback. True, but the generic API can be extended as well to cover new grounds, features. Like this metadata thing. > If there is tight coupling between the DMA core and client and there is no > intention of using a generic client the best solution might even be to no > use DMAengine at all. This is how the knav stuff ended up. Well it is only used by networking atm, so it is 'fine' to have custom API, but it is not portable. > - 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, 17 Apr 2018 17:53:51 +0300 Subject: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client In-Reply-To: <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> 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> <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> Message-ID: <78828d31-e4cd-5211-f1b6-8918ac38f599@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2018-04-17 16:58, Lars-Peter Clausen wrote: >>> There are two options. >>> >>> Either you extend the generic interfaces so it can cover your usecase in a >>> generic way. E.g. the ability to attach meta data to transfer. >> >> Fwiw I have this patch as part of a bigger work to achieve similar results: > > That's good stuff. Is this in a public tree somewhere? Not atm. I can not send the user of the new API and I did not wanted to send something like this out of the blue w/o context. But as it is a generic patch, I can send it as well. The only thing is that the need for the memcpy, so I might end up with ptr = get_metadata_ptr(desc, &size); /* size: in RX the valid size */ and set_metadata_size(); /* in TX to tell how the client placed */ Or something like that, the attach_metadata() as it is works just fine, but high throughput might not like the memcpy. >>> Or you can implement a interface that is specific to your DMA controller and >>> any client using this interface knows it is talking to your DMA controller. >> >> Hrm, so we can have DMA driver specific calls? The reason why TI's keystone 2 >> navigator DMA support was rejected that it was introducing NAV specific calls >> for clients to configure features not yet supported by the framework. > > In my opinion it is OK, somebody else might have different ideas. I mean it > is not nice, but it is better than the alternative of overloading the > generic API with driver specific semantics or introducing some kind of IOCTL > catch all callback. True, but the generic API can be extended as well to cover new grounds, features. Like this metadata thing. > If there is tight coupling between the DMA core and client and there is no > intention of using a generic client the best solution might even be to no > use DMAengine at all. This is how the knav stuff ended up. Well it is only used by networking atm, so it is 'fine' to have custom API, but it is not portable. > - P?ter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki