Re: Etnaviv issues on i.MX8M-Mini

[Schrempf Frieder <frieder.schrempf@kontron.de>]

On 02.03.20 09:44, Frieder Schrempf wrote:
> 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.

Sorry to bother you with one more question from a DRM newbie.

I'm currently looking at Guido's code for the NWL DSI bridge and trying 
to convert the NXP SEC DSIM host driver to a bridge driver.

The NWL driver uses mipi_dsi_host_register(), which searches for a 
output (panel) child node under the DSI bridge's node [1] as described 
in the bindings example [2].

How is this supposed to work in a setup with another bridge after the 
DSI bridge, where that bridge is not a child node of the DSI bridge, but 
only connected via the DSI bridges output port? For example I have a 
DSI->LVDS bridge, that is attached to an I2C port.

[1] 
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_mipi_dsi.c#L284

[2] 
https://source.puri.sm/guido.gunther/linux-imx8/blob/forward-upstream/next-20200226/mxsfb+nwl/v9-wip/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml#L173

Thanks,
Frieder
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel