Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1563390ybj; Fri, 8 May 2020 04:25:48 -0700 (PDT) X-Google-Smtp-Source: APiQypJ1VyGPdbIaiAJ7L74+xqvVAH2uL/KOlaDfNhwNH+nLoLriW1VXlyC3MF3NFKWrLGQxjCLJ X-Received: by 2002:a17:906:dc02:: with SMTP id yy2mr1407664ejb.11.1588937148383; Fri, 08 May 2020 04:25:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588937148; cv=none; d=google.com; s=arc-20160816; b=tsUTVJBjrEdOav3jCFHJfWSBJ26toPB0fySy2pn2Nyin5luHFkshPkG9bxu1dhENFN 9+jfqi0ClvfL3y49aV+jx8dCUks7Kx/lf5J1sVd1af6ntk4ddf8zfwhTQzDOgX5GheHY oOQ+ZVoji3fqBhLgcmXWVYhWZzVVyFRGU8b/rOpIdJTmQRsGkxf727XJVf1ugsWRcU84 EbbebyDuibMpthxUYinduMptKnSHKcxik6dX7nUSb61HQ/3TNoe29jYq34HIP/mdoHcy kFYaCyAgqi3/caI08yYzSzd9a3neRQ1ejLFF0gB3SoSuYhHvP+f74eCQM8/OkawhfvTc 22Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=iaaPzxeX5jhtYVDUGGmHBazRrUEXY3V4+om1h3aLGfo=; b=RvR7egHBuSb8xgJzQcTEoRXw2O0LuIkIAvj8NPWEGp70crXK/FzCeUP4i3mOHa3dVn 7JfEzdjeiflCjroJPRg0MXtRAcK23b2AAHY59pehEIOhNIuKwYPmPdINqGR/RhYrq7LU 5ud4aOpnFzEArFPUp5CfaU3XWkHo0glQXYiNAuxlVxe8ixmCVf96PuTgaEcPtGN6w4xR WqZ3R3ioDbeHBzj06HU1kyHxy8AAJy8ZJMsm9+3XnF+mu1xnMgGve17LtzPnyiQ9EP/w K1Q7n8KA9tR3hlREad5+bG7JYDDdCzm8GMHSb6Ji7sGXsBo1lmGeLRENjZ96oj+bAiwN dGMw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bs10si833040edb.429.2020.05.08.04.25.24; Fri, 08 May 2020 04:25:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726908AbgEHLVz (ORCPT + 99 others); Fri, 8 May 2020 07:21:55 -0400 Received: from mga05.intel.com ([192.55.52.43]:64781 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726616AbgEHLVy (ORCPT ); Fri, 8 May 2020 07:21:54 -0400 IronPort-SDR: eZ8BD4v1hrMhJzG2YO3dTlTNvmoDzwvQB8tlU6Nw6bfc+dL+bYvhBY55u1oje5rFu4gZ1zQ09U +ZFh0ZxzWFmA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 May 2020 04:21:53 -0700 IronPort-SDR: AWn4JlKcN8+Kxi8TzKAw9JjRTfavnoOzEW0AiPwbQHRL5c+GX//59m/RxVdjoQmAf6vZ6Z3I1w haHJ31QpjNnA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,367,1583222400"; d="scan'208";a="462202399" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga005.fm.intel.com with ESMTP; 08 May 2020 04:21:49 -0700 Received: from andy by smile with local (Exim 4.93) (envelope-from ) id 1jX14i-005PEb-LK; Fri, 08 May 2020 14:21:52 +0300 Date: Fri, 8 May 2020 14:21:52 +0300 From: Andy Shevchenko To: Serge Semin , Vineet Gupta Cc: Vinod Koul , Viresh Kumar , Dan Williams , Serge Semin , Alexey Malahov , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , linux-mips@vger.kernel.org, devicetree@vger.kernel.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/6] dmaengine: dw: Set DMA device max segment size parameter Message-ID: <20200508112152.GI185537@smile.fi.intel.com> References: <20200306131048.ADBE18030797@mail.baikalelectronics.ru> <20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru> <20200508105304.14065-4-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200508105304.14065-4-Sergey.Semin@baikalelectronics.ru> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Cc (Vineet, for information you probably know) On Fri, May 08, 2020 at 01:53:01PM +0300, Serge Semin wrote: > Maximum block size DW DMAC configuration corresponds to the max segment > size DMA parameter in the DMA core subsystem notation. Lets set it with a > value specific to the probed DW DMA controller. It shall help the DMA > clients to create size-optimized SG-list items for the controller. This in > turn will cause less dw_desc allocations, less LLP reinitializations, > better DMA device performance. Thank you for the patch. My comments below. ... > + /* > + * Find maximum block size to be set as the DMA device maximum > + * segment size. By doing so we'll have size optimized SG-list > + * items for the channels with biggest block size. This won't > + * be a problem for the rest of the channels, since they will > + * still be able to split the requests up by allocating > + * multiple DW DMA LLP descriptors, which they would have done > + * anyway. > + */ > + if (dwc->block_size > block_size) > + block_size = dwc->block_size; > } > > /* Clear all interrupts on all channels. */ > @@ -1220,6 +1233,10 @@ int do_dma_probe(struct dw_dma_chip *chip) > BIT(DMA_MEM_TO_MEM); > dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST; > > + /* Block size corresponds to the maximum sg size */ > + dw->dma.dev->dma_parms = &dw->dma_parms; > + dma_set_max_seg_size(dw->dma.dev, block_size); > + > err = dma_async_device_register(&dw->dma); > if (err) > goto err_dma_register; Yeah, I have locally something like this and I didn't dare to upstream because there is an issue. We have this information per DMA controller, while we actually need this on per DMA channel basis. Above will work only for synthesized DMA with all channels having same block size. That's why above conditional is not needed anyway. OTOH, I never saw the DesignWare DMA to be synthesized differently (I remember that Intel Medfield has interesting settings, but I don't remember if DMA channels are different inside the same controller). Vineet, do you have any information that Synopsys customers synthesized DMA controllers with different channel characteristics inside one DMA IP? ... > #include > +#include Isn't enough to supply struct device; ? > #include > #include Also this change needs a separate patch I suppose. ... > - struct dma_device dma; > - char name[20]; > - void __iomem *regs; > - struct dma_pool *desc_pool; > - struct tasklet_struct tasklet; > + struct dma_device dma; > + struct device_dma_parameters dma_parms; > + char name[20]; > + void __iomem *regs; > + struct dma_pool *desc_pool; > + struct tasklet_struct tasklet; > > /* channels */ > - struct dw_dma_chan *chan; > - u8 all_chan_mask; > - u8 in_use; > + struct dw_dma_chan *chan; > + u8 all_chan_mask; > + u8 in_use; Please split formatting fixes into a separate patch. -- With Best Regards, Andy Shevchenko