linux-kernel - Re: [PATCH 09/20] drm/bridge: tc358775: remove complex vsdelay calculation

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 for Android: free password hash cracker in your pocket

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

Message-Id: <D3Z9XTBHSUEN.2GW0UCIPLR6HY@kernel.org>
Date: Fri, 06 Sep 2024 16:34:23 +0200
From: "Michael Walle" <mwalle@...nel.org>
To: "Daniel Semkowicz" <dse@...umatec.com>
Cc: "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>, "Maarten
 Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard"
 <mripard@...nel.org>, "Thomas Zimmermann" <tzimmermann@...e.de>, "David
 Airlie" <airlied@...il.com>, "Daniel Vetter" <daniel@...ll.ch>, "Chun-Kuang
 Hu" <chunkuang.hu@...nel.org>, "Philipp Zabel" <p.zabel@...gutronix.de>,
 "Matthias Brugger" <matthias.bgg@...il.com>, "AngeloGioacchino Del Regno"
 <angelogioacchino.delregno@...labora.com>, "Sam Ravnborg"
 <sam@...nborg.org>, "Vinay Simha BN" <simhavcs@...il.com>, "Tony Lindgren"
 <tony@...mide.com>, <dri-devel@...ts.freedesktop.org>,
 <linux-kernel@...r.kernel.org>, <linux-mediatek@...ts.infradead.org>,
 <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 09/20] drm/bridge: tc358775: remove complex vsdelay
 calculation

Hi Daniel,

> > To cite the datasheet on VSDELAY:
> >   During DSI link speed is slower than that of LVDS link’s, data needs
> >   to be buffer within 775XBG before outputting to prevent data from
> >   underflow. Register field VPCTRL[VSDELAY] is used to for this purpose
> >
> > This driver assumes that the DSI link speed is the pixel clock (as does
> > every DSI bridge driver), after all the LVDS clock is derived from the
> > DSI clock. Thus we know for a fact, that the DSI link is not slower than
> > the LVDS side. Just use the (sane) default value of the bridge and drop
> > the complicated calculation here.
>
> I am not convinced this is a good idea to revert to a default
> VSdelay value. I tested your patch series with RK3399 platform
> and default value (5) was not enough there. There was small data
> underflow visible, resulting in display offset. Removing this patch
> and using the original calculation formula fixed the problem.
> The calculated VSDELAY value seems to be a lot bigger than required,
> but keeps us on the safe side.

Did you use just parts of this series or did you port the "lp11
notify" mechanism to the rk3399 platform? Please keep in mind, that
this bridge doesn't really work if the reset isn't deasserted during
lp-11 mode and lots of odd things happen.

Also, do you know if you have an EEPROM attached to the bridge or
does any firmware part initialize that bridge?

> It looks that hback-porch value for panel is used also on DSI link,
> effectively delaying hactive data delivered to TC358775 bridge.
> I suspect this causes the requirement for higher VSDELAY.

It was ages ago since I've worked on this bridge and extensively
tested and even measured and decoded the DSI link and the LVDS
stream. But IIRC this delay was only to compensate the difference
between the DSI clock and the LVDS clock, that is, if you push the
pixel stream slower into the bridge than the bridge is pushing it
out to the LVDS panel.

So the back porch should be irrelevant here (?!).

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)