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: <CAHgnY3=KCD4gyJ4nL6nN1tvWcsiRQL+Oz11RNOniDdyMoEPcSg@mail.gmail.com>
Date: Fri, 6 Sep 2024 16:20:28 +0200
From: Daniel Semkowicz <dse@...umatec.com>
To: Michael Walle <mwalle@...nel.org>
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

Hello Michael,

On Mon, May 6, 2024 at 3:35 PM Michael Walle <mwalle@...nel.org> wrote:
>
> 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.

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.

>
> While at it, replace the TC358775_VPCTRL_MSF() and
> TC358775_VPCTRL_OPXLFMT() inline functions by the usual macros for a bit
> flag.
>
> Signed-off-by: Michael Walle <mwalle@...nel.org>
> ---
>  drivers/gpu/drm/bridge/tc358775.c | 49 +++++++--------------------------------
>  1 file changed, 8 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c b/drivers/gpu/drm/bridge/tc358775.c
> index 54aea58a3406..a9d731e87970 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -109,7 +109,9 @@
>  #define RDPKTLN         0x0404  /* Command Read Packet Length */
>
>  #define VPCTRL          0x0450  /* Video Path Control */
> -#define EVTMODE                BIT(5)  /* Video event mode enable, tc35876x only */
> +#define VPCTRL_MSF     BIT(0)
> +#define VPCTRL_OPXLFMT BIT(8)
> +#define VPCTRL_EVTMODE BIT(5)  /* Video event mode enable, tc35876x only */
>  #define HTIM1           0x0454  /* Horizontal Timing Control 1 */
>  #define HTIM2           0x0458  /* Horizontal Timing Control 2 */
>  #define VTIM1           0x045C  /* Vertical Timing Control 1 */
> @@ -187,30 +189,6 @@ enum {
>
>  #define L0EN BIT(1)
>
> -#define TC358775_VPCTRL_VSDELAY__MASK  0x3FF00000
> -#define TC358775_VPCTRL_VSDELAY__SHIFT 20
> -static inline u32 TC358775_VPCTRL_VSDELAY(uint32_t val)
> -{
> -       return ((val) << TC358775_VPCTRL_VSDELAY__SHIFT) &
> -                       TC358775_VPCTRL_VSDELAY__MASK;
> -}
> -
> -#define TC358775_VPCTRL_OPXLFMT__MASK  0x00000100
> -#define TC358775_VPCTRL_OPXLFMT__SHIFT 8
> -static inline u32 TC358775_VPCTRL_OPXLFMT(uint32_t val)
> -{
> -       return ((val) << TC358775_VPCTRL_OPXLFMT__SHIFT) &
> -                       TC358775_VPCTRL_OPXLFMT__MASK;
> -}
> -
> -#define TC358775_VPCTRL_MSF__MASK      0x00000001
> -#define TC358775_VPCTRL_MSF__SHIFT     0
> -static inline u32 TC358775_VPCTRL_MSF(uint32_t val)
> -{
> -       return ((val) << TC358775_VPCTRL_MSF__SHIFT) &
> -                       TC358775_VPCTRL_MSF__MASK;
> -}
> -
>  #define TC358775_LVCFG_PCLKDIV__MASK   0x000000f0
>  #define TC358775_LVCFG_PCLKDIV__SHIFT  4
>  static inline u32 TC358775_LVCFG_PCLKDIV(uint32_t val)
> @@ -350,7 +328,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
>         u32 hback_porch, hsync_len, hfront_porch, hactive, htime1, htime2;
>         u32 vback_porch, vsync_len, vfront_porch, vactive, vtime1, vtime2;
>         unsigned int val = 0;
> -       u16 dsiclk, clkdiv, byteclk, t1, t2, t3, vsdelay;
>         struct drm_display_mode *mode;
>         struct drm_connector *connector = get_connector(bridge->encoder);
>
> @@ -398,27 +375,17 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
>
>         /* Video event mode vs pulse mode bit, does not exist for tc358775 */
>         if (tc->type == TC358765)
> -               val = EVTMODE;
> +               val = VPCTRL_EVTMODE;
>         else
>                 val = 0;
>
>         if (tc->bpc == 8)
> -               val |= TC358775_VPCTRL_OPXLFMT(1);
> +               val |= VPCTRL_OPXLFMT;
>         else /* bpc = 6; */
> -               val |= TC358775_VPCTRL_MSF(1);
> -
> -       dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000;
> -       clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 : DIVIDE_BY_3);
> -       byteclk = dsiclk / 4;
> -       t1 = hactive * (tc->bpc * 3 / 8) / tc->num_dsi_lanes;
> -       t2 = ((100000 / clkdiv)) * (hactive + hback_porch + hsync_len + hfront_porch) / 1000;
> -       t3 = ((t2 * byteclk) / 100) - (hactive * (tc->bpc * 3 / 8) /
> -               tc->num_dsi_lanes);
> -
> -       vsdelay = (clkdiv * (t1 + t3) / byteclk) - hback_porch - hsync_len - hactive;
> +               val |= VPCTRL_MSF;
>
> -       val |= TC358775_VPCTRL_VSDELAY(vsdelay);
> -       regmap_write(tc->regmap, VPCTRL, val);
> +       regmap_update_bits(tc->regmap, VPCTRL, val,
> +                          VPCTRL_OPXLFMT | VPCTRL_MSF | VPCTRL_EVTMODE);
>
>         regmap_write(tc->regmap, HTIM1, htime1);
>         regmap_write(tc->regmap, VTIM1, vtime1);
>
> --
> 2.39.2
>

Kind regards
Daniel

Powered by blists - more mailing lists