diff for duplicates of <20180528180914.4d70af2a@bbrezillon> diff --git a/a/1.txt b/N1/1.txt index b11036a..0c346fd 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -161,7 +161,7 @@ Peter Rosin <peda@axentia.se> wrote: > a pain these days). > > The panels we are using only supports one resolution (each), but the issue -> is there with both 1920x1080@16bpp and 1024x768@8bpp (~60Hz). +> is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz). Duh! This adds to the weirdness of this issue. I'd thought that by dividing the required bandwidth by 2 you would get a reliable setup. @@ -171,7 +171,7 @@ dividing the required bandwidth by 2 you would get a reliable setup. > > block and compared it to the max (LP)DDR bandwidth? > > I did, but don't remember the exact details. There is some room even for -> 1920x1080@16bpp, but not oceans of it. We were a bit uncertain if 16bpp +> 1920x1080 at 16bpp, but not oceans of it. We were a bit uncertain if 16bpp > would be possible, and in fact that was the reason I worked on CLUT > support for atmel-hlcdc last year. But since the problem persists with > much less memory pressure as well, I don't think that's it either. diff --git a/a/content_digest b/N1/content_digest index 4d2b8fd..0fb5931 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,24 +17,10 @@ "ref\0c3cc1894-2d7d-93b6-a9de-ed9ca4564ae9@axentia.se\0" "ref\020180528162718.6be7191f@bbrezillon\0" "ref\0db31aac0-6b59-8835-2181-635670e7f176@axentia.se\0" - "From\0Boris Brezillon <boris.brezillon@bootlin.com>\0" - "Subject\0Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma\0" + "From\0boris.brezillon@bootlin.com (Boris Brezillon)\0" + "Subject\0[PATCH] mtd: nand: raw: atmel: add module param to avoid using dma\0" "Date\0Mon, 28 May 2018 18:09:14 +0200\0" - "To\0Peter Rosin <peda@axentia.se>\0" - "Cc\0Tudor Ambarus <tudor.ambarus@microchip.com>" - Nicolas Ferre <nicolas.ferre@microchip.com> - Ludovic Desroches <ludovic.desroches@microchip.com> - 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 - 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>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Mon, 28 May 2018 17:52:53 +0200\n" @@ -200,7 +186,7 @@ "> a pain these days).\n" "> \n" "> The panels we are using only supports one resolution (each), but the issue\n" - "> is there with both 1920x1080@16bpp and 1024x768@8bpp (~60Hz).\n" + "> is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz).\n" "\n" "Duh! This adds to the weirdness of this issue. I'd thought that by\n" "dividing the required bandwidth by 2 you would get a reliable setup.\n" @@ -210,7 +196,7 @@ "> > block and compared it to the max (LP)DDR bandwidth? \n" "> \n" "> I did, but don't remember the exact details. There is some room even for\n" - "> 1920x1080@16bpp, but not oceans of it. We were a bit uncertain if 16bpp\n" + "> 1920x1080 at 16bpp, but not oceans of it. We were a bit uncertain if 16bpp\n" "> would be possible, and in fact that was the reason I worked on CLUT\n" "> support for atmel-hlcdc last year. But since the problem persists with\n" "> much less memory pressure as well, I don't think that's it either.\n" @@ -223,4 +209,4 @@ "understand the root cause of this problem. Tudor, any idea why the\n" various stuff Peter tried did not work? -0e666c77872fa8f0a0457550c7bfa00fb453a2edf8d7627355f4fd3cca69461e +acadc5da8395c537b4d011a46a8d456b5bf4acf31c5f7849ffd4b59c3451857f
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.