From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: 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,
Michael Walle <mwalle@kernel.org>
Cc: Daniel Semkowicz <dse@thaumatec.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Michael Walle <mwalle@kernel.org>
Subject: Re: [PATCH 01/20] drm/bridge: add dsi_lp11_notify mechanism
Date: Tue, 07 May 2024 10:37:54 +0200 [thread overview]
Message-ID: <2189493.irdbgypaU6@steina-w> (raw)
In-Reply-To: <20240506-tc358775-fix-powerup-v1-1-545dcf00b8dd@kernel.org>
Hi Michael,
Am Montag, 6. Mai 2024, 15:34:30 CEST schrieb Michael Walle:
> Some bridges have very strict power-up reqirements. In this case, the
> Toshiba TC358775. The reset has to be deasserted while *both* the DSI
> clock and DSI data lanes are in LP-11 mode. After the reset is relased,
> the bridge needs the DSI clock to actually be able to process I2C
> access. This access will configure the DSI side of the bridge during
> which the DSI data lanes have to be in LP-11 mode.
Apparently this is an issue for a lot of DSI bridges. But enabling LP-11 for
a bridge is impossible with current documentation [1], which states "A DSI
host should keep the PHY powered down until the pre_enable operation is
called."
Additionally tc358767/tc9595 (DSI-DP bridge) needs LP-11 for AUX channel
access to even get EDID. This is a requirement before pre_enable would
even be possible.
So some changes to the current flow are needed. But I am not so sure
about LP-11 notification. IMHO a device request to the DSI host to
enable LP-11 seems more sensible.
Best regards,
Alexander
[1] https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation
> After everything is
> configured the video stream can finally be enabled.
>
> This means:
> (1) The bridge has to be configured completely in .pre_enable() op
> (with the clock turned on and data lanes in LP-11 mode, thus
> .pre_enable_prev_first has to be set).
> (2) The bridge will enable its output in the .enable() op
> (3) There must be some mechanism before (1) where the bridge can
> release its reset while the clock lane is still in LP-11 mode.
>
> Unfortunately, (3) is crucial for a correct operation of the bridge.
> To satisfy this requriment, introduce a new callback .dsi_lp11_notify()
> which will be called by the DSI host driver.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> drivers/gpu/drm/drm_bridge.c | 16 ++++++++++++++++
> include/drm/drm_bridge.h | 12 ++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 28abe9aa99ca..98cd6558aecb 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1339,6 +1339,22 @@ void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> }
> EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>
> +/**
> + * drm_bridge_dsi_lp11_notify - notify clock/data lanes LP-11 mode
> + * @bridge: bridge control structure
> + *
> + * DSI host drivers shall call this function while the clock and data lanes
> + * are still in LP-11 mode.
> + *
> + * This function shall be called in a context that can sleep.
> + */
> +void drm_bridge_dsi_lp11_notify(struct drm_bridge *bridge)
> +{
> + if (bridge->funcs->dsi_lp11_notify)
> + bridge->funcs->dsi_lp11_notify(bridge);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_dsi_lp11_notify);
> +
> #ifdef CONFIG_OF
> /**
> * of_drm_find_bridge - find the bridge corresponding to the device node in
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 4baca0d9107b..4ef61274e0a8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -630,6 +630,17 @@ struct drm_bridge_funcs {
> */
> void (*hpd_disable)(struct drm_bridge *bridge);
>
> + /**
> + * dsi_lp11_notify:
> + *
> + * Will be called by the DSI host driver while both the DSI clock
> + * lane as well as the DSI data lanes are in LP-11 mode. Some bridges
> + * need this state while releasing the reset, for example.
> + * Not all DSI host drivers will support this. Therefore, the DSI
> + * bridge driver must not rely on this op to be called.
> + */
> + void (*dsi_lp11_notify)(struct drm_bridge *bridge);
> +
> /**
> * @debugfs_init:
> *
> @@ -898,6 +909,7 @@ void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> enum drm_connector_status status);
> +void drm_bridge_dsi_lp11_notify(struct drm_bridge *bridge);
>
> #ifdef CONFIG_DRM_PANEL_BRIDGE
> bool drm_bridge_is_panel(const struct drm_bridge *bridge);
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
next prev parent reply other threads:[~2024-05-07 8:38 UTC|newest]
Thread overview: 23+ 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 [this message]
2024-05-07 13:39 ` Dmitry Baryshkov
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-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-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
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=2189493.irdbgypaU6@steina-w \
--to=alexander.stein@ew.tq-group.com \
--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=mwalle@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 read-only IMAP folder(s) and NNTP newsgroup(s).