Message-ID: <3230032b-5d8c-414b-b9c9-76dc1dc93d52@kontron.de>
Date:   Thu, 7 Sep 2023 10:20:06 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Michael Tretter <m.tretter@...gutronix.de>
Cc:     Inki Dae <inki.dae@...sung.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Robert Foss <rfoss@...nel.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>, kernel@...gutronix.de,
        Marco Felsch <m.felsch@...gutronix.de>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 0/5] drm/bridge: samsung-dsim: fix various modes with
 ADV7535 bridge

Hi Michael,

On 06.09.23 11:56, Michael Tretter wrote:
> Hi Frieder,
> 
> On Wed, 06 Sep 2023 11:31:45 +0200, Frieder Schrempf wrote:
>> On 04.09.23 16:02, Frieder Schrempf wrote:
>>> On 28.08.23 17:59, Michael Tretter wrote:
>>>> I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter,
>>>> which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few
>>>> modes were working, but in many modes my monitor stayed dark.
>>>>
>>>> This series fixes the Samsung DSIM bridge driver to bring up a few more
>>>> modes:
>>>>
>>>> The driver read the rate of the PLL ref clock only during probe.
>>>> However, if the clock is re-parented to the VIDEO_PLL, changes to the
>>>> pixel clock have an effect on the PLL ref clock. Therefore, the driver
>>>> must read and potentially update the PLL ref clock on every modeset.
>>>>
>>>> I also found that the rounding mode of the porches and active area has
>>>> an effect on the working modes. If the driver rounds up instead of
>>>> rounding down and be calculates them in Hz instead of kHz, more modes
>>>> start to work.
>>>>
>>>> The following table shows the modes that were working in my test without
>>>> this patch set and the modes that are working now:
>>>>
>>>> |            Mode | Before | Now |
>>>> | 1920x1080-60.00 | X      | X   |
>>>> | 1920x1080-59.94 |        | X   |
>>>> | 1920x1080-50.00 |        | X   |
>>>> | 1920x1080-30.00 |        | X   |
>>>> | 1920x1080-29.97 |        | X   |
>>>> | 1920x1080-25.00 |        | X   |
>>>> | 1920x1080-24.00 |        |     |
>>>> | 1920x1080-23.98 |        |     |
>>>> | 1680x1050-59.88 |        | X   |
>>>> | 1280x1024-75.03 | X      | X   |
>>>> | 1280x1024-60.02 | X      | X   |
>>>> |  1200x960-59.99 |        | X   |
>>>> |  1152x864-75.00 | X      | X   |
>>>> |  1280x720-60.00 |        |     |
>>>> |  1280x720-59.94 |        |     |
>>>> |  1280x720-50.00 |        | X   |
>>>> |  1024x768-75.03 |        | X   |
>>>> |  1024x768-60.00 |        | X   |
>>>> |   800x600-75.00 | X      | X   |
>>>> |   800x600-60.32 | X      | X   |
>>>> |   720x576-50.00 | X      | X   |
>>>> |   720x480-60.00 |        |     |
>>>> |   720x480-59.94 | X      |     |
>>>> |   640x480-75.00 | X      | X   |
>>>> |   640x480-60.00 |        | X   |
>>>> |   640x480-59.94 |        | X   |
>>>> |   720x400-70.08 |        |     |
>>>>
>>>> Interestingly, the 720x480-59.94 mode stopped working. However, I am
>>>> able to bring up the 720x480 modes by manually hacking the active area
>>>> (hsa) to 40 and carefully adjusting the clocks, but something still
>>>> seems to be off.
>>>>
>>>> Unfortunately, a few more modes are still not working at all. The NXP
>>>> downstream kernel has some quirks to handle some of the modes especially
>>>> wrt. to the porches, but I cannot figure out, what the driver should
>>>> actually do in these cases. Maybe there is still an error in the
>>>> calculation of the porches and someone at NXP can chime in.
>>>
>>> Thanks for working on this! We tested these patches with our Kontron BL
>>> i.MX8MM board and a "10.1inch HDMI LCD (E)" display from Waveshare  [1].
>>>
>>> Without this series we don't get an image with the default mode of the
>>> display (1024x600). With this series applied, it's now working.
>>
>> Minor correction: The display does work, but there is some flickering
>> and occasional black screens if you let it run for some time. So there
>> is still some sync issue.
> 
> What is the parent of the dsi_phy_ref clock in your test case?

It's the IMX8MM_CLK_24M default from imx8mm.dtsi.

> Make sure that
> the lcdif_pixel and dsi_phy_ref clocks are driven by the same PLL.
> 
> I saw occasional black screens, if the lcdif_pixel and dsi_phy_ref clock had
> different parents, and fixed it by changing the assigned-parent of
> IMX8MN_CLK_DSI_PHY_REF to IMX8MN_VIDEO_PLL1_OUT in the device tree. If the
> clocks are not in sync, it seems that the ADV3575 has issues correctly
> reconstructing the pixel clock and HDMI monitors loose sync.
> 
> This is something that must be configured in the board device tree, though.

Ok, I tried to set the parent of IMX8MM_CLK_DSI_PHY_REF to
IMX8MM_VIDEO_PLL1_OUT.

I also noticed, that I forgot to remove the samsung,pll-clock-frequency
from the mipi_dsi node in imx8mm.dtsi. This is necessary to make use of
your PLL input clock improvements. Otherwise I get 23.76 MHz for the
DSIM PLL input (derived from IMX8MM_VIDEO_PLL1_OUT) which results in a
HS clock of 300.96 MHz while the display requests 301.5 MHz (50.25 MHz
pixel clock). This is too low and the display doesn't work at all.

Unfortunately all of this doesn't result in a more stable image on the
10" Waveshare display. It seems like the display turns black whenever
the Qt app does a lot of framebuffer updates, e. g. during animations, etc.

Anyway, thanks for the help!

Best regards
Frieder

Powered by blists - more mailing lists