diff mbox series

[v3,10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided

Message ID 20210402152701.v3.10.I7a8708139ae993f30f51eec7d065a1906c31a4bc@changeid
State New
Headers show
Series drm: Fix EDID reading on ti-sn65dsi86 | expand

Commit Message

Doug Anderson April 2, 2021, 10:28 p.m. UTC
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(+)

Comments

Laurent Pinchart April 5, 2021, 1:04 a.m. UTC | #1
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@chromium.org>


Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.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
diff mbox series

Patch

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);
 }