linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Walle" <mwalle@kernel.org>
To: "Daniel Semkowicz" <dse@thaumatec.com>
Cc: "Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Chun-Kuang Hu" <chunkuang.hu@kernel.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Vinay Simha BN" <simhavcs@gmail.com>,
	"Tony Lindgren" <tony@atomide.com>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<linux-mediatek@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 09/20] drm/bridge: tc358775: remove complex vsdelay calculation
Date: Fri, 06 Sep 2024 16:34:23 +0200	[thread overview]
Message-ID: <D3Z9XTBHSUEN.2GW0UCIPLR6HY@kernel.org> (raw)
In-Reply-To: <CAHgnY3=KCD4gyJ4nL6nN1tvWcsiRQL+Oz11RNOniDdyMoEPcSg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

  reply	other threads:[~2024-09-06 14:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-06 13:34 [PATCH 00/20] drm/bridge: tc358775: proper bridge bringup and code cleanup Michael Walle
2024-05-06 13:34 ` [PATCH 01/20] drm/bridge: add dsi_lp11_notify mechanism Michael Walle
2024-05-07  8:37   ` Alexander Stein
2024-05-07 13:39     ` Dmitry Baryshkov
2024-06-03 13:39       ` Michael Walle
2024-05-06 13:34 ` [PATCH 02/20] drm/mediatek: dsi: provide LP-11 mode during .pre_enable Michael Walle
2024-05-06 13:34 ` [PATCH 03/20] drm/mediatek: dsi: add support for .dsi_lp11_notity() Michael Walle
2024-05-06 13:34 ` [PATCH 04/20] drm/bridge: tc358775: fix regulator supply id Michael Walle
2024-05-06 13:34 ` [PATCH 05/20] drm/bridge: tc358775: add crtc modes fixup Michael Walle
2024-05-06 13:34 ` [PATCH 06/20] drm/bridge: tc358775: redefine LV_MX() Michael Walle
2024-05-06 13:34 ` [PATCH 07/20] drm/bridge: tc358775: use regmap instead of open coded access functions Michael Walle
2024-09-06 13:47   ` Daniel Semkowicz
2024-09-06 13:58     ` Michael Walle
2024-05-06 13:34 ` [PATCH 08/20] drm/bridge: tc358775: remove error message if regulator is missing Michael Walle
2024-05-06 13:34 ` [PATCH 09/20] drm/bridge: tc358775: remove complex vsdelay calculation Michael Walle
2024-09-06 14:20   ` Daniel Semkowicz
2024-09-06 14:34     ` Michael Walle [this message]
2024-09-09  5:29       ` Daniel Semkowicz
2024-05-06 13:34 ` [PATCH 10/20] drm/bridge: tc358775: simplify lvds_link property Michael Walle
2024-05-06 13:34 ` [PATCH 11/20] drm/bridge: tc358775: reformat weird indentation Michael Walle
2024-05-06 13:34 ` [PATCH 12/20] drm/bridge: tc358775: correctly configure LVDS clock Michael Walle
2024-05-06 13:34 ` [PATCH 13/20] drm/bridge: tc358775: split the init code Michael Walle
2024-05-06 13:34 ` [PATCH 14/20] drm/bridge: tc358775: configure PLL depending on the LVDS clock Michael Walle
2024-05-06 13:34 ` [PATCH 15/20] drm/bridge: tc358775: dynamically configure DSI link settings Michael Walle
2024-05-06 13:34 ` [PATCH 16/20] drm/bridge: tc358775: use proper defines to configure LVDS timings Michael Walle
2024-05-06 13:34 ` [PATCH 17/20] drm/bridge: tc358775: move bridge power up/down into functions Michael Walle
2024-05-06 13:34 ` [PATCH 18/20] drm/bridge: tc358775: fix the power-up/down delays Michael Walle
2024-05-06 13:34 ` [PATCH 19/20] drm/bridge: tc358775: fix power-up sequencing Michael Walle
2024-05-06 13:34 ` [PATCH 20/20] drm/bridge: tc358775: use devm_drm_bridge_add() Michael Walle
2024-06-03 11:47 ` [PATCH 00/20] drm/bridge: tc358775: proper bridge bringup and code cleanup Michael Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D3Z9XTBHSUEN.2GW0UCIPLR6HY@kernel.org \
    --to=mwalle@kernel.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dse@thaumatec.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=rfoss@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=simhavcs@gmail.com \
    --cc=tony@atomide.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).