From: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Cc: "Saarinen, Jani" <jani.saarinen@intel.com>,
"Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Syrjala, Ville" <ville.syrjala@intel.com>
Subject: Re: [PATCH v8 4/4] drm/i915/display: handle systems with duplicate qgv/psf gv points
Date: Mon, 25 Mar 2024 16:11:27 +0000 [thread overview]
Message-ID: <e5cf6ed3867e04c645bc1103b9ce1f4a0e65db68.camel@intel.com> (raw)
In-Reply-To: <ZgGSKCaoUUieIja5@intel.com>
Hi Ville,
On Mon, 2024-03-25 at 17:03 +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 03:01:56PM +0200, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> >
> > There could be multiple qgv and psf gv points with similar values
> > In case if we need to set one such QGV or psf gv point where there
> > could be duplicate entries, we would have to select all those
> > points. Otherwise pcode might reject the GV configuration. We do
> > handle this when we set appropriate qgv and psf gv as part of
> > intel_bw_atomic_check calls. But during the bw_init force disable
> > QGV points phase, we need to select all those points corresponding
> > to the maximum bw as well.
> >
> > v1: - use the same treatment to qgv points as well (Vinod)
> >
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 844d2d9efeb4..20c67474154e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -847,6 +847,8 @@ static unsigned int icl_max_bw_qgv_point_mask(struct drm_i915_private *i915,
> > if (max_data_rate > max_bw) {
> > max_bw_point_mask = BIT(i);
> > max_bw = max_data_rate;
> > + } else if (max_data_rate == max_bw) {
> > + max_bw_point_mask |= BIT(i);
> > }
> > }
> >
> > @@ -866,6 +868,8 @@ static unsigned int icl_max_bw_psf_gv_point_mask(struct drm_i915_private
> > *i915)
> > if (max_data_rate > max_bw) {
> > max_bw_point_mask = BIT(i);
> > max_bw = max_data_rate;
> > + } else if (max_data_rate == max_bw) {
> > + max_bw_point_mask |= BIT(i);
>
> This doesn't seem entirely safe. What happens if we somehow
> have two qgv points with the same bandwidth but different
> uderlying clock/gear ratio/etc.?
>
> While such behaviour may not seem entirely sensible, given
> that we need to do this stuff at all, I don't think we can
> assume any kind of sensible behaviour from pcode here.
>
> So I think we will need to check that the qgv points
> being used here are in fact 100% identical.
Main thing is we need to match the comparison what pcode is doing.. right?
We compare the deratedbw of different QGV points calculated using the rest of the information
provided as part of qgv info. I assume pcode is also going to do the same kind of comparison or that
is what I understood from one of the email conversation.
Do you want this clarified from pcode team?
BR
vinod
>
> > }
> > }
> >
> > --
> > 2.34.1
>
next prev parent reply other threads:[~2024-03-25 16:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 13:01 [PATCH v8 0/4] QGV/SAGV related fixes Vinod Govindapillai
2024-03-25 13:01 ` [PATCH v8 1/4] drm/i915: Add meaningful traces for QGV point info error handling Vinod Govindapillai
2024-03-25 13:01 ` [PATCH v8 2/4] drm/i915: Extract code required to calculate max qgv/psf gv point Vinod Govindapillai
2024-03-25 13:01 ` [PATCH v8 3/4] drm/i915: Disable SAGV on bw init, to force QGV point recalculation Vinod Govindapillai
2024-03-25 13:01 ` [PATCH v8 4/4] drm/i915/display: handle systems with duplicate qgv/psf gv points Vinod Govindapillai
2024-03-25 15:03 ` Ville Syrjälä
2024-03-25 16:11 ` Govindapillai, Vinod [this message]
2024-03-25 16:17 ` Ville Syrjälä
2024-03-25 15:44 ` ✗ Fi.CI.CHECKPATCH: warning for QGV/SAGV related fixes (rev8) Patchwork
2024-03-25 15:44 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-03-25 15:56 ` ✗ Fi.CI.BAT: failure " 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=e5cf6ed3867e04c645bc1103b9ce1f4a0e65db68.camel@intel.com \
--to=vinod.govindapillai@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.saarinen@intel.com \
--cc=stanislav.lisovskiy@intel.com \
--cc=ville.syrjala@intel.com \
--cc=ville.syrjala@linux.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