All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Govindapillai, Vinod" <vinod.govindapillai@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 18:17:17 +0200	[thread overview]
Message-ID: <ZgGjjenPT1WGF4Ev@intel.com> (raw)
In-Reply-To: <e5cf6ed3867e04c645bc1103b9ce1f4a0e65db68.camel@intel.com>

On Mon, Mar 25, 2024 at 04:11:27PM +0000, Govindapillai, Vinod wrote:
> 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?

If pcode is only checking the bandwidth then it might be
technically broken as then we can't be 100% sure we can
actually disable sagv. The only way that can work is if
pcode then never ever switches between two qgv points
that have provide the same bandwidth.

> 
> BR
> vinod
> 
> > 
> > >                 }
> > >         }
> > >  
> > > -- 
> > > 2.34.1
> > 
> 

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2024-03-25 16:17 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
2024-03-25 16:17       ` Ville Syrjälä [this message]
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=ZgGjjenPT1WGF4Ev@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.saarinen@intel.com \
    --cc=stanislav.lisovskiy@intel.com \
    --cc=ville.syrjala@intel.com \
    --cc=vinod.govindapillai@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 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.