From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeniy.Paltsev@synopsys.com (Eugeniy Paltsev) Date: Thu, 27 Apr 2017 15:34:33 +0000 Subject: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver In-Reply-To: <1493143941.24567.196.camel@linux.intel.com> References: <1491573855-1039-1-git-send-email-Eugeniy.Paltsev@synopsys.com> <1491573855-1039-3-git-send-email-Eugeniy.Paltsev@synopsys.com> <1492518695.24567.56.camel@linux.intel.com> <1492784977.16657.6.camel@synopsys.com> <1492787583.24567.120.camel@linux.intel.com> <1493049305.25985.4.camel@synopsys.com> <1493052970.24567.168.camel@linux.intel.com> <1493133369.25985.10.camel@synopsys.com> <1493143941.24567.196.camel@linux.intel.com> List-ID: Message-ID: <1493307272.25985.20.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org On Tue, 2017-04-25@21:12 +0300, Andy Shevchenko wrote: > On Tue, 2017-04-25@15:16 +0000, Eugeniy Paltsev wrote: > > On Mon, 2017-04-24@19:56 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-24@15:55 +0000, Eugeniy Paltsev wrote: > > > > Hi, > > > > On Fri, 2017-04-21@18:13 +0300, Andy Shevchenko wrote: > > > > > On Fri, 2017-04-21@14:29 +0000, Eugeniy Paltsev wrote: > > > > > > On Tue, 2017-04-18@15:31 +0300, Andy Shevchenko wrote: > > > > > > > On Fri, 2017-04-07@17:04 +0300, Eugeniy Paltsev wrote: > > > > This IP can be (ans is) configured with small block size. > > > > (note, that I am not saying about runtime HW configuration) > > > > > > > > And there is opportunity what we can't use sg_list directly and > > > > need > > > > to > > > > split sg_list to a smaller chunks. > > > > > > That's what I have referred quite ago. The driver should provide > > > an > > > interface to tell potential caller what maximum block (number of > > > items > > > with given bus width) it supports. > > > > > > We have struct dma_parms in struct device, but what we actually > > > need > > > is > > > to support similar on per channel basis in DMAengine framework. > > > > > > So, instead of working around this I recommend either to > > > implement > > > it > > > properly or rely on the fact that in the future someone > > > eventually > > > does that for you. > > > > > > Each driver which has this re-splitting mechanism should be > > > cleaned > > > up and refactored. > > > > I still can't see any pros of this implementation. > > There is no performance profit: we anyway need to re-splitt sg_list > > (but now in dma-user driver instead of dma driver) --->--- > > If we want to use same descriptors several times we just can use > > DMA_CTRL_REUSE option - the descriptors will be created one time > > and re-splitting will be ?ompleted only one time. > > There are two type of descriptors: SW and HW. That flag about SW > descriptor, so, it in most cases has nothing to do with the actual > entry size. Hmm, I checked all virt-dma code attentively and I don't see this limitation. The only existing limitation I can see is that we can use DMA_CTRL_REUSE only for channels supporting slave transfers. (But it is irrelevant to our discussion) So, we can use DMA_CTRL_REUSE for both HW/SW descriptor types. -- ?Eugeniy Paltsev From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeniy Paltsev Subject: Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver Date: Thu, 27 Apr 2017 15:34:33 +0000 Message-ID: <1493307272.25985.20.camel@synopsys.com> References: <1491573855-1039-1-git-send-email-Eugeniy.Paltsev@synopsys.com> <1491573855-1039-3-git-send-email-Eugeniy.Paltsev@synopsys.com> <1492518695.24567.56.camel@linux.intel.com> <1492784977.16657.6.camel@synopsys.com> <1492787583.24567.120.camel@linux.intel.com> <1493049305.25985.4.camel@synopsys.com> <1493052970.24567.168.camel@linux.intel.com> <1493133369.25985.10.camel@synopsys.com> <1493143941.24567.196.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1493143941.24567.196.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> Content-Language: en-US Content-ID: <5F1B665FD522044486BB772894009119-z7JfP6tgrtVBCHUSTMH8dZqQE7yCjDx5@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org" Cc: "vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org" , "linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org T24gVHVlLCAyMDE3LTA0LTI1IGF0IDIxOjEyICswMzAwLCBBbmR5IFNoZXZjaGVua28gd3JvdGU6 DQo+IE9uIFR1ZSwgMjAxNy0wNC0yNSBhdCAxNToxNiArMDAwMCwgRXVnZW5peSBQYWx0c2V2IHdy b3RlOg0KPiA+IE9uIE1vbiwgMjAxNy0wNC0yNCBhdCAxOTo1NiArMDMwMCwgQW5keSBTaGV2Y2hl bmtvIHdyb3RlOg0KPiA+ID4gT24gTW9uLCAyMDE3LTA0LTI0IGF0IDE1OjU1ICswMDAwLCBFdWdl bml5IFBhbHRzZXYgd3JvdGU6DQo+ID4gPiA+IEhpLA0KPiA+ID4gPiBPbiBGcmksIDIwMTctMDQt MjEgYXQgMTg6MTMgKzAzMDAsIEFuZHkgU2hldmNoZW5rbyB3cm90ZToNCj4gPiA+ID4gPiBPbiBG cmksIDIwMTctMDQtMjEgYXQgMTQ6MjkgKzAwMDAsIEV1Z2VuaXkgUGFsdHNldiB3cm90ZToNCj4g PiA+ID4gPiA+IE9uIFR1ZSwgMjAxNy0wNC0xOCBhdCAxNTozMSArMDMwMCwgQW5keSBTaGV2Y2hl bmtvIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiBPbiBGcmksIDIwMTctMDQtMDcgYXQgMTc6MDQgKzAz MDAsIEV1Z2VuaXkgUGFsdHNldiB3cm90ZToNCj4gPiA+ID4gVGhpcyBJUCBjYW4gYmUgKGFucyBp cykgY29uZmlndXJlZCB3aXRoIHNtYWxsIGJsb2NrIHNpemUuDQo+ID4gPiA+IChub3RlLCB0aGF0 IEkgYW0gbm90IHNheWluZyBhYm91dCBydW50aW1lIEhXIGNvbmZpZ3VyYXRpb24pDQo+ID4gPiA+ DQo+ID4gPiA+IEFuZCB0aGVyZSBpcyBvcHBvcnR1bml0eSB3aGF0IHdlIGNhbid0IHVzZSBzZ19s aXN0IGRpcmVjdGx5IGFuZA0KPiA+ID4gPiBuZWVkDQo+ID4gPiA+IHRvDQo+ID4gPiA+IHNwbGl0 IHNnX2xpc3QgdG8gYSBzbWFsbGVyIGNodW5rcy4NCj4gPiA+DQo+ID4gPiBUaGF0J3Mgd2hhdCBJ IGhhdmUgcmVmZXJyZWQgcXVpdGUgYWdvLiBUaGUgZHJpdmVyIHNob3VsZCBwcm92aWRlDQo+ID4g PiBhbg0KPiA+ID4gaW50ZXJmYWNlIHRvIHRlbGwgcG90ZW50aWFsIGNhbGxlciB3aGF0IG1heGlt dW0gYmxvY2sgKG51bWJlciBvZg0KPiA+ID4gaXRlbXMNCj4gPiA+IHdpdGggZ2l2ZW4gYnVzIHdp ZHRoKSBpdCBzdXBwb3J0cy4NCj4gPiA+DQo+ID4gPiBXZSBoYXZlIHN0cnVjdCBkbWFfcGFybXMg aW4gc3RydWN0IGRldmljZSwgYnV0IHdoYXQgd2UgYWN0dWFsbHkNCj4gPiA+IG5lZWQNCj4gPiA+ IGlzDQo+ID4gPiB0byBzdXBwb3J0IHNpbWlsYXIgb24gcGVyIGNoYW5uZWwgYmFzaXMgaW4gRE1B ZW5naW5lIGZyYW1ld29yay4NCj4gPiA+DQo+ID4gPiBTbywgaW5zdGVhZCBvZiB3b3JraW5nIGFy b3VuZCB0aGlzIEkgcmVjb21tZW5kIGVpdGhlciB0bw0KPiA+ID4gaW1wbGVtZW50DQo+ID4gPiBp dA0KPiA+ID4gcHJvcGVybHkgb3IgcmVseSBvbiB0aGUgZmFjdCB0aGF0IGluIHRoZSBmdXR1cmUg c29tZW9uZQ0KPiA+ID4gZXZlbnR1YWxseQ0KPiA+ID4gZG9lcyB0aGF0IGZvciB5b3UuDQo+ID4g Pg0KPiA+ID4gRWFjaCBkcml2ZXIgd2hpY2ggaGFzIHRoaXMgcmUtc3BsaXR0aW5nIG1lY2hhbmlz bSBzaG91bGQgYmUNCj4gPiA+IGNsZWFuZWQNCj4gPiA+IHVwIGFuZCByZWZhY3RvcmVkLg0KPiA+ DQo+ID4gSSBzdGlsbCBjYW4ndCBzZWUgYW55IHByb3Mgb2YgdGhpcyBpbXBsZW1lbnRhdGlvbi4N Cj4gPiBUaGVyZSBpcyBubyBwZXJmb3JtYW5jZSBwcm9maXQ6IHdlIGFueXdheSBuZWVkIHRvIHJl LXNwbGl0dCBzZ19saXN0DQo+ID4gKGJ1dCBub3cgaW4gZG1hLXVzZXIgZHJpdmVyIGluc3RlYWQg b2YgZG1hIGRyaXZlcikNCi0tLT4tLS0NCj4gPiBJZiB3ZSB3YW50IHRvIHVzZSBzYW1lIGRlc2Ny aXB0b3JzIHNldmVyYWwgdGltZXMgd2UganVzdCBjYW4gdXNlDQo+ID4gRE1BX0NUUkxfUkVVU0Ug b3B0aW9uIC0gdGhlIGRlc2NyaXB0b3JzIHdpbGwgYmUgY3JlYXRlZCBvbmUgdGltZQ0KPiA+IGFu ZCByZS1zcGxpdHRpbmcgd2lsbCBiZSDRgW9tcGxldGVkIG9ubHkgb25lIHRpbWUuDQo+DQo+IFRo ZXJlIGFyZSB0d28gdHlwZSBvZiBkZXNjcmlwdG9yczogU1cgYW5kIEhXLiBUaGF0IGZsYWcgYWJv dXQgU1cNCj4gZGVzY3JpcHRvciwgc28sIGl0IGluIG1vc3QgY2FzZXMgaGFzIG5vdGhpbmcgdG8g ZG8gd2l0aCB0aGUgYWN0dWFsDQo+IGVudHJ5IHNpemUuDQoNCkhtbSwgSSBjaGVja2VkIGFsbCB2 aXJ0LWRtYSBjb2RlIGF0dGVudGl2ZWx5IGFuZCBJIGRvbid0IHNlZSB0aGlzDQpsaW1pdGF0aW9u Lg0KVGhlIG9ubHkgZXhpc3RpbmcgbGltaXRhdGlvbiBJIGNhbiBzZWUgaXMgdGhhdCB3ZSBjYW4g dXNlDQpETUFfQ1RSTF9SRVVTRSBvbmx5IGZvciBjaGFubmVscyBzdXBwb3J0aW5nIHNsYXZlIHRy YW5zZmVycy4gKEJ1dCBpdCBpcw0KaXJyZWxldmFudCB0byBvdXIgZGlzY3Vzc2lvbikNCg0KU28s IHdlIGNhbiB1c2UgRE1BX0NUUkxfUkVVU0UgZm9yIGJvdGggSFcvU1cgZGVzY3JpcHRvciB0eXBl cy4NCg0KLS0NCsKgRXVnZW5peSBQYWx0c2V2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968784AbdD0PfI (ORCPT ); Thu, 27 Apr 2017 11:35:08 -0400 Received: from smtprelay4.synopsys.com ([198.182.47.9]:56717 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S968427AbdD0Pe7 (ORCPT ); Thu, 27 Apr 2017 11:34:59 -0400 From: Eugeniy Paltsev To: "andriy.shevchenko@linux.intel.com" CC: "vinod.koul@intel.com" , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , "Alexey.Brodkin@synopsys.com" , "devicetree@vger.kernel.org" , "Eugeniy.Paltsev@synopsys.com" , "linux-snps-arc@lists.infradead.org" , "dan.j.williams@intel.com" , "dmaengine@vger.kernel.org" Subject: Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver Thread-Topic: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver Thread-Index: AQHSr6fifaPEtWYJzkyOcLiQLbUIqKHK/piAgATX+YCAAAwigIAEwr2AgAAREQCAAXZjgIAAMTuAgAL4kgA= Date: Thu, 27 Apr 2017 15:34:33 +0000 Message-ID: <1493307272.25985.20.camel@synopsys.com> References: <1491573855-1039-1-git-send-email-Eugeniy.Paltsev@synopsys.com> <1491573855-1039-3-git-send-email-Eugeniy.Paltsev@synopsys.com> <1492518695.24567.56.camel@linux.intel.com> <1492784977.16657.6.camel@synopsys.com> <1492787583.24567.120.camel@linux.intel.com> <1493049305.25985.4.camel@synopsys.com> <1493052970.24567.168.camel@linux.intel.com> <1493133369.25985.10.camel@synopsys.com> <1493143941.24567.196.camel@linux.intel.com> In-Reply-To: <1493143941.24567.196.camel@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.113] Content-Type: text/plain; charset="utf-8" Content-ID: <5F1B665FD522044486BB772894009119@internal.synopsys.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3RFZJca022574 On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote: > On Tue, 2017-04-25 at 15:16 +0000, Eugeniy Paltsev wrote: > > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote: > > > > Hi, > > > > On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote: > > > > > On Fri, 2017-04-21 at 14:29 +0000, Eugeniy Paltsev wrote: > > > > > > On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote: > > > > > > > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote: > > > > This IP can be (ans is) configured with small block size. > > > > (note, that I am not saying about runtime HW configuration) > > > > > > > > And there is opportunity what we can't use sg_list directly and > > > > need > > > > to > > > > split sg_list to a smaller chunks. > > > > > > That's what I have referred quite ago. The driver should provide > > > an > > > interface to tell potential caller what maximum block (number of > > > items > > > with given bus width) it supports. > > > > > > We have struct dma_parms in struct device, but what we actually > > > need > > > is > > > to support similar on per channel basis in DMAengine framework. > > > > > > So, instead of working around this I recommend either to > > > implement > > > it > > > properly or rely on the fact that in the future someone > > > eventually > > > does that for you. > > > > > > Each driver which has this re-splitting mechanism should be > > > cleaned > > > up and refactored. > > > > I still can't see any pros of this implementation. > > There is no performance profit: we anyway need to re-splitt sg_list > > (but now in dma-user driver instead of dma driver) --->--- > > If we want to use same descriptors several times we just can use > > DMA_CTRL_REUSE option - the descriptors will be created one time > > and re-splitting will be сompleted only one time. > > There are two type of descriptors: SW and HW. That flag about SW > descriptor, so, it in most cases has nothing to do with the actual > entry size. Hmm, I checked all virt-dma code attentively and I don't see this limitation. The only existing limitation I can see is that we can use DMA_CTRL_REUSE only for channels supporting slave transfers. (But it is irrelevant to our discussion) So, we can use DMA_CTRL_REUSE for both HW/SW descriptor types. --  Eugeniy Paltsev