mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Douglas Anderson <dianders@chromium.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	robdclark@chromium.org, linux-arm-msm@vger.kernel.org,
	seanpaul@chromium.org, bjorn.andersson@linaro.org,
	Jonas Karlman <jonas@kwiboo.se>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	David Airlie <airlied@linux.ie>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 9/9] drm/bridge: ti-sn65dsi86: Skip non-standard DP rates
Date: Sat, 14 Dec 2019 01:07:38 +0100	[thread overview]
Message-ID: <20191214000738.GP624164@phenom.ffwll.local> (raw)
In-Reply-To: <20191213154448.9.I1791f91dd22894da04f86699a7507d101d4385bc@changeid>

On Fri, Dec 13, 2019 at 03:45:30PM -0800, Douglas Anderson wrote:
> The bridge chip supports these DP rates according to TI's spec:
> * 1.62 Gbps (RBR)
> * 2.16 Gbps
> * 2.43 Gbps
> * 2.7 Gbps (HBR)
> * 3.24 Gbps
> * 4.32 Gbps
> * 5.4 Gbps (HBR2)
> 
> As far as I can tell, only RBR, HBR, and HBR2 are part of the DP spec.
> If other rates work then I believe it's because the sink has allowed
> bending the spec a little bit.

I think you need to look at the eDP spec. And filter this stuff correctly
(there's more fields there for these somewhat irky edp timings). Simply
not using them works, but it's defeating the point of having these
intermediate clocks for edp panels.
-Daniel

> 
> I hoped that we could tell which rates would work and which rates
> didn't work based on whether link training passed or not.
> Unfortunately this wasn't so good on at least one panel hooked up to
> the bridge (AUO B116XAK01).  On that panel with 24 bpp configured:
> * 1.62: too small for 69500 kHz at 24 bpp
> * 2.16: link training failed
> * 2.43: link training passed, but garbage on screen
> * 2.7:  joy and happiness
> 
> Let's bypass all non-standard rates, which makes this panel happy
> working.  I'll still keep the code organized in such a way where it
> _could_ try the other rates, though, on the assumption that eventually
> someone will find a way to make use of them.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index cc8bef172f69..cb774ee536cd 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -454,6 +454,15 @@ static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
>  	0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
>  };
>  
> +/**
> + * A table indicating which of the rates in ti_sn_bridge_dp_rate_lut
> + * is as per the DP spec (AKA a standard) as opposed to an intermediate
> + * rate.
> + */
> +static const bool ti_sn_bridge_dp_rate_standard[] = {
> +	false, true, false, false, true, false, false, true
> +};
> +
>  static int ti_sn_bridge_calc_min_dp_rate_idx(struct ti_sn_bridge *pdata)
>  {
>  	unsigned int bit_rate_khz, dp_rate_mhz;
> @@ -660,6 +669,18 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>  	for (dp_rate_idx = ti_sn_bridge_calc_min_dp_rate_idx(pdata);
>  	     dp_rate_idx <= max_dp_rate_idx;
>  	     dp_rate_idx++) {
> +		/*
> +		 * To be on the safe side, we'll skip all non-standard
> +		 * rates and move up to the next standard one.  This is
> +		 * because some panels will pass link training with a non-
> +		 * standard rate but just show garbage.  If the non-standard
> +		 * rates are useful we should figure out how to enable them
> +		 * through querying the panel, having a per-panel whitelist,
> +		 * or adding a DT property.
> +		 */
> +		if (!ti_sn_bridge_dp_rate_standard[dp_rate_idx])
> +			continue;
> +
>  		ret = ti_sn_link_training(pdata, dp_rate_idx, &last_err_str);
>  		if (!ret)
>  			break;
> -- 
> 2.24.1.735.g03f4e72817-goog
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2019-12-14  0:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 23:45 [PATCH 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other low res DP Douglas Anderson
2019-12-13 23:45 ` [PATCH 1/9] drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates Douglas Anderson
2019-12-13 23:45 ` [PATCH 2/9] drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int Douglas Anderson
2019-12-13 23:45 ` [PATCH 3/9] drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link Douglas Anderson
2019-12-13 23:45 ` [PATCH 4/9] drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta Douglas Anderson
2019-12-13 23:45 ` [PATCH 5/9] drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink Douglas Anderson
2019-12-13 23:45 ` [PATCH 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can Douglas Anderson
2019-12-13 23:45 ` [PATCH 7/9] drm/bridge: ti-sn65dsi86: Group DP link training bits in a function Douglas Anderson
2019-12-13 23:45 ` [PATCH 8/9] drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail Douglas Anderson
2019-12-15 20:04   ` [PATCH 1/2] fixup! " Rob Clark
2019-12-18  0:52     ` Doug Anderson
2019-12-13 23:45 ` [PATCH 9/9] drm/bridge: ti-sn65dsi86: Skip non-standard DP rates Douglas Anderson
2019-12-14  0:07   ` Daniel Vetter [this message]
2019-12-14  0:47     ` Doug Anderson
2019-12-16  1:19       ` Jeffrey Hugo
2019-12-17  0:31         ` Doug Anderson
2019-12-15 20:06   ` [PATCH 2/2] fixup! " Rob Clark
2019-12-18  0:54     ` Doug Anderson
2019-12-15 20:02 ` [PATCH 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other low res DP Rob Clark

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=20191214000738.GP624164@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=dianders@chromium.org \
    --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 \
    --cc=robdclark@chromium.org \
    --cc=seanpaul@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®