Re: [PATCH 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other low res DP

From: Rob Clark
Date: Sun Dec 15 2019 - 15:02:19 EST

On Fri, Dec 13, 2019 at 3:46 PM Douglas Anderson <dianders@xxxxxxxxxxxx> 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.
> It's not expected that this series will break any existing users, but
> it is possible that the patch to skip non-standard DP rates could mean
> that a panel that used to use one of these non-standard link rates
> will now run at a higher rate than it used to. If this happens, the
> patch could be reverted or someone could figure out how to decide when
> it's OK to use the non-standard rates.
> 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.
> The patch to try more than one rate was validated by forcing the code
> to try 2.16 GHz (but still skip 2.43 GHz, which trains but shows
> garbage on AUO B116XAK01) and seeing that we'd try 2.16 GHz (and fail)
> and then eventually pass at 2.7 GHz and show a pretty screen.
> 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.
> 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: Skip non-standard DP rates
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 230 +++++++++++++++++++++-----
> 1 file changed, 187 insertions(+), 43 deletions(-)

I've given these a spin on my yoga c630, which uses the same bridge, so:

Tested-by: Rob Clark <robdclark@xxxxxxxxx>

I've got one small fixup for a compiler warning for the 2nd to last,
and with that, the first 8 are:

Reviewed-by: Rob Clark <robdclark@xxxxxxxxx>

I've also got a fixup for the last one which reads
SUPPORTED_LINK_RATES. However the panel I have is pre eDP 1.4, so the
interesting codepath there is untested. Not sure offhand if the
panels you have are eDP 1.4+ or not?


> --
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx