From: Douglas Anderson <dianders@chromium.org>
To: Andrzej Hajda <a.hajda@samsung.com>,
Neil Armstrong <narmstrong@baylibre.com>
Cc: robdclark@chromium.org, linux-arm-msm@vger.kernel.org,
seanpaul@chromium.org, bjorn.andersson@linaro.org,
Douglas Anderson <dianders@chromium.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: [PATCH 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other low res DP
Date: Fri, 13 Dec 2019 15:45:21 -0800 [thread overview]
Message-ID: <20191213234530.145963-1-dianders@chromium.org> (raw)
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(-)
--
2.24.1.735.g03f4e72817-goog
next reply other threads:[~2019-12-13 23:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 23:45 Douglas Anderson [this message]
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
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=20191213234530.145963-1-dianders@chromium.org \
--to=dianders@chromium.org \
--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 \
--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
Powered by JetHome