From: Lucas Stach <l.stach@pengutronix.de>
To: Marek Vasut <marex@denx.de>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>,
Jonas Karlman <jonas@kwiboo.se>,
dri-devel@lists.freedesktop.org, patchwork-lst@pengutronix.de,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
kernel@pengutronix.de
Subject: Re: [PATCH 2/2] drm: bridge: tc358767: give VSDELAY some positive value
Date: Wed, 07 Jun 2023 14:53:23 +0200 [thread overview]
Message-ID: <7210bb5955a469134f3b072007bf98a74c8f17da.camel@pengutronix.de> (raw)
In-Reply-To: <70962376-c7f1-1adc-37e4-55fa33055ae9@denx.de>
Am Freitag, dem 02.06.2023 um 23:34 +0200 schrieb Marek Vasut:
> On 6/2/23 21:15, Lucas Stach wrote:
> > From: David Jander <david@protonic.nl>
> >
> > The documentation is not clear about how this delay works.
> > Empirical tests have shown that with a VSDELAY of 0, the first
> > scanline is not properly formatted in the output stream when
> > DSI->DP mode is used. The calculation spreadsheets from Toshiba
> > seem to always make this value equal to the HFP + 10 for DSI->DP
> > use-case. For DSI->DPI this value should be > 2 and for DPI->DP
> > it seems to always be 0x64.
> >
> > Signed-off-by: David Jander <david@protonic.nl>
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > drivers/gpu/drm/bridge/tc358767.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
> > index 46916ae30f8f..9f2c67b4a488 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -817,7 +817,7 @@ static int tc_set_common_video_mode(struct tc_data *tc,
> > * sync signals
> > */
> > ret = regmap_write(tc->regmap, VPCTRL0,
> > - FIELD_PREP(VSDELAY, 0) |
> > + FIELD_PREP(VSDELAY, right_margin + 10) |
> > OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
> > if (ret)
> > return ret;
>
> Aren't you running into a problem due to VS timing misconfiguration on
> the scanout engine or DSI serializer side ? The VSDELAY seems to
> increase the length of VSYNC active .
>
No, as far as I understand the VSDELAY adds an offset between input an
output side of the video FIFO. It shouldn't increase the length of any
sync signal, but delays the read side of the FIFO, so the write (DSI)
side has some margin to put data into the FIFO before DP side starts to
assemble packets.
> Which DSI bus mode do you use, sync events/pulses/burst ?
At the time when this patch was written it still was the SYNC_PULSE
mode.
Regards,
Lucas
next prev parent reply other threads:[~2023-06-07 12:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 19:15 [PATCH 1/2] drm: bridge: tc358767: increase PLL lock time delay Lucas Stach
2023-06-02 19:15 ` [PATCH 2/2] drm: bridge: tc358767: give VSDELAY some positive value Lucas Stach
2023-06-02 21:34 ` Marek Vasut
2023-06-07 12:53 ` Lucas Stach [this message]
2023-06-07 13:54 ` Marek Vasut
2023-06-08 8:11 ` Lucas Stach
2023-07-08 19:01 ` Marek Vasut
2023-06-02 21:31 ` [PATCH 1/2] drm: bridge: tc358767: increase PLL lock time delay Marek Vasut
2023-07-08 19:02 ` Marek Vasut
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=7210bb5955a469134f3b072007bf98a74c8f17da.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=andrzej.hajda@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@pengutronix.de \
--cc=marex@denx.de \
--cc=neil.armstrong@linaro.org \
--cc=patchwork-lst@pengutronix.de \
--cc=rfoss@kernel.org \
/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).