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