[PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

Thu Jan 9 16:46:48 UTC 2020

On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher <alexdeucher at gmail.com> wrote:

> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> <mario.kleiner.de at gmail.com> wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
>
> Would it make more sense to just add a quirk for this particular
> panel?  Would there be cases where the link was programmed wrong and
> then we end up using that additional link speed as supported?
>
> Alex
>
>
Not sure. This MBP 2017 is the only non-ancient laptop i now have. I'd
assume many other Apple Retina panels would behave similar. The panels dpcd
regs report DP 1.1 and eDP 1.3, so the flexible table with additional modes
from eDP1.4+ does not exist. According to Wikipedia, eDP 1.4 was introduced
in february 2013 and this is a mid 2017 machine, so Apple seems to be quite
behind. Therefore i assume  we'd need a lot of quirks over time.

That said:

1. The logic in amdgpu's DC for the same purpose is a bit different than on
the intel side.

2. DC allows overriding DP link settings, that's how i initially tested
this, so one could do the "quirk" via something like that in a bootup
script. So on AMD one could work around the lack of the patch and of quirks.

3. I spent a lot of time with a photo-meter, testing the quality of the 10
bit: It turns out that running the panel at 8 bit + AMD's spatial dithering
that kicks in gives better results than running the panel in native 10 bit.
Maybe the panel is not really a 10 bit one, but just pretends to be and
then uses its own dithering to achieve 10 bit. So at least on AMD one is
better off precision-wise with the 8 bit panel default with this specific
panel.

On Intel however, we don't do dithering for > 6 bpc panels atm., so using
the panel at 10 bpc is the only way to get 10 bit display atm. Adn we don't
use dithering on Intel at > 6 bpc panels atm., because there are some
oddities in the way Intel hw dithers at higher bit depths - it also dithers
pixel values where it shouldn't. That makes it impossible to get an
identity passthrough of a 8 bpc framebuffer to the outputs, which kills all
kind of special display equipment that needs that identity passthrough to
work.

-mario

>
> > Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
> > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> >         struct drm_i915_private *dev_priv =
> >                 to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > +       int max_rate;
> > +       u8 link_bw;
> >
> >         /* this function is meant to be called only once */
> >         WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >         else
> >                 intel_dp_set_sink_rates(intel_dp);
> >
> > +       /*
> > +        * If the firmware programmed a rate higher than the standard
> sink rates
> > +        * during boot, then add that rate as a valid sink rate, as fw
> knows
> > +        * this is a good rate and we get extra bandwidth.
> > +        *
> > +        * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which
> is only
> > +        * eDP 1.1, but supports the unusual rate of 324000 kHz at
> bootup, for
> > +        * 10 bpc / 30 bit color depth.
> > +        */
> > +       if (!intel_dp->use_rate_select &&
> > +           (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw,
> 1) == 1) &&
> > +           (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> > +               max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > +               if (max_rate >
> intel_dp->sink_rates[intel_dp->num_sink_rates - 1]) {
> > +                       intel_dp->sink_rates[intel_dp->num_sink_rates] =
> max_rate;
> > +                       intel_dp->num_sink_rates++;
> > +                       DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d
> kHz.\n",
> > +                                     max_rate);
> > +               }
> > +       }
> > +
> >         intel_dp_set_common_rates(intel_dp);
> >
> >         /* Read the eDP DSC DPCD registers */
> > --
> > 2.24.0
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200109/5285d697/attachment-0001.htm>