* Re: Etnaviv issues on i.MX8M-Mini [not found] ` <41b4070d-8db8-112c-6c57-f50af00b1604@kontron.de> @ 2020-02-26 15:31 ` Schrempf Frieder 2020-02-26 15:54 ` Lucas Stach 0 siblings, 1 reply; 7+ messages in thread From: Schrempf Frieder @ 2020-02-26 15:31 UTC (permalink / raw) To: Lucas Stach, Chris Healy, etnaviv, dri-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Etnaviv issues on i.MX8M-Mini 2020-02-26 15:31 ` Etnaviv issues on i.MX8M-Mini Schrempf Frieder @ 2020-02-26 15:54 ` Lucas Stach 2020-02-26 16:05 ` Guido Günther 0 siblings, 1 reply; 7+ messages in thread From: Lucas Stach @ 2020-02-26 15:54 UTC (permalink / raw) To: Schrempf Frieder, Guido Günther, Chris Healy, etnaviv, dri-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Etnaviv issues on i.MX8M-Mini 2020-02-26 15:54 ` Lucas Stach @ 2020-02-26 16:05 ` Guido Günther 2020-03-02 8:45 ` Schrempf Frieder 0 siblings, 1 reply; 7+ messages in thread From: Guido Günther @ 2020-02-26 16:05 UTC (permalink / raw) To: Lucas Stach; +Cc: dri-devel, Chris Healy, Schrempf Frieder, etnaviv 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Etnaviv issues on i.MX8M-Mini 2020-02-26 16:05 ` Guido Günther @ 2020-03-02 8:45 ` Schrempf Frieder 2020-03-03 11:43 ` Schrempf Frieder 0 siblings, 1 reply; 7+ messages in thread From: Schrempf Frieder @ 2020-03-02 8:45 UTC (permalink / raw) To: Guido Günther, Lucas Stach; +Cc: dri-devel, etnaviv, Chris Healy 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Etnaviv issues on i.MX8M-Mini 2020-03-02 8:45 ` Schrempf Frieder @ 2020-03-03 11:43 ` Schrempf Frieder 2020-03-03 15:59 ` Guido Günther 0 siblings, 1 reply; 7+ messages in thread From: Schrempf Frieder @ 2020-03-03 11:43 UTC (permalink / raw) To: Guido Günther, Lucas Stach; +Cc: dri-devel, etnaviv, Chris Healy 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Etnaviv issues on i.MX8M-Mini 2020-03-03 11:43 ` Schrempf Frieder @ 2020-03-03 15:59 ` Guido Günther 2020-03-03 16:27 ` Schrempf Frieder 0 siblings, 1 reply; 7+ messages in thread From: Guido Günther @ 2020-03-03 15:59 UTC (permalink / raw) To: Schrempf Frieder; +Cc: dri-devel, etnaviv, Chris Healy 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Etnaviv issues on i.MX8M-Mini 2020-03-03 15:59 ` Guido Günther @ 2020-03-03 16:27 ` Schrempf Frieder 0 siblings, 0 replies; 7+ messages in thread From: Schrempf Frieder @ 2020-03-03 16:27 UTC (permalink / raw) To: Guido Günther; +Cc: dri-devel, etnaviv, Chris Healy 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-03-04 7:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <2704d3bd-5563-8951-58f7-75a906782754@kontron.de> [not found] ` <CAFXsbZp9kW555gm+8Cz+oQVRNSzVzzQO2rM5YqzitCd6T7KN6Q@mail.gmail.com> [not found] ` <bcc3af77-07c5-fbc7-ad20-d070c5ab1ce8@kontron.de> [not found] ` <CAFXsbZqNQMi+-tPE22oMTHqb+8vEOy+v8cLfUMmhqs7S5RLoqg@mail.gmail.com> [not found] ` <d1c98cb7-c75f-d8ca-9541-3c118d371a57@kontron.de> [not found] ` <38c7cdc27213697b50517ce103a9d38120f84bd3.camel@pengutronix.de> [not found] ` <f3a0bd17-83f5-4afa-e9a6-3eac411d34ff@kontron.de> [not found] ` <ca594143751e94a2cf519e03915faa23a91c2836.camel@pengutronix.de> [not found] ` <41b4070d-8db8-112c-6c57-f50af00b1604@kontron.de> 2020-02-26 15:31 ` Etnaviv issues on i.MX8M-Mini Schrempf Frieder 2020-02-26 15:54 ` Lucas Stach 2020-02-26 16:05 ` Guido Günther 2020-03-02 8:45 ` Schrempf Frieder 2020-03-03 11:43 ` Schrempf Frieder 2020-03-03 15:59 ` Guido Günther 2020-03-03 16:27 ` Schrempf Frieder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).