[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGpiAKAETufAuMwF@pendragon.ideasonboard.com>
Date: Mon, 5 Apr 2021 04:04:00 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Douglas Anderson <dianders@...omium.org>
Cc: Andrzej Hajda <a.hajda@...sung.com>,
Neil Armstrong <narmstrong@...libre.com>,
Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...l.net>,
Sam Ravnborg <sam@...nborg.org>,
Linus W <linus.walleij@...aro.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
robdclark@...omium.org, Stephen Boyd <swboyd@...omium.org>,
Steev Klimaszewski <steev@...i.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
linux-arm-msm@...r.kernel.org,
Stanislav Lisovskiy <stanislav.lisovskiy@...el.com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>,
Robert Foss <robert.foss@...aro.org>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if
refclk was provided
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:44PM -0700, Douglas Anderson wrote:
> Though I don't have access to any hardware that uses ti-sn65dsi86 and
> _doesn't_ provide a "refclk", I believe that we'll have trouble
> reading the EDID at bootup in that case. Specifically I believe that
> if there's no "refclk" we need the MIPI source clock to be active
> before we can successfully read the EDID. My evidence here is that, in
> testing, I couldn't read the EDID until I turned on the DPPLL in the
> bridge chip and that the DPPLL needs the input clock to be active.
>
> Since this is hard to support, let's punt trying to read the EDID if
> there's no "refclk".
>
> I don't believe there are any users of the ti-sn65dsi86 bridge chip
> that _don't_ use "refclk". The bridge chip is _very_ inflexible in
> that mode. The only time I've seen that mode used was for some really
> early prototype hardware that was thrown in the e-waste bin years ago
> when we realized how inflexible it was.
>
> Even if someone is using the bridge chip without the "refclk" they're
> in no worse shape than they were before the (fairly recent) commit
> 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC").
>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index a76cac93cb46..fb50f9f95b0f 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -275,6 +275,18 @@ static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector)
> bool was_enabled;
> int num;
>
> + /*
> + * Don't try to read the EDID if no refclk. In theory it is possible
> + * to make this work but it's tricky. I believe that we need to get
> + * our upstream MIPI source to provide a pixel clock before we can
> + * do AUX transations but we need to be able to read the EDID before
> + * we've picked a display mode. The bridge is already super limited
> + * if you try to use it without a refclk so presumably limiting to
> + * the fixed modes our downstream panel reports is fine.
> + */
> + if (!pdata->refclk)
> + goto exit;
> +
> if (!edid) {
> was_enabled = pdata->pre_enabled;
>
> @@ -291,6 +303,7 @@ static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector)
> return num;
> }
>
> +exit:
> return drm_panel_get_modes(pdata->panel, connector);
> }
>
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists