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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BF10C4BA12 for ; Wed, 26 Feb 2020 15:54:42 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 15E2721556 for ; Wed, 26 Feb 2020 15:54:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15E2721556 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 24DD66EAAF; Wed, 26 Feb 2020 15:54:41 +0000 (UTC) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6011B6E356 for ; Wed, 26 Feb 2020 15:54:39 +0000 (UTC) Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1j6z1A-00019b-7U; Wed, 26 Feb 2020 16:54:36 +0100 Message-ID: <8234253d725e665a4ef0f231c587e32cd4261a55.camel@pengutronix.de> Subject: Re: Etnaviv issues on i.MX8M-Mini From: Lucas Stach To: Schrempf Frieder , Guido =?ISO-8859-1?Q?G=FCnther?= , Chris Healy , "etnaviv@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" Date: Wed, 26 Feb 2020 16:54:35 +0100 In-Reply-To: <47cc398f-565a-5725-eb93-66870dfbdc0c@kontron.de> References: <2704d3bd-5563-8951-58f7-75a906782754@kontron.de> <38c7cdc27213697b50517ce103a9d38120f84bd3.camel@pengutronix.de> <41b4070d-8db8-112c-6c57-f50af00b1604@kontron.de> <47cc398f-565a-5725-eb93-66870dfbdc0c@kontron.de> User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: dri-devel@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mi, 2020-02-26 at 15:31 +0000, Schrempf Frieder wrote: > On 25.02.20 09:13, Frieder Schrempf wrote: > > Hi Lucas, > > > > On 24.02.20 12:08, Lucas Stach wrote: > > > On Mo, 2020-02-24 at 10:53 +0000, Schrempf Frieder wrote: > > > > Hi Lucas, > > > > > > > > On 24.02.20 11:37, Lucas Stach wrote: > > > > > Hi Frieder, > > > > > > > > > > On Mo, 2020-02-24 at 10:28 +0000, Schrempf Frieder wrote: > > > > > > On 20.02.20 19:58, Chris Healy wrote: > > > > > > > For the jerkey transitions, can you determine if this is a symptom of > > > > > > > a low framerate or dropped frames or something else? > > > > > > > > > > > > > > Perhaps you can start your app with > > > > > > > "GALLIUM_HUD=fps,cpu,draw-calls,frametime". This may give some > > > > > > > clues. > > > > > > > > > > > > The framerate seems ok. I get something between 50 and 70 FPS. > > > > > > > > > > > > I have a Qt demo app with a menu and an animated 'ball' that moves > > > > > > across the screen. When the menu is visible, the ball movement is > > > > > > really > > > > > > jerky (ball seems to 'jump back and forth' instead of moving > > > > > > linearly). > > > > > > > > > > > > As soon as I hide the menu and show the animation fullscreen, the > > > > > > movements are perfectly smooth. > > > > > > > > > > > > Running the same app with software rendering, everything looks > > > > > > good, too. > > > > > > > > > > > > No idea what that means, though. I probably need to look at the > > > > > > code of > > > > > > the app and do some more experiments to get a better idea of what > > > > > > might > > > > > > cause the distortion. > > > > > > > > > > > > Unless some of the graphics experts here already have an idea of what > > > > > > can cause and/or how to debug such an issue!? > > > > > > > > > > Which driver is used for the display side? It seems like the display > > > > > side doesn't properly handle the dma fences used to synchronize scanout > > > > > and rendering. > > > > > > > > I ported/picked the drivers for the LCDIF and DSI controllers from > > > > development branch of the 5.4-based vendor kernel [1] to our own > > > > v5.4-based kernel [2]. So it is quite probable, that something could be > > > > wrong here. > > > > > > Please just use DRM_MXSFB for the display side, instead of the > > > downstream driver. > > > > Hm, good idea. I somehow forgot about the fact, that there is an > > upstream driver for the LCDIF controller. On first try I couldn't get it > > to run on the i.MX8MM, but I suspect that's due to some reset, > > power-domain or clock setup, that is missing upstream. I will see if I > > can get any further with this. > > So I had a closer look and while the DRM_MXSFB looks ok on its own, I > have some problem with the rest of the i.MX8MM display subsystem. > > The vendor stack, that I'm currently using integrates into the imx-drm > master/core driver [1] that binds all the components of the display > subsystem, such as the LCDIF driver and the integrated SEC_DSIM DSI bridge. > > And because of my lack of DRM skills, I have no idea how to get the > DRM_MXSFB driver to bind to the imx-drm core, instead of running > separately and connecting directly to some panel as it is done for > i.MX23/28 and i.MX6SX/UL. It's a separate hardware and it's a pretty major design issue of the downstream driver that it integrates into imx-drm. You don't want this with the upstream driver. Maybe Guido (CCed) can give you some clues, as apparently he is using the mainline eLCDIF driver + some patches to drive the DSI display path on i.MX8MQ. A lot of this will probably be transferable to the i.MX8MM display path. Regards, Lucas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel