All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Deucher <alexdeucher@gmail.com>
To: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: mario.kleiner.de@gmail.de,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
Date: Thu, 9 Jan 2020 14:49:12 -0500	[thread overview]
Message-ID: <CADnq5_NPdg8MjQ5cB2aCD+US1Hv+FoP1gqKcA4W2e0pouG8cGQ@mail.gmail.com> (raw)
In-Reply-To: <CAEsyxyjTvuCHHA3D-NJd=aGkHz2d=obSizwGQL8B4k1B7i2jJg@mail.gmail.com>

On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
>
> On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>
>> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>> <mario.kleiner.de@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.
>

As Harry mentioned in the other thread, won't this only work if the
display was brought up by the vbios?  In the suspend/resume case,
won't we just fall back to 2.7Gbps?

Alex

> -mario
>
>> >
>> > Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
>> > Cc: Daniel Vetter <daniel.vetter@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@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID
From: Alex Deucher <alexdeucher@gmail.com>
To: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: mario.kleiner.de@gmail.de,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
Date: Thu, 9 Jan 2020 14:49:12 -0500	[thread overview]
Message-ID: <CADnq5_NPdg8MjQ5cB2aCD+US1Hv+FoP1gqKcA4W2e0pouG8cGQ@mail.gmail.com> (raw)
In-Reply-To: <CAEsyxyjTvuCHHA3D-NJd=aGkHz2d=obSizwGQL8B4k1B7i2jJg@mail.gmail.com>

On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
>
> On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>
>> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>> <mario.kleiner.de@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.
>

As Harry mentioned in the other thread, won't this only work if the
display was brought up by the vbios?  In the suspend/resume case,
won't we just fall back to 2.7Gbps?

Alex

> -mario
>
>> >
>> > Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
>> > Cc: Daniel Vetter <daniel.vetter@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@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-09 19:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:07 Mario Kleiner
2020-01-09 15:07 ` [Intel-gfx] " Mario Kleiner
2020-01-09 15:26 ` Ville Syrjälä
2020-01-09 15:26   ` [Intel-gfx] " Ville Syrjälä
2020-01-09 15:38   ` Ville Syrjälä
2020-01-09 15:38     ` [Intel-gfx] " Ville Syrjälä
2020-01-09 16:30     ` Mario Kleiner
2020-01-09 16:30       ` [Intel-gfx] " Mario Kleiner
2020-01-09 16:47       ` Ville Syrjälä
2020-01-09 16:47         ` [Intel-gfx] " Ville Syrjälä
2020-01-09 17:57         ` Mario Kleiner
2020-01-09 17:57           ` [Intel-gfx] " Mario Kleiner
2020-01-09 18:24           ` Ville Syrjälä
2020-01-09 18:24             ` [Intel-gfx] " Ville Syrjälä
2020-01-09 20:19             ` Mario Kleiner
2020-01-09 20:19               ` [Intel-gfx] " Mario Kleiner
2020-01-10 13:32               ` Ville Syrjälä
2020-01-10 13:32                 ` [Intel-gfx] " Ville Syrjälä
2020-01-10 15:50                 ` Mario Kleiner
2020-01-10 15:50                   ` [Intel-gfx] " Mario Kleiner
2020-01-09 16:31     ` Ville Syrjälä
2020-01-09 16:31       ` [Intel-gfx] " Ville Syrjälä
2020-01-09 16:27   ` Mario Kleiner
2020-01-09 16:27     ` [Intel-gfx] " Mario Kleiner
2020-01-09 15:39 ` Alex Deucher
2020-01-09 15:39   ` [Intel-gfx] " Alex Deucher
2020-01-09 16:46   ` Mario Kleiner
2020-01-09 16:46     ` [Intel-gfx] " Mario Kleiner
2020-01-09 19:49     ` Alex Deucher [this message]
2020-01-09 19:49       ` Alex Deucher
2020-01-09 21:04       ` Mario Kleiner
2020-01-09 21:04         ` [Intel-gfx] " Mario Kleiner
2020-01-09 21:26         ` Harry Wentland
2020-01-09 21:26           ` [Intel-gfx] " Harry Wentland
2020-01-10 16:02           ` Mario Kleiner
2020-01-10 16:02             ` [Intel-gfx] " Mario Kleiner
2020-01-10 18:09           ` Ville Syrjälä
2020-01-10 18:09             ` Ville Syrjälä
2020-01-15 12:34             ` Jani Nikula
2020-01-15 12:34               ` Jani Nikula
2020-01-15 14:17               ` Ville Syrjälä
2020-01-15 14:17                 ` Ville Syrjälä
2020-01-09 23:52 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dp: Add current maximum eDP link rate to sink_rate array. (rev2) Patchwork

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=CADnq5_NPdg8MjQ5cB2aCD+US1Hv+FoP1gqKcA4W2e0pouG8cGQ@mail.gmail.com \
    --to=alexdeucher@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mario.kleiner.de@gmail.com \
    --cc=mario.kleiner.de@gmail.de \
    --subject='Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.