From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S939702AbeE1QLW (ORCPT ); Mon, 28 May 2018 12:11:22 -0400 Received: from esa4.microchip.iphmx.com ([68.232.154.123]:23103 "EHLO esa4.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933391AbeE1QLQ (ORCPT ); Mon, 28 May 2018 12:11:16 -0400 X-IronPort-AV: E=Sophos;i="5.49,453,1520924400"; d="scan'208";a="14412918" Subject: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma To: Peter Rosin , Boris Brezillon CC: Tudor Ambarus , Ludovic Desroches , Alexandre Belloni , Marek Vasut , Josh Wu , Cyrille Pitchen , , , Richard Weinberger , Brian Norris , David Woodhouse , , Eugen Hristev References: <20180329131054.22506-1-peda@axentia.se> <20180329153322.5e2fc1e7@bbrezillon> <20180329154416.5c1a0013@bbrezillon> <20180402142249.7e076a64@bbrezillon> <20180402212843.164d5d21@bbrezillon> <20180402222020.1d344c14@bbrezillon> <20180403091813.5fb5c18c@bbrezillon> <959d826d-1a98-ca22-acee-a4548427fcd3@microchip.com> <024079cb-77ad-9c48-e370-e6e8f2de171b@axentia.se> <9c496531-f7b6-4b9d-dd51-0bfb68ead303@axentia.se> <20180528162718.6be7191f@bbrezillon> From: Nicolas Ferre Organization: microchip Message-ID: <49ff8830-eb23-4ea8-0247-0f4fd783afb6@microchip.com> Date: Mon, 28 May 2018 18:09:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/05/2018 at 17:52, Peter Rosin wrote: > On 2018-05-28 16:27, Boris Brezillon wrote: [..] >> Could it just be that you're reaching the DDR bus limit. As I said >> previously, when you go through the CPU, and assuming you're consuming >> the data directly, you have: >> >> 1/ NFC SRAM -> CPU >> 2/ CPU -> L1 data cache --write-back--> DRAM >> 3/ L1-cache -> CPU >> >> While, if you use DMA you get: >> >> 1/ NFC SRAM -> DRAM >> 2/ SDRAM -> L1 data cache -> CPU >> >> So, if you're approaching the limit of (LP)DDR bandwidth, using the CPU >> might make things a bit better. Still, if the limitation really comes >> from the DDR bus, my opinion is that you should maybe use a smaller >> resolution or use a more compact pixel format (RGB565?). > > The issue is still there if I use a CLUT mode instead of rgb565, which is > what I normally use (and what I would like to use, CLUT is just alien and > 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). > >> Did you calculate how much of the bandwidth is taken by the HLCDC >> 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 > 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. Just jumping in the conversation with another perspective (maybe already tried actually). Can you try to make all that you can to maximize the blanking period of your screen (some are more tolerant than others according to that). By doing so, you would allow the LCD FIFO to recover better after each line. You might loose some columns on the side of your display but it would give us a good idea of how far we are from getting rid of those annoying LCD reset glitches (that are due to underruns on LCD FIFO). > Admittedly I have not tested these AHB matrix tricks with a smaller > panel (it would take a bit of work to arrange for those tests), but the > issue was there when I last tried (using defaults). If what I said earlier has an impact, reducing the panel size will also make a difference. But the question is how small is "smaller" ;-) Best regards, -- Nicolas Ferre From mboxrd@z Thu Jan 1 00:00:00 1970 From: nicolas.ferre@microchip.com (Nicolas Ferre) Date: Mon, 28 May 2018 18:09:15 +0200 Subject: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma In-Reply-To: References: <20180329131054.22506-1-peda@axentia.se> <20180329153322.5e2fc1e7@bbrezillon> <20180329154416.5c1a0013@bbrezillon> <20180402142249.7e076a64@bbrezillon> <20180402212843.164d5d21@bbrezillon> <20180402222020.1d344c14@bbrezillon> <20180403091813.5fb5c18c@bbrezillon> <959d826d-1a98-ca22-acee-a4548427fcd3@microchip.com> <024079cb-77ad-9c48-e370-e6e8f2de171b@axentia.se> <9c496531-f7b6-4b9d-dd51-0bfb68ead303@axentia.se> <20180528162718.6be7191f@bbrezillon> Message-ID: <49ff8830-eb23-4ea8-0247-0f4fd783afb6@microchip.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 28/05/2018 at 17:52, Peter Rosin wrote: > On 2018-05-28 16:27, Boris Brezillon wrote: [..] >> Could it just be that you're reaching the DDR bus limit. As I said >> previously, when you go through the CPU, and assuming you're consuming >> the data directly, you have: >> >> 1/ NFC SRAM -> CPU >> 2/ CPU -> L1 data cache --write-back--> DRAM >> 3/ L1-cache -> CPU >> >> While, if you use DMA you get: >> >> 1/ NFC SRAM -> DRAM >> 2/ SDRAM -> L1 data cache -> CPU >> >> So, if you're approaching the limit of (LP)DDR bandwidth, using the CPU >> might make things a bit better. Still, if the limitation really comes >> from the DDR bus, my opinion is that you should maybe use a smaller >> resolution or use a more compact pixel format (RGB565?). > > The issue is still there if I use a CLUT mode instead of rgb565, which is > what I normally use (and what I would like to use, CLUT is just alien and > a pain these days). > > The panels we are using only supports one resolution (each), but the issue > is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz). > >> Did you calculate how much of the bandwidth is taken by the HLCDC >> 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 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. Just jumping in the conversation with another perspective (maybe already tried actually). Can you try to make all that you can to maximize the blanking period of your screen (some are more tolerant than others according to that). By doing so, you would allow the LCD FIFO to recover better after each line. You might loose some columns on the side of your display but it would give us a good idea of how far we are from getting rid of those annoying LCD reset glitches (that are due to underruns on LCD FIFO). > Admittedly I have not tested these AHB matrix tricks with a smaller > panel (it would take a bit of work to arrange for those tests), but the > issue was there when I last tried (using defaults). If what I said earlier has an impact, reducing the panel size will also make a difference. But the question is how small is "smaller" ;-) Best regards, -- Nicolas Ferre