Etnaviv issues on i.MX8M-Mini

[Schrempf Frieder]

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.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/imx/imx-drm-core.c