linux-kernel - Re: [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations

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: <f42a2a11c1a2df4d773b61a449e8f4d5a9a010d1.camel@pengutronix.de>
Date:   Thu, 20 Apr 2023 15:06:45 +0200
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Adam Ford <aford173@...il.com>
Cc:     dri-devel@...ts.freedesktop.org,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        aford@...conembedded.com,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Fabio Estevam <festevam@...il.com>, m.szyprowski@...sung.com,
        marex@...x.de, Robert Foss <rfoss@...nel.org>,
        David Airlie <airlied@...il.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        NXP Linux Team <linux-imx@....com>,
        devicetree@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>,
        Jonas Karlman <jonas@...boo.se>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Inki Dae <inki.dae@...sung.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-kernel@...r.kernel.org,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>
Subject: Re: [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane
 calculations

Hi Adam,

Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@...il.com> wrote:
> > 
> > On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@...gutronix.de> wrote:
> > > 
> > > Hi Adam,
> > > 
> > > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > > bytes/pixel, then they are divided amongst the different lanes with some
> > > > additional overhead. This is necessary to achieve higher resolutions while
> > > > keeping the pixel clocks lower as the number of lanes increase.
> > > > 
> > > 
> > > In the testing I did to come up with my patch "drm: bridge: samsung-
> > > dsim: fix blanking packet size calculation" the number of lanes didn't
> > > make any difference. My testing might be flawed, as I could only
> > > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > > interested to know what others did here. How did you validate the
> > > blanking with your patch? Would you have a chance to test my patch and
> > > see if it works or breaks in your setup?
> 
> Lucas,
> 
> I tried your patch instead of mine.  Yours is dependent on the
> hs_clock being always set to the burst clock which is configured by
> the device tree.  I unrolled a bit of my stuff and replaced it with
> yours.  It worked at 1080p, but when I tried a few other resolutions,
> they did not work.  I assume it's because the DSI clock is fixed and
> not changing based on the pixel clock.  In the version I did, I only
> did that math when the lanes were > 1. In your patch, you divide by 8,
> and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> that just in case the bpp ever changes from 8.  Overall,  I think our
> patches basically do the same thing.

The calculations in your and my patch are quite different. I'm not
taking into account the number of lanes or the MIPI format. I'm basing
the blanking size purely on the ratio between MIPI DSI byte clock and
the DPI interface clock. It's quite counter-intuitive that the host
would scale the blanking to the number of lanes automatically, but
still require the MIPI packet offset removed, but that's what my
measurements showed to produce the correct blanking after translation
to DPI by the TC358767 bridge chip.

If you dynamically scale the HS clock, then you would need to input the
real used HS clock to the calculation in my patch, instead of the fixed
burst mode rate.

Regards,
Lucas