From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeniy.Paltsev@synopsys.com (Eugeniy Paltsev) Date: Fri, 25 Nov 2016 11:40:31 +0000 Subject: [PATCH v5 2/2] DW DMAC: add multi-block property to device tree In-Reply-To: <1480003098.20074.18.camel@linux.intel.com> References: <1479999878-19120-1-git-send-email-Eugeniy.Paltsev@synopsys.com> <1479999878-19120-3-git-send-email-Eugeniy.Paltsev@synopsys.com> <1480002728.20074.15.camel@linux.intel.com> <1480003098.20074.18.camel@linux.intel.com> List-ID: Message-ID: <1480074030.2534.46.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org On Thu, 2016-11-24@17:58 +0200, Andy Shevchenko wrote: > On Thu, 2016-11-24@17:52 +0200, Andy Shevchenko wrote: > > > > On Thu, 2016-11-24@18:04 +0300, Eugeniy Paltsev wrote: > > > > > > Several versions of DW DMAC have multi block transfers hardware > > > support. Hardware support of multi block transfers is disabled > > > by default if we use DT to configure DMAC and software emulation > > > of multi block transfers used instead. > > > Add multi-block property, so it is possible to enable hardware > > > multi block transfers (if present) via DT. > > > > > > Switch from per device is_nollp variable to multi_block array > > > to be able enable/disable multi block transfers separately per > > > channel. > > Thanks for an update. Basically I'm fine with this one. > > > > So, we still have question about autoconfiguration in SPEAr SoCs, > > and > > your ARC SoC but it's a different story. I would expect once you > > will > > clarify it. > > > > Another one is minor listed below, otherwise > > > > Acked-by: Andy Shevchenko > > > > > > > > @@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device > > > *pdev) > > > ? pdata->data_width[tmp] = BIT(arr[tmp] & > > > 0x07); > > > ? } > > > ? > > > + if (!of_property_read_u32_array(np, "multi-block", chan, > > > nr_channels)) { > > > + for (tmp = 0; tmp < nr_channels; tmp++) > > > + pdata->multi_block[tmp] = chan[tmp]; > > ...mb (as short of multi-block) would suit better. > Oh, sorry, guys, but one more important thing. If there is no such > property, keep a default to "supported". Otherwise you will break old > (working) DTBs. Should I remove explicit declaration "multi-block" property from existing DTS (which I added during v5 patch iteration)? I mean that: ---------------------->8----------------------- + multi-block = <1 1 1 1 1 1 1 1>; ---------------------->8----------------------- We don't actually need it, if we use use 1 ("supported") as "multi- block" property default value. -- ?Paltsev Eugeniy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeniy Paltsev Subject: Re: [PATCH v5 2/2] DW DMAC: add multi-block property to device tree Date: Fri, 25 Nov 2016 11:40:31 +0000 Message-ID: <1480074030.2534.46.camel@synopsys.com> References: <1479999878-19120-1-git-send-email-Eugeniy.Paltsev@synopsys.com> <1479999878-19120-3-git-send-email-Eugeniy.Paltsev@synopsys.com> <1480002728.20074.15.camel@linux.intel.com> <1480003098.20074.18.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1480003098.20074.18.camel@linux.intel.com> Content-Language: en-US Content-ID: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org To: "andriy.shevchenko@linux.intel.com" Cc: "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "christian.ruppert@alitech.com" , "arnd@arndb.de" , "vinod.koul@intel.com" , "vireshk@kernel.org" , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , "dmaengine@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "shiraz.linux.kernel@gmail.com" List-Id: devicetree@vger.kernel.org T24gVGh1LCAyMDE2LTExLTI0IGF0IDE3OjU4ICswMjAwLCBBbmR5IFNoZXZjaGVua28gd3JvdGU6 DQo+IE9uIFRodSwgMjAxNi0xMS0yNCBhdCAxNzo1MiArMDIwMCwgQW5keSBTaGV2Y2hlbmtvIHdy b3RlOg0KPiA+IA0KPiA+IE9uIFRodSwgMjAxNi0xMS0yNCBhdCAxODowNCArMDMwMCwgRXVnZW5p eSBQYWx0c2V2IHdyb3RlOg0KPiA+ID4gDQo+ID4gPiBTZXZlcmFsIHZlcnNpb25zIG9mIERXIERN QUMgaGF2ZSBtdWx0aSBibG9jayB0cmFuc2ZlcnMgaGFyZHdhcmUNCj4gPiA+IHN1cHBvcnQuIEhh cmR3YXJlIHN1cHBvcnQgb2YgbXVsdGkgYmxvY2sgdHJhbnNmZXJzIGlzIGRpc2FibGVkDQo+ID4g PiBieSBkZWZhdWx0IGlmIHdlIHVzZSBEVCB0byBjb25maWd1cmUgRE1BQyBhbmQgc29mdHdhcmUg ZW11bGF0aW9uDQo+ID4gPiBvZiBtdWx0aSBibG9jayB0cmFuc2ZlcnMgdXNlZCBpbnN0ZWFkLg0K PiA+ID4gQWRkIG11bHRpLWJsb2NrIHByb3BlcnR5LCBzbyBpdCBpcyBwb3NzaWJsZSB0byBlbmFi bGUgaGFyZHdhcmUNCj4gPiA+IG11bHRpIGJsb2NrIHRyYW5zZmVycyAoaWYgcHJlc2VudCkgdmlh IERULg0KPiA+ID4gDQo+ID4gPiBTd2l0Y2ggZnJvbSBwZXIgZGV2aWNlIGlzX25vbGxwIHZhcmlh YmxlIHRvIG11bHRpX2Jsb2NrIGFycmF5DQo+ID4gPiB0byBiZSBhYmxlIGVuYWJsZS9kaXNhYmxl IG11bHRpIGJsb2NrIHRyYW5zZmVycyBzZXBhcmF0ZWx5IHBlcg0KPiA+ID4gY2hhbm5lbC4NCj4g PiBUaGFua3MgZm9yIGFuIHVwZGF0ZS4gQmFzaWNhbGx5IEknbSBmaW5lIHdpdGggdGhpcyBvbmUu DQo+ID4gDQo+ID4gU28sIHdlIHN0aWxsIGhhdmUgcXVlc3Rpb24gYWJvdXQgYXV0b2NvbmZpZ3Vy YXRpb24gaW4gU1BFQXIgU29DcywNCj4gPiBhbmQNCj4gPiB5b3VyIEFSQyBTb0MgYnV0IGl0J3Mg YSBkaWZmZXJlbnQgc3RvcnkuIEkgd291bGQgZXhwZWN0IG9uY2UgeW91DQo+ID4gd2lsbA0KPiA+ IGNsYXJpZnkgaXQuDQo+ID4gDQo+ID4gQW5vdGhlciBvbmUgaXMgbWlub3IgbGlzdGVkIGJlbG93 LCBvdGhlcndpc2UNCj4gPiANCj4gPiBBY2tlZC1ieTogQW5keSBTaGV2Y2hlbmtvIDxhbmRyaXku c2hldmNoZW5rb0BsaW51eC5pbnRlbC5jb20+DQo+ID4gDQo+ID4gPiANCj4gPiA+IEBAIC0xNTIs NiArMTU0LDExIEBAIGR3X2RtYV9wYXJzZV9kdChzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlDQo+ID4g PiAqcGRldikNCj4gPiA+IMKgCQkJcGRhdGEtPmRhdGFfd2lkdGhbdG1wXSA9IEJJVChhcnJbdG1w XSAmDQo+ID4gPiAweDA3KTsNCj4gPiA+IMKgCX0NCj4gPiA+IMKgDQo+ID4gPiArCWlmICghb2Zf cHJvcGVydHlfcmVhZF91MzJfYXJyYXkobnAsICJtdWx0aS1ibG9jayIsIGNoYW4sDQo+ID4gPiBu cl9jaGFubmVscykpIHsNCj4gPiA+ICsJCWZvciAodG1wID0gMDsgdG1wIDwgbnJfY2hhbm5lbHM7 IHRtcCsrKQ0KPiA+ID4gKwkJCXBkYXRhLT5tdWx0aV9ibG9ja1t0bXBdID0gY2hhblt0bXBdOw0K PiA+IC4uLm1iIChhcyBzaG9ydCBvZiBtdWx0aS1ibG9jaykgd291bGQgc3VpdCBiZXR0ZXIuDQo+ IE9oLCBzb3JyeSwgZ3V5cywgYnV0IG9uZSBtb3JlIGltcG9ydGFudCB0aGluZy4gSWYgdGhlcmUg aXMgbm8gc3VjaA0KPiBwcm9wZXJ0eSwga2VlcCBhIGRlZmF1bHQgdG8gInN1cHBvcnRlZCIuIE90 aGVyd2lzZSB5b3Ugd2lsbCBicmVhayBvbGQNCj4gKHdvcmtpbmcpIERUQnMuDQpTaG91bGQgSSBy ZW1vdmUgZXhwbGljaXQgZGVjbGFyYXRpb24gIm11bHRpLWJsb2NrIiBwcm9wZXJ0eSBmcm9tDQpl eGlzdGluZyBEVFMgKHdoaWNoIEkgYWRkZWQgZHVyaW5nIHY1IHBhdGNoIGl0ZXJhdGlvbik/DQoN CkkgbWVhbiB0aGF0Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCisJCQltdWx0aS1ibG9jayA9IDwxIDEgMSAxIDEgMSAxIDE+Ow0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KV2UgZG9uJ3QgYWN0dWFsbHkg bmVlZCBpdCwgaWYgd2UgdXNlIHVzZSAxICgic3VwcG9ydGVkIikgYXMgIm11bHRpLQ0KYmxvY2si IHByb3BlcnR5IGRlZmF1bHQgdmFsdWUuDQoNCi0tIA0KwqBQYWx0c2V2IEV1Z2VuaXkNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXNucHMtYXJj IG1haWxpbmcgbGlzdApsaW51eC1zbnBzLWFyY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtc25wcy1hcmM= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753509AbcKYLkv (ORCPT ); Fri, 25 Nov 2016 06:40:51 -0500 Received: from smtprelay.synopsys.com ([198.182.60.111]:41773 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753248AbcKYLkg (ORCPT ); Fri, 25 Nov 2016 06:40:36 -0500 From: Eugeniy Paltsev To: "andriy.shevchenko@linux.intel.com" CC: "vinod.koul@intel.com" , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , "shiraz.linux.kernel@gmail.com" , "devicetree@vger.kernel.org" , "vireshk@kernel.org" , "linux-snps-arc@lists.infradead.org" , "mark.rutland@arm.com" , "dmaengine@vger.kernel.org" , "christian.ruppert@alitech.com" , "arnd@arndb.de" Subject: Re: [PATCH v5 2/2] DW DMAC: add multi-block property to device tree Thread-Topic: [PATCH v5 2/2] DW DMAC: add multi-block property to device tree Thread-Index: AQHSRmQhkoeQwUfuQ0SZzqx0Wz6t2KDoN+AAgAABuQCAAUpNAA== Date: Fri, 25 Nov 2016 11:40:31 +0000 Message-ID: <1480074030.2534.46.camel@synopsys.com> References: <1479999878-19120-1-git-send-email-Eugeniy.Paltsev@synopsys.com> <1479999878-19120-3-git-send-email-Eugeniy.Paltsev@synopsys.com> <1480002728.20074.15.camel@linux.intel.com> <1480003098.20074.18.camel@linux.intel.com> In-Reply-To: <1480003098.20074.18.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.14.113] Content-Type: text/plain; charset="utf-8" Content-ID: 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 uAPBespa007491 On Thu, 2016-11-24 at 17:58 +0200, Andy Shevchenko wrote: > On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote: > > > > On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote: > > > > > > Several versions of DW DMAC have multi block transfers hardware > > > support. Hardware support of multi block transfers is disabled > > > by default if we use DT to configure DMAC and software emulation > > > of multi block transfers used instead. > > > Add multi-block property, so it is possible to enable hardware > > > multi block transfers (if present) via DT. > > > > > > Switch from per device is_nollp variable to multi_block array > > > to be able enable/disable multi block transfers separately per > > > channel. > > Thanks for an update. Basically I'm fine with this one. > > > > So, we still have question about autoconfiguration in SPEAr SoCs, > > and > > your ARC SoC but it's a different story. I would expect once you > > will > > clarify it. > > > > Another one is minor listed below, otherwise > > > > Acked-by: Andy Shevchenko > > > > > > > > @@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device > > > *pdev) > > >   pdata->data_width[tmp] = BIT(arr[tmp] & > > > 0x07); > > >   } > > >   > > > + if (!of_property_read_u32_array(np, "multi-block", chan, > > > nr_channels)) { > > > + for (tmp = 0; tmp < nr_channels; tmp++) > > > + pdata->multi_block[tmp] = chan[tmp]; > > ...mb (as short of multi-block) would suit better. > Oh, sorry, guys, but one more important thing. If there is no such > property, keep a default to "supported". Otherwise you will break old > (working) DTBs. Should I remove explicit declaration "multi-block" property from existing DTS (which I added during v5 patch iteration)? I mean that: ---------------------->8----------------------- + multi-block = <1 1 1 1 1 1 1 1>; ---------------------->8----------------------- We don't actually need it, if we use use 1 ("supported") as "multi- block" property default value. --  Paltsev Eugeniy