From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4D746C43334 for ; Mon, 25 Jul 2022 14:19:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:Subject: From:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=88WIOKQRT8yio3iVXxXVz0yOjrLip+0boKvyRBbgULo=; b=xfmXKOHeUvPZaP B/0XqOYsLBcXpAqvORWH+ENGys20Kum2ssw4dUoo1sakkhM35kj4hcKZsixvcTIC+CqiPex/5qYzE ALc32lAZ3JUUJvhzQ4B5W/DAkLeKp7WmHq7cE2yWfp1P6rUJTHMGl4fO5wSVyRYHXSZKMWN0kggHQ h6ViM5D4u1B6/5qDkbA9Ro69Ht4eTD4VBMK4B1qpcqHXxe6QotqT7euPl5B29AMNeQzRv5JCkY0O1 tTEdnerQTz7PiFQtdTpOiHKuqgqmSUFjVwz8f/v1a99SFqHiCuflPL9aYDVLZrjhBEGa+FPU+ezjq 1pcn98E09N/eGiKszKLQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oFyuL-00BbqD-4E; Mon, 25 Jul 2022 14:18:05 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oFyuH-00BbnP-HG for linux-arm-kernel@lists.infradead.org; Mon, 25 Jul 2022 14:18:03 +0000 Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=[127.0.0.1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1oFyu2-0000fg-2q; Mon, 25 Jul 2022 16:17:46 +0200 Message-ID: <18679edd-17e5-1522-8cfa-59e33e44eca3@pengutronix.de> Date: Mon, 25 Jul 2022 16:17:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: Ahmad Fatoum Subject: Re: SAMA5D3 Display FIFO underflow (Was: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma) To: Peter Rosin , Tudor Ambarus , nicolas.ferre@microchip.com, boris.brezillon@collabora.com Cc: Alexandre Belloni , Ludovic Desroches , Pengutronix Kernel Team , "linux-arm-kernel@lists.infradead.org" , Claudiu Beznea , Philipp Zabel 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> <2c7059f9-13f2-1418-cc66-7a6ed111175f@pengutronix.de> Content-Language: en-US In-Reply-To: <2c7059f9-13f2-1418-cc66-7a6ed111175f@pengutronix.de> X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220725_071801_608653_1B895DA4 X-CRM114-Status: GOOD ( 33.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello everyone, On 16.06.22 17:54, Ahmad Fatoum wrote: > Hello Peter, > > Hardware has found its way to my desk that has the same issue > that you experienced. Disabling NAND DMA also fixed the display > FIFO underflow, but on another variant, it didn't help and we > need to dig deeper. Were there perhaps any new findings since > this thread concluded in 2018? We've since looked deeper into this and found that changing the AHB port of the LCDC worked around the issue. The other AHB port connects to a different DDR port and presumably the DDR port scheduling is less disadvantageous to the LCDC than the interconnect arbitration on the DDR port shared with the DMA controller used for NAND. > On 25.05.18 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. > > @Tudor, @Nicolas, Like Peter, I also have a lot of 3s (i.e. highest > priority for all DMA masters with access to a given slave) preset in > my matrix configuration. It seems not possible to change these priorities. I tested again and changing priorities was possible, just not for the first LCDC master. That one was at the lowest priority and the best one can do is decreasing other master priorities, but this did not resolve the issue. I also tried other things like breaking burst length and setting default master for the port, but nothing I configured in the MATRIX registers helped. > I have yet to try more of the suggestions in this thread. Has there been > a reply from your hardware team, if there are constraints regarding when > it's allowed to change MATRIX_PRBS9/10 on the SAMA5D3? While I have a workaround now, the proper way would still be configuring PRBS9. @Tudor, @Nicolas, do you know why changing the LCDC bit in that register is not possible on the SAMA5D3? I tried setting it prior to Linux boot (and LCDC enabling), but it did not help. Thanks, Ahmad > > Thanks in advance, > Ahmad > > >> >> 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). >> >> 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). >> >> 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? >> >> Thanks, >> ta > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel