linux-kernel - Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

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: <5720B333.4000804@metafoo.de>
Date:	Wed, 27 Apr 2016 14:40:19 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Appana Durga Kedareswara Rao <appana.durga.rao@...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>,
	"vinod.koul@...el.com" <vinod.koul@...el.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>,
	Anirudha Sarangi <anirudh@...inx.com>,
	Punnaiah Choudary Kalluri <punnaia@...inx.com>
Cc:	"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 v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
 device tree binding documentation

On 04/27/2016 09:33 AM, Appana Durga Kedareswara Rao wrote:
> Hi Lars,
> 
>> -----Original Message-----
>> From: Lars-Peter Clausen [mailto:lars@...afoo.de]
>> Sent: Wednesday, April 27, 2016 12:42 PM
>> To: Appana Durga Kedareswara Rao <appanad@...inx.com>;
>> robh+dt@...nel.org; pawel.moll@....com; mark.rutland@....com;
>> ijc+devicetree@...lion.org.uk; galak@...eaurora.org; Michal Simek
>> <michals@...inx.com>; Soren Brinkmann <sorenb@...inx.com>;
>> vinod.koul@...el.com; dan.j.williams@...el.com; Appana Durga Kedareswara
>> Rao <appanad@...inx.com>; moritz.fischer@...us.com;
>> laurent.pinchart@...asonboard.com; luis@...ethencourt.com; Anirudha
>> Sarangi <anirudh@...inx.com>; Punnaiah Choudary Kalluri
>> <punnaia@...inx.com>
>> Cc: devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-
>> kernel@...r.kernel.org; dmaengine@...r.kernel.org
>> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
>> device tree binding documentation
>>
>> On 04/27/2016 09:05 AM, Kedareswara rao Appana wrote:
>> [...]
>>> +- xlnx,include-sg	: Indicates the controller to operate in simple or
>>> +			  scatter gather dma mode
>>> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
>>> +			  source AXI transaction
>>> +- xlnx,overfetch	: Tells whether the channel is allowed to over
>>> +			  fetch the data
>>> +- xlnx,src-issue	: Number of AXI outstanding transactions on source
>> side
>>> +- xlnx,src-burst-len	: AXI length for data read. Support only power of
>>> +			  2 byte values.
>>> +- xlnx,dst-burst-len	: AXI length for data write. Support only power of
>>
>> These are all software runtime configuration parameters that you'd want to
>> change at runtime depending on which peripheral you are targeting with a
>> specific DMA transfer. These really do not belong into the devicetree.
> 
> You mean to have a separate config structure in the driver and handle the above parameters
> Through that structure???
> 
> I understand that above will work for slave dma transfer types what about memory to memory
> Transfers where we don't have provision to the use this parameters...

These parameters are just as application specific as e.g. the DMA
source/destination address or the DMA transfer length. If you want to use
the DMA controller in a different configuration you'd have to re-compile the
DTB and reboot your board, that is not really practical. Especially
considering that you'd typically have multiple applications using the DMA
controller in different configurations concurrently. In general if I have to
reconfigure the DT depending on what application software is running
something is fundamentally broken.

Derive these parameters at runtime depending on the requested transfer. E.g.
some transfer types only work in SG mode, others only work in non-SG modes.
For those which can work in both modes choose the one that is more
efficient. Similar for the other parameters.

- Lars