[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHCN7xKhbvaVnz1FFc_GX1xFN25ctS2aRDs0ZwY0MazqVgjxFA@mail.gmail.com>
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
Powered by blists - more mailing lists