[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200203234509.GJ311651@builder>
Date: Mon, 3 Feb 2020 15:45:09 -0800
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: Andrzej Hajda <a.hajda@...sung.com>,
Neil Armstrong <narmstrong@...libre.com>,
robdclark@...omium.org, linux-arm-msm@...r.kernel.org,
seanpaul@...omium.org, Jeffrey Hugo <jeffrey.l.hugo@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Jonas Karlman <jonas@...boo.se>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, David Airlie <airlied@...ux.ie>,
Jernej Skrabec <jernej.skrabec@...l.net>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH v3 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO
B116XAK01 + other DP
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> This series contains a pile of patches that was created to support
> hooking up the AUO B116XAK01 panel to the eDP side of the bridge. In
> general it should be useful for hooking up a wider variety of DP
> panels to the bridge, especially those with lower resolution and lower
> bits per pixel.
>
> The overall result of this series:
> * Allows panels with fewer than 4 DP lanes hooked up to work.
> * Optimizes the link rate for panels with 6 bpp.
> * Supports trying more than one link rate when training if the main
> link rate didn't work.
> * Avoids invalid link rates.
>
> It's not expected that this series will break any existing users but
> testing is always good.
>
> To support the AUO B116XAK01, we could actually stop at the ("Use
> 18-bit DP if we can") patch since that causes the panel to run at a
> link rate of 1.62 which works. The patches to try more than one link
> rate were all developed prior to realizing that I could just use
> 18-bit mode and were validated with that patch reverted.
>
> These patches were tested on sdm845-cheza atop mainline as of
> 2019-12-13 and also on another board (the one with AUO B116XAK01) atop
> a downstream kernel tree.
>
> This patch series doesn't do anything to optimize the MIPI link and
> only focuses on the DP link. For instance, it's left as an exercise
> to the reader to see if we can use the 666-packed mode on the MIPI
> link and save some power (because we could lower the clock rate).
>
> I am nowhere near a display expert and my knowledge of DP and MIPI is
> pretty much zero. If something about this patch series smells wrong,
> it probably is. Please let know and I'll try to fix it.
>
Thanks for the patches Doug, this fixes the rate and DP lane-count
issues I'm seeing on my Lenovo Yoga C630 with the current
implementation.
Tested-by: Bjorn Andersson <bjorn.andersson@...aro.org>
Regards,
Bjorn
> Changes in v3:
> - Init rate_valid table, don't rely on stack being 0 (oops).
> - Rename rate_times_200khz to rate_per_200khz.
> - Loop over the ti_sn_bridge_dp_rate_lut table, making code smaller.
> - Use 'true' instead of 1 for bools.
> - Added note to commit message noting DP 1.4+ isn't well tested.
>
> Changes in v2:
> - Squash in maybe-uninitialized fix from Rob Clark.
> - Patch ("Avoid invalid rates") replaces ("Skip non-standard DP rates")
>
> Douglas Anderson (9):
> drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates
> drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int
> drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link
> drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta
> drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink
> drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
> drm/bridge: ti-sn65dsi86: Group DP link training bits in a function
> drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail
> drm/bridge: ti-sn65dsi86: Avoid invalid rates
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 259 +++++++++++++++++++++-----
> 1 file changed, 216 insertions(+), 43 deletions(-)
>
> --
> 2.24.1.735.g03f4e72817-goog
>
Powered by blists - more mailing lists