linux-kernel - Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160628041441.GQ22564@localhost>
Date:	Tue, 28 Jun 2016 09:44:41 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@...inx.com>
Cc:	Appana Durga Kedareswara Rao <appanad@...inx.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	Michal Simek <michals@...inx.com>,
	Soren Brinkmann <sorenb@...inx.com>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"moritz.fischer@...us.com" <moritz.fischer@...us.com>,
	"laurent.pinchart@...asonboard.com" 
	<laurent.pinchart@...asonboard.com>,
	"luis@...ethencourt.com" <luis@...ethencourt.com>,
	Srikanth Vemula <svemula@...inx.com>,
	Anirudha Sarangi <anirudh@...inx.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>
Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver
 support

On Tue, Jun 21, 2016 at 05:29:42PM +0000, Punnaiah Choudary Kalluri wrote:
> 
> Ok agree with you for the scenario that I have mentioned above.
> 
> Other simple dma mode feature that I missed to explain is configuring the 
> Dma descriptors. It provides a register interface for configuring the dma transaction.
> So, no need to maintain the descriptors in memory and it will be useful for the system 
> that are in crunch of memory.  

And why are these not coming out in the first place, which makes me think it
is fishy!

Do you mean programming DMA descriptors to hardware and you can use
registers instead of memory?

> 
> How do you want us to handle this case?
> 

> > Okay I am convince now this is not right approach. Please remove this
> > custom interface and then implement slave for required slave scenarios!
> >
> 
> Assume controller is having 8 channels and four of them are used for slave
> Dma and others are for memcpy.
> Controller didn't have the per channel priority control but providing the rate control
> Mechanism. 

How does the use of few for memcpy and few for slave change things? IMO it
doesn't, you program the channel accordingly

> 
> So, I need some interface for configuring the rate control per channel at run time irrespective
> Of whether the channel is allocated for slave dma or memcpy dma.

why?

> Is it wrong having the configurable dma parameters for dma memcpy operation? We are exposing the
> Hw capabilities to the user for better dma transaction management.

For memcpy yes. Memcpy is a generic case where people do not do driver
specific stuff. So I tend ot push back on that..

For slave, existing APIs allow you to program the additional parameters..
FWIW, rate control is a generic parameter which if you justify enough can be
added to dma_slave_config

Thanks
-- 
~Vinod