[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180529195708.1fa41027@bbrezillon>
Date: Tue, 29 May 2018 19:57:08 +0200
From: Boris Brezillon <boris.brezillon@...tlin.com>
To: Eugen Hristev <eugen.hristev@...rochip.com>
Cc: Peter Rosin <peda@...ntia.se>,
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>, <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 Tue, 29 May 2018 17:46:21 +0200
Boris Brezillon <boris.brezillon@...tlin.com> wrote:
> On Tue, 29 May 2018 18:21:40 +0300
> Eugen Hristev <eugen.hristev@...rochip.com> wrote:
>
> > On 29.05.2018 18:15, Boris Brezillon wrote:
> > > On Tue, 29 May 2018 18:01:40 +0300
> > > Eugen Hristev <eugen.hristev@...rochip.com> wrote:
> > >
> > >> [...]
> > >>
> > >>
> > >>>
> > >>> I think you're missing something here. We use the DMA engine in memcpy
> > >>> mode (SRAM -> DRAM), not in device mode (dev -> DRAM or DRAM -> dev).
> > >>> So there's no dmas prop defined in the DT and there should not be.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Boris
> > >>>
> > >>
> > >> Ok, so the memcpy SRAM <-> DRAM will hog the transfer between DRAM and
> > >> LCD if my understanding is correct. That's the DMA that Peter wants to
> > >> disable with his patch ?
> > >>
> > >> Then we can then try to force NFC SRAM DMA channels to use just DDR port
> > >> 1 or 2 for memcpy ?
> > >
> > > You mean the dmaengine? According to "14.1.3 Master to Slave Access"
> > > that's already the case.
> > >
> > > Only DMAC0 can access the NFC SRAM and it's done through DMAC0:IF0,
> > > then access to DDR is going through port DDR port 1 (DMAC0:IF1) or 2
> > > (DMAC0:IF0).
> >
> > If we can make NFC use port 1 only, then HLCDC could have two ports as
> > master 8 & 9, maybe a better bandwidth.
>
> Peter, can you try with the following patch?
Actually that won't work because all SRAMs are on IF0, and here we use
DMA memcpy to copy things from/to the SRAM to/from the DRAM. I have no
simple solution to force usage of IF1 when accessing the DRAM but I'm
also not sure this will solve Peter's problem since forcing LCDC to use
DDR port 3 did not make things better.
>
> --->8---
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index ef3f227ce3e6..2a48e870f292 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -124,8 +124,8 @@
> #define ATC_SIF(i) (0x3 & (i)) /* Src tx done via AHB-Lite Interface i */
> #define ATC_DIF(i) ((0x3 & (i)) << 4) /* Dst tx done via AHB-Lite Interface i */
> /* Specify AHB interfaces */
> -#define AT_DMA_MEM_IF 0 /* interface 0 as memory interface */
> -#define AT_DMA_PER_IF 1 /* interface 1 as peripheral interface */
> +#define AT_DMA_MEM_IF 1 /* interface 0 as memory interface */
> +#define AT_DMA_PER_IF 0 /* interface 1 as peripheral interface */
>
> #define ATC_SRC_PIP (0x1 << 8) /* Source Picture-in-Picture enabled */
> #define ATC_DST_PIP (0x1 << 12) /* Destination Picture-in-Picture enabled */
Powered by blists - more mailing lists