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