dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dave Stevenson <dave.stevenson@raspberrypi.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>,
	Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Robert Foss <robert.foss@linaro.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 1/2] drm/ bridge: tc358762: move bridge init to enable callback
Date: Fri, 26 Nov 2021 11:56:36 +0000	[thread overview]
Message-ID: <CAPY8ntBrhYAmsraDqJGuTrSL6VjGXBAMVoN7xweV7E4qZv+v3Q@mail.gmail.com> (raw)
In-Reply-To: <20211126003227.1031347-1-dmitry.baryshkov@linaro.org>

Hi Dmitry

On Fri, 26 Nov 2021 at 00:32, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> During the pre_enable time the previous bridge (e.g. DSI host) might be
> not initialized yet. Move the regulator enablement and bridge init to
> te enable callback (and consequently regulator disblement to disable).

Except that in the enable callback the DSI host has video enabled too,
so the data lanes may be in HS mode too, and the bridge may not be
prepared to accept that during power on / initialisation. That means
you've got a race condition over how quickly the composition hardware
starts producing pixel data vs when this enable callback is called. I
suspect that is why we had [1] for the rare case when the race
condition failed.
There's also seems to be no guarantee that a host can do LP commands
between HS video packets (eg sunxi [2])

This is the same issue that was being hacked around in [3], and is one
of the questions I'd raised back in July [4].
The DSI support is broken when it comes to accommodating
initialisation sequences, but in trying to ensure all possible
sequences can be accomodated, all currently proposed solutions have
been shot down.
Some platforms have worked around it by powering up the DSI host in
mode_set (dw-mipi-dsi), others have broken the bridge chain apart so
their pre_enable gets called first (exynos and currently vc4) except
that approach is broken for the atomic API.

There is a need for some form of resolution, even if it is only
documenting the correct hack to implement in the DSI host driver.
Hacking bridge or panel drivers to try and workaround it seems wrong.

  Dave

[1] https://lists.freedesktop.org/archives/dri-devel/2021-September/322119.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#n776
[3] https://lists.freedesktop.org/archives/dri-devel/2021-November/332003.html
[4] https://lists.freedesktop.org/archives/dri-devel/2021-July/313576.html

> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>  drivers/gpu/drm/bridge/tc358762.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358762.c b/drivers/gpu/drm/bridge/tc358762.c
> index 7104828024fd..ebdf771a1e49 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -64,7 +64,7 @@ struct tc358762 {
>         struct drm_connector connector;
>         struct regulator *regulator;
>         struct drm_bridge *panel_bridge;
> -       bool pre_enabled;
> +       bool enabled;
>         int error;
>  };
>
> @@ -125,26 +125,26 @@ static int tc358762_init(struct tc358762 *ctx)
>         return tc358762_clear_error(ctx);
>  }
>
> -static void tc358762_post_disable(struct drm_bridge *bridge)
> +static void tc358762_disable(struct drm_bridge *bridge)
>  {
>         struct tc358762 *ctx = bridge_to_tc358762(bridge);
>         int ret;
>
>         /*
> -        * The post_disable hook might be called multiple times.
> +        * The disable hook might be called multiple times.
>          * We want to avoid regulator imbalance below.
>          */
> -       if (!ctx->pre_enabled)
> +       if (!ctx->enabled)
>                 return;
>
> -       ctx->pre_enabled = false;
> +       ctx->enabled = false;
>
>         ret = regulator_disable(ctx->regulator);
>         if (ret < 0)
>                 dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
>  }
>
> -static void tc358762_pre_enable(struct drm_bridge *bridge)
> +static void tc358762_enable(struct drm_bridge *bridge)
>  {
>         struct tc358762 *ctx = bridge_to_tc358762(bridge);
>         int ret;
> @@ -157,7 +157,7 @@ static void tc358762_pre_enable(struct drm_bridge *bridge)
>         if (ret < 0)
>                 dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
>
> -       ctx->pre_enabled = true;
> +       ctx->enabled = true;
>  }
>
>  static int tc358762_attach(struct drm_bridge *bridge,
> @@ -170,8 +170,8 @@ static int tc358762_attach(struct drm_bridge *bridge,
>  }
>
>  static const struct drm_bridge_funcs tc358762_bridge_funcs = {
> -       .post_disable = tc358762_post_disable,
> -       .pre_enable = tc358762_pre_enable,
> +       .disable = tc358762_disable,
> +       .enable = tc358762_enable,
>         .attach = tc358762_attach,
>  };
>
> @@ -218,7 +218,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
>         mipi_dsi_set_drvdata(dsi, ctx);
>
>         ctx->dev = dev;
> -       ctx->pre_enabled = false;
> +       ctx->enabled = false;
>
>         /* TODO: Find out how to get dual-lane mode working */
>         dsi->lanes = 1;
> --
> 2.33.0
>

  parent reply	other threads:[~2021-11-26 11:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26  0:32 [PATCH 1/2] drm/ bridge: tc358762: move bridge init to enable callback Dmitry Baryshkov
2021-11-26  0:32 ` [PATCH 2/2] drm/ bridge: tc358762: drop connector field Dmitry Baryshkov
2021-11-26 11:56 ` Dave Stevenson [this message]
2021-12-09 16:53   ` [PATCH 1/2] drm/ bridge: tc358762: move bridge init to enable callback Dmitry Baryshkov
2021-12-09 17:06     ` Laurent Pinchart

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=CAPY8ntBrhYAmsraDqJGuTrSL6VjGXBAMVoN7xweV7E4qZv+v3Q@mail.gmail.com \
    --to=dave.stevenson@raspberrypi.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=robert.foss@linaro.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).