linux-kernel - Re: [PATCH 0/5] drm/bridge: samsung-dsim: fix various modes with ADV7535 bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86fac1f0-0fcb-4cbd-a983-03a6e7c41097@kontron.de>
Date:   Wed, 6 Sep 2023 11:31:45 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Michael Tretter <m.tretter@...gutronix.de>,
        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>
Cc:     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

On 04.09.23 16:02, Frieder Schrempf wrote:
> Hi Michael,
> 
> 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.

Anyway it's better than not working at all.

> 
> For the whole series:
> 
> Tested-by: Frieder Schrempf <frieder.schrempf@...tron.de> # Kontron BL
> i.MX8MM + Waveshare 10.1inch HDMI LCD (E)
> 
> Thanks
> Frieder
> 
> [1] https://www.waveshare.com/10.1inch-hdmi-lcd-e.htm