From: Lucas Stach <l.stach@pengutronix.de>
To: "Schrempf Frieder" <frieder.schrempf@kontron.de>,
"Guido Günther" <agx@sigxcpu.org>,
"Chris Healy" <cphealy@gmail.com>,
"etnaviv@lists.freedesktop.org" <etnaviv@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: Etnaviv issues on i.MX8M-Mini
Date: Wed, 26 Feb 2020 16:54:35 +0100 [thread overview]
Message-ID: <8234253d725e665a4ef0f231c587e32cd4261a55.camel@pengutronix.de> (raw)
In-Reply-To: <47cc398f-565a-5725-eb93-66870dfbdc0c@kontron.de>
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
next prev parent reply other threads:[~2020-02-26 15:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2704d3bd-5563-8951-58f7-75a906782754@kontron.de>
[not found] ` <CAFXsbZp9kW555gm+8Cz+oQVRNSzVzzQO2rM5YqzitCd6T7KN6Q@mail.gmail.com>
[not found] ` <bcc3af77-07c5-fbc7-ad20-d070c5ab1ce8@kontron.de>
[not found] ` <CAFXsbZqNQMi+-tPE22oMTHqb+8vEOy+v8cLfUMmhqs7S5RLoqg@mail.gmail.com>
[not found] ` <d1c98cb7-c75f-d8ca-9541-3c118d371a57@kontron.de>
[not found] ` <38c7cdc27213697b50517ce103a9d38120f84bd3.camel@pengutronix.de>
[not found] ` <f3a0bd17-83f5-4afa-e9a6-3eac411d34ff@kontron.de>
[not found] ` <ca594143751e94a2cf519e03915faa23a91c2836.camel@pengutronix.de>
[not found] ` <41b4070d-8db8-112c-6c57-f50af00b1604@kontron.de>
2020-02-26 15:31 ` Etnaviv issues on i.MX8M-Mini Schrempf Frieder
2020-02-26 15:54 ` Lucas Stach [this message]
2020-02-26 16:05 ` Guido Günther
2020-03-02 8:45 ` Schrempf Frieder
2020-03-03 11:43 ` Schrempf Frieder
2020-03-03 15:59 ` Guido Günther
2020-03-03 16:27 ` Schrempf Frieder
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=8234253d725e665a4ef0f231c587e32cd4261a55.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=agx@sigxcpu.org \
--cc=cphealy@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=frieder.schrempf@kontron.de \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).