From: Peter Rosin <peda@axentia.se> To: Tudor Ambarus <tudor.ambarus@microchip.com>, Nicolas Ferre <nicolas.ferre@microchip.com>, Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>, Marek Vasut <marek.vasut@gmail.com>, Josh Wu <rainyfeeling@outlook.com>, Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>, linux-kernel@vger.kernel.org, Boris Brezillon <boris.brezillon@bootlin.com>, linux-mtd@lists.infradead.org, Richard Weinberger <richard@nod.at>, Brian Norris <computersforpeace@gmail.com>, David Woodhouse <dwmw2@infradead.org>, linux-arm-kernel@lists.infradead.org, Eugen Hristev <eugen.hristev@microchip.com> Subject: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma Date: Sat, 26 May 2018 19:40:42 +0200 [thread overview] Message-ID: <d930349b-ed0a-507a-6ba6-00925f0a4136@axentia.se> (raw) In-Reply-To: <a25ca617-d3da-d401-1ba9-8e5887f8a8e5@microchip.com> On 2018-05-25 16:51, Tudor Ambarus wrote: > Hi, Peter, > > On 04/11/2018 06:34 PM, Nicolas Ferre wrote: >> I'll try to move forward with your detailed explanation and with my >> contacts within the "product" team internally. > > We have talked with the hardware team, looks like there is an error in > the description of the Master to Slave Access matrix. CPU accesses DDR2 > port0 through AXI matrix and not AHB. There is no conflict between CPU > and LCDC DMA when accessing DDR2 ports. This explains why using CPU > helps. > > The slave numbers from "Table 14-3 Master to Slave Access" are wrong. > The 7th row should be removed and all the other rows from below it, > shifted up with one level (DDR2 Port 1 is Slave no 7, DDR2 port 2 is > Slave no 8, ... , APB1 is slave no 11). Yes, the fact that row 7 (the 8th row, since there is a row 0, but I get what you mean) should be removed was pretty much what I had guessed. But what about the other strange things I found? To reiterate, this is my PRxSy register content (zeroes shown as -): PRxS0 33--3--3--3333-- PRxS1 33--3--3--3333-- PRxS2 33-------------- PRxS3 -3--------333--- PRxS4 33-------------- PRxS5 3--------------- PRxS6 33--33-33333333- PRxS7 --3-3--3-------- PRxS8 -3---3--3--3---- PRxS9 --3-3--3-33-333- PRxS10 3--3------------ PRxS11 3-----3--------- PRxS12 ---------------- PRxS13 ---------------- PRxS14 ---------------- PRxS15 ---------------- So, PRxS7 matches row 8 (DDR2 port 1) in the datasheet. And PRxS8 matches row 9 (DDR2 port 2) in the datasheet. But PRxS9 is not matching row 10 (DDR2 port 3)! And PRxS10-11 match rows 11-12 (APB 0-1) in the datasheet. But also look at PRxS3 (Internal ROM), there's a missing 3 in the first slot (A5)! Maybe the priority of that one can't be changed for some fundamental reason? But there is no hint to that effect in the datasheet AFAICT... > 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). I think I tried to arrange for that last time around. Not sure though, so I will try again next week... > Also, some information about your configuration is useful. Can you > please tell us what NAND DMA configuration did you use? Are you using > NAND storage for the videos that you are playing on the LCD screen? Not sure what level of detail you are after? We use W949D2CBJX5E LPDDR1 memories from Winbond. Years ago, I wrote some LPDDR1 patches for at91bootstrap to driver/ddramc.c (which predate the current upstream support) and to board/sama5d3xek/sama5d3xek.c (which doesn't to this day support LPDDR1 upstream, but I guess it shouldn't and that we should have a board of our own, so that part isn't really clean and also the reason I never upstreamed it). Anyway, some other trivial glue was also needed, but the meat are in those files. I just had a brief look at the LPDDR1 support in the upstream ddramc.c file and our code is very similar. But I did notice some differences and I will look into if that difference is something that matters. I can show provide patches if you think they are relevant? We use this in the sam-ba .qml file when we flash the devices with sam-ba and the nandflash applet (don't know if it's relevant, but it shows that we have a 16-bit bus): device: SAMA5D3 { name: "sama5d3-linea" aliases: [] description: "SAMA5D3 Linea" config { nandflash { ioset: 1 busWidth: 16 header: 0xc0902405 } } } *time passes* Oh dear ... you said NAND *DMA* configuration. Nothing special that I know of. So, the default? Anything specific I should check? Further, we are not playing any video. The artifacts are visible on a static screen on an otherwise "idle" system (i.e. just showing whatever on the screen and accessing the DRAM with DMA is enough to trigger the visual glitches). Cheers, Peter
WARNING: multiple messages have this Message-ID (diff)
From: peda@axentia.se (Peter Rosin) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma Date: Sat, 26 May 2018 19:40:42 +0200 [thread overview] Message-ID: <d930349b-ed0a-507a-6ba6-00925f0a4136@axentia.se> (raw) In-Reply-To: <a25ca617-d3da-d401-1ba9-8e5887f8a8e5@microchip.com> On 2018-05-25 16:51, Tudor Ambarus wrote: > Hi, Peter, > > On 04/11/2018 06:34 PM, Nicolas Ferre wrote: >> I'll try to move forward with your detailed explanation and with my >> contacts within the "product" team internally. > > We have talked with the hardware team, looks like there is an error in > the description of the Master to Slave Access matrix. CPU accesses DDR2 > port0 through AXI matrix and not AHB. There is no conflict between CPU > and LCDC DMA when accessing DDR2 ports. This explains why using CPU > helps. > > The slave numbers from "Table 14-3 Master to Slave Access" are wrong. > The 7th row should be removed and all the other rows from below it, > shifted up with one level (DDR2 Port 1 is Slave no 7, DDR2 port 2 is > Slave no 8, ... , APB1 is slave no 11). Yes, the fact that row 7 (the 8th row, since there is a row 0, but I get what you mean) should be removed was pretty much what I had guessed. But what about the other strange things I found? To reiterate, this is my PRxSy register content (zeroes shown as -): PRxS0 33--3--3--3333-- PRxS1 33--3--3--3333-- PRxS2 33-------------- PRxS3 -3--------333--- PRxS4 33-------------- PRxS5 3--------------- PRxS6 33--33-33333333- PRxS7 --3-3--3-------- PRxS8 -3---3--3--3---- PRxS9 --3-3--3-33-333- PRxS10 3--3------------ PRxS11 3-----3--------- PRxS12 ---------------- PRxS13 ---------------- PRxS14 ---------------- PRxS15 ---------------- So, PRxS7 matches row 8 (DDR2 port 1) in the datasheet. And PRxS8 matches row 9 (DDR2 port 2) in the datasheet. But PRxS9 is not matching row 10 (DDR2 port 3)! And PRxS10-11 match rows 11-12 (APB 0-1) in the datasheet. But also look at PRxS3 (Internal ROM), there's a missing 3 in the first slot (A5)! Maybe the priority of that one can't be changed for some fundamental reason? But there is no hint to that effect in the datasheet AFAICT... > 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). I think I tried to arrange for that last time around. Not sure though, so I will try again next week... > Also, some information about your configuration is useful. Can you > please tell us what NAND DMA configuration did you use? Are you using > NAND storage for the videos that you are playing on the LCD screen? Not sure what level of detail you are after? We use W949D2CBJX5E LPDDR1 memories from Winbond. Years ago, I wrote some LPDDR1 patches for at91bootstrap to driver/ddramc.c (which predate the current upstream support) and to board/sama5d3xek/sama5d3xek.c (which doesn't to this day support LPDDR1 upstream, but I guess it shouldn't and that we should have a board of our own, so that part isn't really clean and also the reason I never upstreamed it). Anyway, some other trivial glue was also needed, but the meat are in those files. I just had a brief look at the LPDDR1 support in the upstream ddramc.c file and our code is very similar. But I did notice some differences and I will look into if that difference is something that matters. I can show provide patches if you think they are relevant? We use this in the sam-ba .qml file when we flash the devices with sam-ba and the nandflash applet (don't know if it's relevant, but it shows that we have a 16-bit bus): device: SAMA5D3 { name: "sama5d3-linea" aliases: [] description: "SAMA5D3 Linea" config { nandflash { ioset: 1 busWidth: 16 header: 0xc0902405 } } } *time passes* Oh dear ... you said NAND *DMA* configuration. Nothing special that I know of. So, the default? Anything specific I should check? Further, we are not playing any video. The artifacts are visible on a static screen on an otherwise "idle" system (i.e. just showing whatever on the screen and accessing the DRAM with DMA is enough to trigger the visual glitches). Cheers, Peter
next prev parent reply other threads:[~2018-05-26 17:40 UTC|newest] Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-29 13:10 [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma Peter Rosin 2018-03-29 13:10 ` Peter Rosin 2018-03-29 13:33 ` Boris Brezillon 2018-03-29 13:33 ` Boris Brezillon 2018-03-29 13:37 ` Peter Rosin 2018-03-29 13:37 ` Peter Rosin 2018-03-29 13:44 ` Boris Brezillon 2018-03-29 13:44 ` Boris Brezillon 2018-03-29 14:27 ` Peter Rosin 2018-03-29 14:27 ` Peter Rosin 2018-03-30 21:43 ` Peter Rosin 2018-03-30 21:43 ` Peter Rosin 2018-04-02 12:22 ` Boris Brezillon 2018-04-02 12:22 ` Boris Brezillon 2018-04-02 17:59 ` Peter Rosin 2018-04-02 17:59 ` Peter Rosin 2018-04-02 19:28 ` Boris Brezillon 2018-04-02 19:28 ` Boris Brezillon 2018-04-02 20:20 ` Boris Brezillon 2018-04-02 20:20 ` Boris Brezillon 2018-04-02 20:32 ` Boris Brezillon 2018-04-02 20:32 ` Boris Brezillon 2018-04-03 6:11 ` Peter Rosin 2018-04-03 6:11 ` Peter Rosin 2018-04-03 7:18 ` Boris Brezillon 2018-04-03 7:18 ` Boris Brezillon 2018-04-11 14:44 ` Peter Rosin 2018-04-11 14:44 ` Peter Rosin 2018-04-11 14:59 ` Boris Brezillon 2018-04-11 14:59 ` Boris Brezillon 2018-04-11 15:10 ` Peter Rosin 2018-04-11 15:10 ` Peter Rosin 2018-04-11 15:34 ` Boris Brezillon 2018-04-11 15:34 ` Boris Brezillon 2018-04-11 15:34 ` Nicolas Ferre 2018-04-11 15:34 ` Nicolas Ferre 2018-04-12 7:18 ` Peter Rosin 2018-04-12 7:18 ` Peter Rosin 2018-05-22 18:03 ` Peter Rosin 2018-05-22 18:03 ` Peter Rosin 2018-05-23 10:42 ` Boris Brezillon 2018-05-23 10:42 ` Boris Brezillon 2018-05-25 14:51 ` Tudor Ambarus 2018-05-25 14:51 ` Tudor Ambarus 2018-05-26 17:40 ` Peter Rosin [this message] 2018-05-26 17:40 ` Peter Rosin 2018-05-27 9:18 ` Peter Rosin 2018-05-27 9:18 ` Peter Rosin 2018-05-27 22:11 ` Peter Rosin 2018-05-27 22:11 ` Peter Rosin 2018-05-28 10:10 ` Peter Rosin 2018-05-28 10:10 ` Peter Rosin 2018-05-28 14:27 ` Boris Brezillon 2018-05-28 14:27 ` Boris Brezillon 2018-05-28 15:52 ` Peter Rosin 2018-05-28 15:52 ` Peter Rosin 2018-05-28 16:09 ` Boris Brezillon 2018-05-28 16:09 ` Boris Brezillon 2018-05-28 16:09 ` Nicolas Ferre 2018-05-28 16:09 ` Nicolas Ferre 2018-05-29 6:30 ` Eugen Hristev 2018-05-29 6:30 ` Eugen Hristev 2018-05-29 7:10 ` Peter Rosin 2018-05-29 7:10 ` Peter Rosin 2018-05-29 7:25 ` Eugen Hristev 2018-05-29 7:25 ` Eugen Hristev 2018-05-29 14:49 ` Boris Brezillon 2018-05-29 14:49 ` Boris Brezillon 2018-05-29 15:01 ` Eugen Hristev 2018-05-29 15:01 ` Eugen Hristev 2018-05-29 15:15 ` Boris Brezillon 2018-05-29 15:15 ` Boris Brezillon 2018-05-29 15:21 ` Eugen Hristev 2018-05-29 15:21 ` Eugen Hristev 2018-05-29 15:46 ` Boris Brezillon 2018-05-29 15:46 ` Boris Brezillon 2018-05-29 17:57 ` Boris Brezillon 2018-05-29 17:57 ` Boris Brezillon 2018-05-29 21:37 ` Peter Rosin 2018-05-29 21:37 ` Peter Rosin 2018-06-04 15:46 ` Tudor Ambarus 2018-06-04 15:46 ` Tudor Ambarus 2018-06-04 16:03 ` Boris Brezillon 2018-06-04 16:03 ` Boris Brezillon 2022-06-16 15:54 ` SAMA5D3 Display FIFO underflow (Was: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma) Ahmad Fatoum 2022-07-25 14:17 ` Ahmad Fatoum 2022-07-28 8:03 ` Tudor.Ambarus 2018-04-03 6:51 ` [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma Peter Rosin 2018-04-03 6:51 ` Peter Rosin 2018-04-03 7:15 ` Boris Brezillon 2018-04-03 7:15 ` Boris Brezillon 2018-04-03 7:32 ` Boris Brezillon 2018-04-03 7:32 ` Boris Brezillon 2018-04-03 8:14 ` Peter Rosin 2018-04-03 8:14 ` Peter Rosin 2018-04-03 8:30 ` Boris Brezillon 2018-04-03 8:30 ` Boris Brezillon 2018-04-02 20:23 ` Peter Rosin 2018-04-02 20:23 ` Peter Rosin 2018-04-02 20:35 ` Boris Brezillon 2018-04-02 20:35 ` Boris Brezillon 2018-04-03 7:18 ` Alexandre Belloni 2018-04-03 7:18 ` Alexandre Belloni 2018-04-03 8:37 ` Peter Rosin 2018-04-03 8:37 ` Peter Rosin 2018-03-29 14:20 ` Nicolas Ferre 2018-03-29 14:20 ` Nicolas Ferre 2018-03-29 14:23 ` Peter Rosin 2018-03-29 14:23 ` Peter Rosin 2018-03-29 14:29 ` Boris Brezillon 2018-03-29 14:29 ` Boris Brezillon 2018-06-18 8:39 ` Boris Brezillon 2018-06-18 8:39 ` Boris Brezillon 2018-06-18 14:00 ` Miquel Raynal 2018-06-18 14:00 ` Miquel Raynal 2018-06-25 12:31 ` Miquel Raynal 2018-06-25 12:31 ` Miquel Raynal
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d930349b-ed0a-507a-6ba6-00925f0a4136@axentia.se \ --to=peda@axentia.se \ --cc=alexandre.belloni@bootlin.com \ --cc=boris.brezillon@bootlin.com \ --cc=computersforpeace@gmail.com \ --cc=cyrille.pitchen@wedev4u.fr \ --cc=dwmw2@infradead.org \ --cc=eugen.hristev@microchip.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=ludovic.desroches@microchip.com \ --cc=marek.vasut@gmail.com \ --cc=nicolas.ferre@microchip.com \ --cc=rainyfeeling@outlook.com \ --cc=richard@nod.at \ --cc=tudor.ambarus@microchip.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.