linux-kernel - Re: [RFC] dmaengine: add new api for preparing simple slave transfer

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: <20110610104318.GC24636@n2100.arm.linux.org.uk>
Date:	Fri, 10 Jun 2011 11:43:18 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	"Raju, Sundaram" <sundaram@...com>
Cc:	"Koul, Vinod" <vinod.koul@...el.com>,
	Dan <dan.j.williams@...el.com>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] dmaengine: add new api for preparing simple slave
	transfer

On Fri, Jun 10, 2011 at 03:51:41PM +0530, Raju, Sundaram wrote:
> Consider a simple video use case of de-interlacing a video buffer.
> Odd lines have to be transferred first, and then the even lines are 
> transferred separately. This can be done by programming the 
> inter frame gap as the line size of the video buffer in the DMAC.
> This will require you to have only 2 descriptors, one for the
> odd lines and another for the even lines. This results in only
> 2 descriptors being written to DMAC registers.

How would this be handled with DMACs which can't 'skip' bytes in the
buffer?  You would have to generate a list of LLIs separately
describing each 'line' of video and chain them together.

How do you handle the situation where a driver uses your new proposed
API, but it doesn't support that in hardware.

> Actually we can deduce the chunk_size from the 
> dma_slave_config itself. It is either the src_addr_width or
> dst_addr_width based on the direction. Because at a stretch
> DMAC cannot transfer more than the slave register width.

I think you're misinterpreting those fields.  (dst|src)_addr_width tells
the DMA controller the width of each transaction - whether to issue a
byte, half-word, word or double-word read or write to the peripheral.
It doesn't say how many of those to issue, it just says what the
peripheral access size is to be.

In other words, they describe the width of the FIFO register.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/