All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Anderson <dianders@chromium.org>
To: Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Sam Ravnborg <sam@ravnborg.org>
Cc: Linus W <linus.walleij@linaro.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	robdclark@chromium.org, Stephen Boyd <swboyd@chromium.org>,
	Steev Klimaszewski <steev@kali.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	linux-arm-msm@vger.kernel.org,
	Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>,
	Douglas Anderson <dianders@chromium.org>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	Robert Foss <robert.foss@linaro.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided
Date: Fri,  2 Apr 2021 15:28:44 -0700	[thread overview]
Message-ID: <20210402152701.v3.10.I7a8708139ae993f30f51eec7d065a1906c31a4bc@changeid> (raw)
In-Reply-To: <20210402222846.2461042-1-dianders@chromium.org>

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@chromium.org>
---

(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);
 }
 
-- 
2.31.0.208.g409f899ff0-goog


WARNING: multiple messages have this Message-ID (diff)
From: Douglas Anderson <dianders@chromium.org>
To: Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Sam Ravnborg <sam@ravnborg.org>
Cc: robdclark@chromium.org, dri-devel@lists.freedesktop.org,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org,
	Douglas Anderson <dianders@chromium.org>,
	Steev Klimaszewski <steev@kali.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>,
	Robert Foss <robert.foss@linaro.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided
Date: Fri,  2 Apr 2021 15:28:44 -0700	[thread overview]
Message-ID: <20210402152701.v3.10.I7a8708139ae993f30f51eec7d065a1906c31a4bc@changeid> (raw)
In-Reply-To: <20210402222846.2461042-1-dianders@chromium.org>

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@chromium.org>
---

(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);
 }
 
-- 
2.31.0.208.g409f899ff0-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-04-02 22:29 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02 22:28 [PATCH v3 00/12] drm: Fix EDID reading on ti-sn65dsi86 Douglas Anderson
2021-04-02 22:28 ` Douglas Anderson
2021-04-02 22:28 ` [PATCH v3 01/12] drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable() Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  0:49   ` Laurent Pinchart
2021-04-05  0:49     ` Laurent Pinchart
2021-04-15  1:19     ` Doug Anderson
2021-04-15  1:19       ` Doug Anderson
2021-04-15  1:56       ` Laurent Pinchart
2021-04-15  1:56         ` Laurent Pinchart
2021-04-15 14:48         ` Doug Anderson
2021-04-15 14:48           ` Doug Anderson
2021-04-02 22:28 ` [PATCH v3 02/12] drm/bridge: ti-sn65dsi86: Simplify refclk handling Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-02 22:28 ` [PATCH v3 03/12] drm/bridge: ti-sn65dsi86: Remove incorrectly tagged kerneldoc comment Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  0:50   ` Laurent Pinchart
2021-04-05  0:50     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 04/12] drm/bridge: ti-sn65dsi86: Reorder remove() Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  0:52   ` Laurent Pinchart
2021-04-05  0:52     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 05/12] drm/bridge: ti-sn65dsi86: Move drm_panel_unprepare() to post_disable() Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  0:58   ` Laurent Pinchart
2021-04-05  0:58     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 06/12] drm/bridge: ti-sn65dsi86: Get rid of the useless detect() function Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  0:58   ` Laurent Pinchart
2021-04-05  0:58     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 07/12] drm/bridge: ti-sn65dsi86: Remove extra call: drm_connector_update_edid_property() Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  1:01   ` Laurent Pinchart
2021-04-05  1:01     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 08/12] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-02 22:28 ` [PATCH v3 09/12] drm/bridge: ti-sn65dsi86: Fail aux transfers right away if not powered Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-02 22:28 ` Douglas Anderson [this message]
2021-04-02 22:28   ` [PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided Douglas Anderson
2021-04-05  1:04   ` Laurent Pinchart
2021-04-05  1:04     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 11/12] drm/bridge: ti-sn65dsi86: Print an error if we fallback to panel modes Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-05  1:04   ` Laurent Pinchart
2021-04-05  1:04     ` Laurent Pinchart
2021-04-02 22:28 ` [PATCH v3 12/12] drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare Douglas Anderson
2021-04-02 22:28   ` Douglas Anderson
2021-04-15  0:58   ` Laurent Pinchart
2021-04-15  0:58     ` Laurent Pinchart
2021-04-15  1:22     ` Doug Anderson
2021-04-15  1:22       ` Doug Anderson
2021-04-15  1:30       ` Laurent Pinchart
2021-04-15  1:30         ` 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=20210402152701.v3.10.I7a8708139ae993f30f51eec7d065a1906c31a4bc@changeid \
    --to=dianders@chromium.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=narmstrong@baylibre.com \
    --cc=robdclark@chromium.org \
    --cc=robert.foss@linaro.org \
    --cc=sam@ravnborg.org \
    --cc=stanislav.lisovskiy@intel.com \
    --cc=steev@kali.org \
    --cc=swboyd@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.