Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
MIME-Version: 1.0
References: <20231013031040.152282-1-aford173@gmail.com> <7e16351f-4d70-4451-b3c7-1dadfa41f20b@kontron.de>
In-Reply-To: <7e16351f-4d70-4451-b3c7-1dadfa41f20b@kontron.de>
From:   Adam Ford <aford173@gmail.com>
Date:   Thu, 26 Oct 2023 13:23:51 -0500
Message-ID: <CAHCN7xKhbvaVnz1FFc_GX1xFN25ctS2aRDs0ZwY0MazqVgjxFA@mail.gmail.com>
Subject: Re: [RFC] drm: bridge: samsung-dsim: Recalculate timings when
 rounding HFP up
To:     Frieder Schrempf <frieder.schrempf@kontron.de>
Cc:     dri-devel@lists.freedesktop.org, marex@denx.de,
        Neil Armstrong <neil.armstrong@linaro.org>,
        Robert Foss <rfoss@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Jonas Karlman <jonas@kwiboo.se>,
        Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
        aford@beaconembedded.com,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Maxime Ripard <mripard@kernel.org>,
        Jagan Teki <jagan@amarulasolutions.com>,
        Andrzej Hajda <andrzej.hajda@intel.com>,
        linux-kernel@vger.kernel.org,
        Marek Szyprowski <m.szyprowski@samsung.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Oct 26, 2023 at 1:12=E2=80=AFPM Frieder Schrempf
<frieder.schrempf@kontron.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.  Thi=
s
> > 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@gmail.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@kontron.de> # Kontron BL
> i.MX8MM with HDMI monitor

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