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 Content-Length: 2049 Lines: 55 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