Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma

From: Eugen Hristev
Date: Tue May 29 2018 - 03:27:32 EST




On 29.05.2018 10:10, Peter Rosin wrote:
On 2018-05-29 08:30, Eugen Hristev wrote:


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.

Got that, that was why I added the various additional traces in that
horrid patch in the mail you are responding to :-)

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.

Ahh, *that* NAND DMA configuration. Of course, how silly of me...

This is a setup based on the at91-linea.dtsi "CPU" board. That dtsi should
have the relevant NAND/DMA info. Also, at91-nattis-2-natte-2.dts describes
the older HW (with a 1024x768 panel) that is also affected, if you want a
full device tree to look at.

Looks like I didn't make a selection, quoting from at91-linea.dtsi:

Ok, so try to force the nand to use DDR port 1 : use DMAC0 or DMAC1 on the interfaces corresponding just to DDR port 1, and see if helps (while leaving HLCDC on both masters - DDR port 2 and 3).

One more thing: what are the actual nand commands which you use when you get the glitches? read/write/erase ... ?
What happens if you try to minimize the nand access? you also said at some point that only *some* nand accesses cause glitches.

Another thing : even if the LCD displays a still image, the DMA still feeds data to the LCD right ?


&ebi {
pinctrl-0 = <&pinctrl_ebi_nand_addr>;
pinctrl-names = "default";
status = "okay";
};

&nand_controller {
status = "okay";

nand: nand@3 {
reg = <0x3 0x0 0x2>;
atmel,rb = <0>;
nand-bus-width = <8>;
nand-ecc-mode = "hw";
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
nand-on-flash-bbt;
label = "atmel_nand";
};
};

The reason is probably because the sama5d3xek device-trees didn't at the
time of "fork". Does anybody have any suggestion for some extra properties
to try in the above nodes?

Further, I forgot that I had actually upstreamed linea support for
at91bootstrap, so relevant NAND timings etc can be found in lpddr1_init()
in

at91bootstrap/contrib/board/axentia/sama5d3_linea/sama5d3_linea.c

Cheers,
Peter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel