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