Etnaviv issues on i.MX8M-Mini

[Schrempf Frieder]

On 26.02.20 17:05, Guido Günther wrote:
> On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote:
>> 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.
> 
> Newer mxsfb supports attaching a bridge so if you make your DSI host
> controller driver a DSI bridge mxsfb can drive it:
> 
>       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mxsfb/mxsfb_drv.c#n268
> 
> this should be similar to what was done for the imx8mq here (imx8mm
> users a different ip core though):
> 
>       https://source.puri.sm/guido.gunther/linux-imx8/commits/forward-upstream/next-20200217/mxsfb+nwl/v9-wip
> 
> There's also some additional mxsfb patches by Robert floating around
> which aren't mainline yet which the above branch also has.
> 
> Which reminds me that i need to prepare and send out a v9.

Thanks Lucas and Guido for pointing out the details!
It's very unfortunate that i.MX8MQ and i.MX8MM don't share the same DSI 
ip core.
It seems like I need to try coming up with a bridge driver for the 
Samsung DSIM DSI controller for a proper upstream solution.

Thanks,
Frieder