From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933540AbcFMFnf (ORCPT ); Mon, 13 Jun 2016 01:43:35 -0400 Received: from mga14.intel.com ([192.55.52.115]:44018 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbcFMFnd (ORCPT ); Mon, 13 Jun 2016 01:43:33 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,465,1459839600"; d="scan'208";a="986167074" Date: Mon, 13 Jun 2016 11:20:12 +0530 From: Vinod Koul To: Appana Durga Kedareswara Rao Cc: "robh+dt@kernel.org" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , Michal Simek , Soren Brinkmann , "dan.j.williams@intel.com" , "moritz.fischer@ettus.com" , "laurent.pinchart@ideasonboard.com" , "luis@debethencourt.com" , Srikanth Vemula , Anirudha Sarangi , Punnaiah Choudary Kalluri , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support Message-ID: <20160613055012.GC16910@localhost> References: <1464765839-29018-1-git-send-email-appanad@xilinx.com> <1464765839-29018-2-git-send-email-appanad@xilinx.com> <20160607070841.GJ16910@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 08, 2016 at 07:40:52AM +0000, Appana Durga Kedareswara Rao wrote: > > > +static void zynqmp_dma_desc_config_eod(struct zynqmp_dma_chan *chan, > > > +void *desc) > > > > eod? 80 line? What's eod? > > > +int zynqmp_dma_channel_set_config(struct dma_chan *dchan, > > > + struct zynqmp_dma_config *cfg) > > > +{ > > > + struct zynqmp_dma_chan *chan = to_chan(dchan); > > > + > > > + chan->config.ovrfetch = cfg->ovrfetch; > > > + chan->config.has_sg = cfg->has_sg; > > > > is this HW capability? if so why would anyone not like to use it! > > Yes it is HW capability. It can be either in simple mode or SG mode > Earlier In the driver this configuration is read from the device-tree > But as per lars and your suggestion moved it as runtime config parameters. If sg mode is available why would anyone _not_ want it? I do not think there is point to have this > > > > > > + chan->config.ratectrl = cfg->ratectrl; > > > + chan->config.src_issue = cfg->src_issue; > > > + chan->config.src_burst_len = cfg->src_burst_len; > > > + chan->config.dst_burst_len = cfg->dst_burst_len; > > > > can you describe these parameters? > ratectl: > Rate control can be independently enabled per channel. When rate control is enabled, the > DMA channel uses the rate control count to schedule successive data read transactions. And how is this used by client? > src_issue: > Tells outstanding transaction on SRC. This should be read only then, right? > Burst_len: > Configures the burst length of the src and dst transfers... Hmmm, but you are on memcpy, so that should be programmed for throughput? > > > > How would a client know how to configure them? > > With the default values of the config parameters driver will work. But how will client know what is default! > If user has specific requirement to change these parameters they can pass > It to the driver using set_config API and all these parameters are > Documented in the include/linux/dma/xilinx_dma.h file... Can you give me an example where user would like to do that -- ~Vinod