From: Imre Deak <imre.deak@intel.com>
To: Lyude Paul <lyude@redhat.com>
Cc: intel-gfx@lists.freedesktop.org,
Ville Syrjala <ville.syrjala@intel.com>,
stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix the MST PBN divider calculation
Date: Tue, 26 Jan 2021 14:06:28 +0200 [thread overview]
Message-ID: <20210126120628.GA1763532@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <f036f8aff9079d97c2997929478621d3be34a69d.camel@redhat.com>
On Mon, Jan 25, 2021 at 05:55:03PM -0500, Lyude Paul wrote:
> On Mon, 2021-01-25 at 23:04 +0200, Imre Deak wrote:
> > On Mon, Jan 25, 2021 at 02:24:58PM -0500, Lyude Paul wrote:
> > > On Mon, 2021-01-25 at 19:36 +0200, Imre Deak wrote:
> > > > Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit)
> > > > value for MST streams if the link parameters (link rate or lane count)
> > > > are limited in a way independent of the sink capabilities (reported by
> > > > DPCD).
> > > >
> > > > One example of such a limitation is when a MUX between the sink and
> > > > source connects only a limited number of lanes to the display and
> > > > connects the rest of the lanes to other peripherals (USB).
> > > >
> > > > Another issue is that atm MST core calculates the divider based on the
> > > > backwards compatible DPCD (at address 0x0000) vs. the extended
> > > > capability info (at address 0x2200). This can result in leaving some
> > > > part of the MST BW unused (For instance in case of the WD19TB dock).
> > > >
> > > > Fix the above two issues by calculating the PBN divider value based on
> > > > the rate and lane count link parameters that the driver uses for all
> > > > other computation.
> > > >
> > > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977
> > > > Cc: Lyude Paul <lyude@redhat.com>
> > > > Cc: Ville Syrjala <ville.syrjala@intel.com>
> > > > Cc: <stable@vger.kernel.org>
> > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index d6a1b961a0e8..b4621ed0127e 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -68,7 +68,9 @@ static int intel_dp_mst_compute_link_config(struct
> > > > intel_encoder *encoder,
> > > >
> > > > slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp-
> > > > > mst_mgr,
> > > > connector->port,
> > > > - crtc_state->pbn, 0);
> > > > + crtc_state->pbn,
> > > > +
> > > > drm_dp_get_vc_payload_bw(crtc_state->port_clock,
> > > > +
> > >
> > > This patch looks fine, however you should take care to also update the
> > > documentation for drm_dp_atomic_find_vcpi_slots() so that it mentiones that
> > > pbn_div should be DSC aware but also is not exclusive to systems supporting
> > > DSC
> > > over MST (see the docs for the @pbn_div parameter)
> >
> > I thought (as a follow-up work) that drm_dp_atomic_find_vcpi_slots() and
> > drm_dp_mst_allocate_vcpi() could be made more generic, requiring the
> > drivers to always pass in pbn_div. By that we could remove
> > mst_mgr::pbn_div, keeping only one copy of this value (the one passed to
> > the above functions).
>
> I'm fine with that! The only thing I ask is (even though it's taken forever) we
> are eventually planning on making it so that we'll have MST helpers that can
> suggest changing the PBN divisor in order to implement link fallback retraining.
> As long as we're still able to make that work in the future, I'm totally fine
> with this.
I don't see a problem wrt. link retraining, pbn_div passed to the above
functions should just reflect the actual rate and lane count the link
was trained with.
> > > Thank you for doing this! I've been meaning to fix the WD19 issues for a
> > > while
> > > now but have been too bogged down by other stuff to spend any time on MST
> > > recently.
> > >
> > > > crtc_state->lane_count));
> > > > if (slots == -EDEADLK)
> > > > return slots;
> > > > if (slots >= 0)
> > >
> > > --
> > > Sincerely,
> > > Lyude Paul (she/her)
> > > Software Engineer at Red Hat
> > >
> > > Note: I deal with a lot of emails and have a lot of bugs on my plate. If
> > > you've
> > > asked me a question, are waiting for a review/merge on a patch, etc. and I
> > > haven't responded in a while, please feel free to send me another email to
> > > check
> > > on my status. I don't bite!
> > >
> >
>
> --
> Sincerely,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
> Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
> asked me a question, are waiting for a review/merge on a patch, etc. and I
> haven't responded in a while, please feel free to send me another email to check
> on my status. I don't bite!
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-01-26 12:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 17:36 [Intel-gfx] [PATCH 1/2] drm/dp/mst: Export drm_dp_get_vc_payload_bw() Imre Deak
2021-01-25 17:36 ` [Intel-gfx] [PATCH 2/2] drm/i915: Fix the MST PBN divider calculation Imre Deak
2021-01-25 19:24 ` Lyude Paul
2021-01-25 21:04 ` Imre Deak
2021-01-25 22:55 ` Lyude Paul
2021-01-26 12:06 ` Imre Deak [this message]
2021-01-28 13:54 ` Ville Syrjälä
2021-01-25 19:22 ` [Intel-gfx] [PATCH 1/2] drm/dp/mst: Export drm_dp_get_vc_payload_bw() Lyude Paul
2021-01-25 19:25 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] " Patchwork
2021-01-25 19:27 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-01-25 19:56 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-01-26 1:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-01-28 19:38 ` Imre Deak
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=20210126120628.GA1763532@ideak-desk.fi.intel.com \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lyude@redhat.com \
--cc=stable@vger.kernel.org \
--cc=ville.syrjala@intel.com \
/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