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]
Date:   Tue, 29 May 2018 09:30:54 +0300
From:   Eugen Hristev <eugen.hristev@...rochip.com>
To:     Peter Rosin <peda@...ntia.se>
CC:     Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Josh Wu <rainyfeeling@...look.com>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        <linux-kernel@...r.kernel.org>,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        <linux-mtd@...ts.infradead.org>,
        Richard Weinberger <richard@....at>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using
 dma



On 28.05.2018 13:10, Peter Rosin wrote:
> On 2018-05-28 00:11, Peter Rosin wrote:
>> On 2018-05-27 11:18, Peter Rosin wrote:
>>> On 2018-05-25 16:51, Tudor Ambarus wrote:
>>>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>>>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>>>> (7th slave).
>>>
>>> Exactly how do I accomplish that?
>>>
>>> I can see how I can move the LCD between slave DDR port 2 and 3 by
>>> selecting LCDC DMA master 8 or 9 (but according to the above it should
>>> not matter). The big question is how I control what slave the NAND flash
>>> is going to use? I find nothing in the datasheet, and the code is also
>>> non-transparent enough for me to figure it out by myself without
>>> throwing out this question first...

 >> [...]

>> and the output is
>>
>> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
>>
>> So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
>> or how to find out. I guess IF2 is not in use since that does not allow any
>> DDR2 port as slave...

Hello Peter,

Thank you for all the information, I will chip in to help a little bit.
The Master/channel is described in the device tree. The channel has a 
controller, a mem/periph interface and a periph ID, plus a FIFO 
configuration.

The dma chan number reported in the dmesg is just software. Here is an 
example from DT:
dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(1)>,
        <&dma0 2 AT91_DMA_CFG_PER_ID(2)>;

you can match this with the help from 
Documentation/devicetree/bindings/dma/atmel-dma.txt:

1. A phandle pointing to the DMA controller. 

2. The memory interface (16 most significant bits), the peripheral 
interface
(16 less significant bits). 

3. Parameters for the at91 DMA configuration register which are device 

dependent: 

   - bit 7-0: peripheral identifier for the hardware handshaking 
interface. The
   identifier can be different for tx and rx. 

   - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.


So , what was Tudor asking for, is your DT for the ebi node (if you are 
using ebi), or, your NFC SRAM (Nand Flash Controller SRAM) DMA 
devicetree chunk, so, we can figure out which type of DMA are you using.

Normally, the ebi should be connected to both DMA0 and DMA1 on those 
interfaces specified in DT. Which ones you want to use, depends on your 
setup (and contention on the bus/accesses, like in your case, the HLCDC)

Thats why we have multiple choices, to pick the right one for each case.
In our vanilla DT sama5d3.dtsi we do not have DMA described for ebi 
interface.

Eugen

 >> [...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ