linux-kernel - Re: [PATCH v3 0/2] dmaengine: core/omap-dma: Support for port window

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] [day] [month] [year] [list]

Date:   Wed, 30 Nov 2016 08:54:28 +0530
From:   Vinod Koul <vinod.koul@...el.com>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     dan.j.williams@...el.com, tony@...mide.com, linux@...linux.org.uk,
        dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-omap@...r.kernel.org, arnd@...db.de
Subject: Re: [PATCH v3 0/2] dmaengine: core/omap-dma: Support for port window

On Tue, Nov 29, 2016 at 04:23:40PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v2:
> - the src/dst_port_window_size is in words, not in bytes (comment updated)
> - correct the port_window based configuration in the omap-dma driver
> 
> Changes since v1:
> - Make sure that the one frame covers the port_window (burst = port_window)
> - added comment to explain the double indexed setup to cover the port_window
> - Simplifications for the code mentioned by Russell and Vinod
> 
> Cover letter from v1:
> 
> as I'm trying to convert the remaining OMAP driver to use DMAengine instead of
> the legacy omap-dma API I have encountered with the
> drivers/usb/musb/tusb6010_omap.c driver.
> 
> The TUSB6010 is connected via NOR FLASH interface and it's register space is
> mapped in the GPMC memory area. In OMAP SoCs we have support for external DMA
> request lines and the TUSB6010 is using those as well.
> 
> With asynchronous access the DMA needs to read/write within the FIFO 'window' in
> incremental address mode to read/write data.
> The constant addressing only works in synchronous mode.
> 
> Since the DMA is driven by external DMA requests, the asynchronous mode is also
> slave DMA operation, but currently the port window can not be 'swiped' as the
> DMAengine only supports single register/address on the slave side.
> 
> This series will add support in dma_slave_config to specify the port side window
> size and the second patch implements the setup needs in omap-dma driver for such
> a transfer.

Applied both, thanks

-- 
~Vinod