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/driv...
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
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/driv...
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/nex...
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
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#n268this 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-wipThere'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
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/driv...
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/nex...
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....
[2] https://source.puri.sm/guido.gunther/linux-imx8/blob/forward-upstream/next-2...
Thanks, Frieder
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/driv...
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/nex...
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/dt...
Cheers, -- Guido
[1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_mipi_dsi....
[2] https://source.puri.sm/guido.gunther/linux-imx8/blob/forward-upstream/next-2...
Thanks, 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/driv...
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/nex...
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@lists.freedesktop.org
-
Guido Günther -
Lucas Stach -
Schrempf Frieder