On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
<mario.kleiner.de@xxxxxxxxx> wrote:
>
> On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>>
>> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>> <mario.kleiner.de@xxxxxxxxx> 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@xxxxxxxxx>
>> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
>> > ---
>> > 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@xxxxxxxxxxxxxxxxxxxxx
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
