All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
To: a.hajda@samsung.com, narmstrong@baylibre.com,
	Laurent.pinchart@ideasonboard.com, jonas@kwiboo.se,
	jernej.skrabec@siol.net, airlied@linux.ie, daniel@ffwll.ch,
	bjorn.andersson@linaro.org
Cc: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Subject: [PATCH v2] drm/bridge: ti-sn65dsi86: Decouple DP output lanes from DSI input lanes
Date: Tue, 22 Oct 2019 12:01:20 -0700	[thread overview]
Message-ID: <20191022190120.25772-1-jeffrey.l.hugo@gmail.com> (raw)

Based on work by Bjorn Andersson <bjorn.andersson@linaro.org>

The bridge can be configured to use 1, 2, or 4 DP lanes.  This
configuration is independent of the input DSI lanes.  Right now, the
driver assumes that there is 1:1 mapping of input lanes to output lanes
which is not correct and does not work for manu devices such as the
Lenovo Miix 630 and Lenovo Yoga C630 laptops.

The bridge can also be configured to use one of a number of data rates on
the DP lanes.  Currently any of the supported rates is considered valid,
however the configured rate must also be supported by the connected panel,
and not all rates are supported or even valid for any particular panel.

Luckily, we can determine what we need at runtime by reading the DPCD from
the attached panel.  DPCD will tell us the maximum number of supported
lanes, and the supported data rates.

Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---

Bjorn, I think this should address the issue you pointed out concerning
the data rate glitch I missed in your origional work.  Would you kindly
give this a test and let me know if it appears to address all of the
issues you were working around?

v2:
-Use DPCD instead of DT to address the issue of some panels not
supporting all the rates

 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 97 ++++++++++++++++++++++++++-
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 43abf01ebd4c..72bacca8d49a 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -100,6 +100,7 @@ struct ti_sn_bridge {
 	struct drm_panel		*panel;
 	struct gpio_desc		*enable_gpio;
 	struct regulator_bulk_data	supplies[SN_REGULATOR_SUPPLY_NUM];
+	int				dp_lanes;
 };
 
 static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
@@ -432,6 +433,8 @@ static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge *pdata)
 	unsigned int val, i;
 	struct drm_display_mode *mode =
 		&pdata->bridge.encoder->crtc->state->adjusted_mode;
+	u8 dpcd_val;
+	u8 rate_valid[8] = {0};
 
 	/* set DSIA clk frequency */
 	bit_rate_mhz = (mode->clock / 1000) *
@@ -444,10 +447,91 @@ static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge *pdata)
 	regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
 
 	/* set DP data rate */
-	dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
+	dp_rate_mhz = ((bit_rate_mhz / pdata->dp_lanes) * DP_CLK_FUDGE_NUM) /
 							DP_CLK_FUDGE_DEN;
+
+	/* read the panel capabilities to determine valid supported rates */
+	val = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LINK_RATE, &dpcd_val);
+	if (!val) {
+		DRM_ERROR("Reading max link rate from DPCD failed\n");
+		return;
+	}
+
+	if (dpcd_val) {
+		/* cap to the max rate supported by the bridge */
+		if (dpcd_val > 0x14)
+			dpcd_val = 0x14;
+
+		switch (dpcd_val) {
+		case 0x14:
+			rate_valid[7] = 1;
+			/* fall through */
+		case 0xa:
+			rate_valid[4] = 1;
+			/* fall through */
+		case 0x6:
+			rate_valid[1] = 1;
+			break;
+		default:
+			DRM_ERROR("Invalid max link rate from DPCD:%x\n",
+				  dpcd_val);
+			return;
+		}
+	} else {
+		/* eDP 1.4 devices can provide a custom table */
+		__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
+
+		val = drm_dp_dpcd_readb(&pdata->aux, DP_EDP_DPCD_REV, &dpcd_val);
+		if (!val) {
+			DRM_ERROR("Reading eDP rev from DPCD failed\n");
+			return;
+		}
+
+		if (dpcd_val < DP_EDP_14) {
+			DRM_ERROR("eDP 1.4 supported link rates specified from non-1.4 device\n");
+			return;
+		}
+
+		drm_dp_dpcd_read(&pdata->aux, DP_SUPPORTED_LINK_RATES,
+			      sink_rates, sizeof(sink_rates));
+
+		for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
+			val = le16_to_cpu(sink_rates[i]);
+
+			if (!val)
+				break;
+
+			switch (val) {
+			case 27000:
+				rate_valid[7] = 1;
+				break;
+			case 21600:
+				rate_valid[6] = 1;
+				break;
+			case 16200:
+				rate_valid[5] = 1;
+				break;
+			case 13500:
+				rate_valid[4] = 1;
+				break;
+			case 12150:
+				rate_valid[3] = 1;
+				break;
+			case 10800:
+				rate_valid[2] = 1;
+				break;
+			case 8100:
+				rate_valid[1] = 1;
+				break;
+			default:
+				/* unsupported */
+				break;
+			}
+		}
+	}
+
 	for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
-		if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
+		if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz && rate_valid[i])
 			break;
 
 	regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
@@ -505,7 +589,14 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
 			   CHA_DSI_LANES_MASK, val);
 
 	/* DP lane config */
-	val = DP_NUM_LANES(pdata->dsi->lanes - 1);
+	ret = drm_dp_dpcd_readb(&pdata->aux, DP_MAX_LANE_COUNT, (u8 *)&val);
+	if (!ret) {
+		DRM_ERROR("Reading lane count from DPCD failed\n");
+		return;
+	}
+	pdata->dp_lanes = val & DP_MAX_LANE_COUNT_MASK;
+	/* 4 lanes are encoded with the value "3" */
+	val = DP_NUM_LANES(pdata->dp_lanes == 4 ? 3 : pdata->dp_lanes);
 	regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK,
 			   val);
 
-- 
2.17.1


             reply	other threads:[~2019-10-22 19:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 19:01 Jeffrey Hugo [this message]
2019-12-18  0:51 ` [PATCH v2] drm/bridge: ti-sn65dsi86: Decouple DP output lanes from DSI input lanes Doug Anderson
2019-12-18  0:51   ` Doug Anderson

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=20191022190120.25772-1-jeffrey.l.hugo@gmail.com \
    --to=jeffrey.l.hugo@gmail.com \
    --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=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    /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.