Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753216AbcKYLwL (ORCPT ); Fri, 25 Nov 2016 06:52:11 -0500 Received: from mga03.intel.com ([134.134.136.65]:6821 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbcKYLwE (ORCPT ); Fri, 25 Nov 2016 06:52:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,547,1473145200"; d="scan'208";a="9275673" Message-ID: <1480074538.20074.24.camel@linux.intel.com> Subject: Re: [PATCH v5 2/2] DW DMAC: add multi-block property to device tree From: Andy Shevchenko To: Eugeniy Paltsev 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" Date: Fri, 25 Nov 2016 13:48:58 +0200 In-Reply-To: <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> <1480074030.2534.46.camel@synopsys.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2520 Lines: 69 On Fri, 2016-11-25 at 11:40 +0000, Eugeniy Paltsev wrote: > 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. My understanding is better to leave to show that the new option has been introduced. It would be possible to do when you confirm that your ARC platform along with SPEAr supports auto configuration including this property. -- Andy Shevchenko Intel Finland Oy