RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

From: Appana Durga Kedareswara Rao <appana.durga.rao@xilinx.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>,
	"pawel.moll@arm.com" <pawel.moll@arm.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	Michal Simek <michals@xilinx.com>,
	Soren Brinkmann <sorenb@xilinx.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"moritz.fischer@ettus.com" <moritz.fischer@ettus.com>,
	"laurent.pinchart@ideasonboard.com" 
	<laurent.pinchart@ideasonboard.com>,
	"luis@debethencourt.com" <luis@debethencourt.com>,
	Srikanth Vemula <svemula@xilinx.com>,
	Anirudha Sarangi <anirudh@xilinx.com>,
	"Punnaiah Choudary Kalluri" <punnaia@xilinx.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>
Subject: RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
Date: Tue, 14 Jun 2016 08:18:09 +0000	[thread overview]
Message-ID: <C246CAC1457055469EF09E3A7AC4E11A4A5B6441@XAP-PVEXMBX01.xlnx.xilinx.com> (raw)
In-Reply-To: <20160613055012.GC16910@localhost>

Hi Vinod,

	Thanks for the review...

> 
> 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?

End of descriptor...

> 
> > > > +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

You mean always keep the device in SG mode and provide an option 
For simple dma mode if user want to use simple DMA mode??

There are few features that are available in the simple DMA mode won't
Available in SG mode like write only DMA , read only DMA mode etc...

> 
> >
> > >
> > > > +	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?

When rate control is enabled, ZDMA channel uses the rate control count
To schedule successive data read transactions I mean kind of flow control to schedule 
Transactions at fixed intervals instead of pumping the transfers without delay or whenever bus is available

Rate control count register definition (11:0):
Scheduling interval for SRC AXI transaction, only used if rate control is enabled 

> 
> > src_issue:
> > Tells outstanding transaction on SRC.
> 
> This should be read only then, right?

It is a Read/Write register
http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html 
By default it is configured for Max transactions.
If user want to limit it they can limit it using this config option.

> 
> > 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?

Yes...

> 
> > >
> > > 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!

Default values means IP default state after reset.
If user not aware of the above parameters also still the driver will work for basic functionality.
Do you want me to implement one more API get_config so that 
Whenever user will call the get_config he will know the default values
Of the config parameters?

> 
> > 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

I am using customized dma test client.
There I am calling this set_config API before triggering memcpy/SG operations.

Regards,
Kedar.

> 
> --
> ~Vinod
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html