linux-kernel - Re: [RFC] drm: bridge: samsung-dsim: Recalculate timings when rounding HFP up

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] [day] [month] [year] [list]

Date:   Thu, 26 Oct 2023 13:23:51 -0500
From:   Adam Ford <aford173@...il.com>
To:     Frieder Schrempf <frieder.schrempf@...tron.de>
Cc:     dri-devel@...ts.freedesktop.org, marex@...x.de,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Robert Foss <rfoss@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jonas Karlman <jonas@...boo.se>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        aford@...conembedded.com,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Maxime Ripard <mripard@...nel.org>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        linux-kernel@...r.kernel.org,
        Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [RFC] drm: bridge: samsung-dsim: Recalculate timings when
 rounding HFP up

On Thu, Oct 26, 2023 at 1:12 PM Frieder Schrempf
<frieder.schrempf@...tron.de> wrote:
>
> Hi Adam,
>
> On 13.10.23 05:10, Adam Ford wrote:
> > When using video sync pulses, the HFP, HBP, and HSA are divided between
> > the available lanes if there is more than one lane.  For certain
> > timings and lane configurations, the HFP may not be evenly divisible
> > and it gets rounded down which can cause certain resolutions and
> > refresh rates to not sync.
> >
> > ie. 720p60 on some monitors show hss of 1390 and hdisplay of 1280.  This
> > yields an HFP of 110. When taking the HFP of 110 divides along 4 lanes,
> > the result is 27.5 which rounds down to 27 and causes some monitors not
> > to sync.
> >
> > The solultion is to round HFP up by finding the remainder of HFP /
> > the number of lanes and increasing the hsync_start, hsync_end, and
> > htotal to compensate when there is a remainder.
> >
> > Signed-off-by: Adam Ford <aford173@...il.com>
> > ---
> > This adds support for 720p60 in the i.MX8M Plus.
> >
> > NXP uses a look-up table in their downstream code to accomplish this.
> > Using this calculation, the driver can adjust without the need for a
> > complicated table and should be flexible for different timings and
> > resolutions depending on the monitor.
> >
> > I don't have a DSI analyzer, and this appears to only work on
> > i.MX8M Plus but not Mini and Nano for some reason, despite their
> > having a similar DSI bridge.
>
> I just want to report that I have tested this patch (on top of current
> linux-next) on our Kontron BL i.MX8MM board with the ADV7535 bridge and
> I don't see any change when trying the 30 different modes the monitor
> reports as supported. 18 of those work and 12 don't work.

Thanks for testing this.   I didn't see any regressions on my Mini or
Nano either, but I did see the 720p60 now works on i.MX8M Plus (but
not on Mini/Nano).  I am not sure why, and I don't have a DSI
analyzer.

>
> So at least there is no negative impact in this case.

At least nothing broke.  :-)

>
> Tested-by: Frieder Schrempf <frieder.schrempf@...tron.de> # Kontron BL
> i.MX8MM with HDMI monitor

I'll add your T-b when I post it again.
>
> Thanks
> Frieder