Re: Etnaviv issues on i.MX8M-Mini

Re: 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Etnaviv issues on i.MX8M-Mini

[Lucas Stach]

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

Re: Etnaviv issues on i.MX8M-Mini

[Guido Günther]

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.
Cheers,
 -- Guido
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Etnaviv issues on i.MX8M-Mini

[Schrempf Frieder]

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

Re: Etnaviv issues on i.MX8M-Mini

[Guido Günther]

Hi,
On Tue, Mar 03, 2020 at 11:43:14AM +0000, Schrempf Frieder wrote:
> 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.

You can also attach another bridge instead of a panel. NXPs BSP uses a
driver very similar to the nwl one above and this is how they attach a
DSI->HDMI bridge:

    https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mq-evk-lcdif-adv7535.dts?h=imx_5.4.0_8dxlphantom_er#n56

Cheers,
 -- Guido

> 
> [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

Re: Etnaviv issues on i.MX8M-Mini

[Schrempf Frieder]

On 03.03.20 16:59, Guido Günther wrote:
> Hi,
> On Tue, Mar 03, 2020 at 11:43:14AM +0000, Schrempf Frieder wrote:
>> 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.
> 
> You can also attach another bridge instead of a panel. NXPs BSP uses a
> driver very similar to the nwl one above and this is how they attach a
> DSI->HDMI bridge:
> 
>      https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mq-evk-lcdif-adv7535.dts?h=imx_5.4.0_8dxlphantom_er#n56

Ok, I understand how this is supposed to work, as here drm_bridge_add() 
is called from probe() in the NWL bridge driver. But in your NWL driver, 
drm_bridge_add() is called from nwl_dsi_host_attach() and I currently 
fail to understand how this is supposed to work.

But don't mind, I figured out that difference now and call 
drm_bridge_add() from probe() in my driver. There's still a lot of other 
things I need to understand and in fact I'm not even sure if I have 
enough time to immerse myself much deeper.

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