From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Roper, Matthew D" <matthew.d.roper@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Power management SAGV/QGV calculation rounding fix
Date: Wed, 15 Mar 2023 09:49:41 +0200 [thread overview]
Message-ID: <ZBF4ld2EIvTjK28i@intel.com> (raw)
In-Reply-To: <9ffb0ff303cb4141e71a2766f14ec746988c42db.camel@intel.com>
On Tue, Mar 14, 2023 at 11:50:20AM +0200, Govindapillai, Vinod wrote:
> Hi Stan
>
> Few other places also do not ceil the result as per the 64631
>
> deinterleave, peakbw, clperchgroup
>
> Well! I am not sure if this has any real impact, but FYI
As per BSpec we are now supposed to floor all the calculations, but
not ceil - bw estimation should be rather pessimistic than optimistic.
Stan
>
> Vinod
>
> On Tue, 2023-03-14 at 11:27 +0200, Govindapillai, Vinod wrote:
> > Hi Stan,
> >
> >
> >
> > On Fri, 2023-03-10 at 16:40 +0200, Stanislav Lisovskiy wrote:
> > > Currently in our bandwidth calculations for QGV
> > > points we round up the calculations.
> > > Recently there was an update to BSpec, recommending
> > > to floor those calculations.
> > > The reasoning behind this was that, overestimating
> > > BW demand with that rounding can cause SAGV to use
> > > next QGV point, even though the less demanding could
> > > be used, thus resulting in waste of power.
> > >
> > > BSpec: 64636
> > >
> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.c | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 202321ffbe2a..8723ddd4d568 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -50,7 +50,7 @@ static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv,
> > > dclk_reference = 6; /* 6 * 16.666 MHz = 100 MHz */
> > > else
> > > dclk_reference = 8; /* 8 * 16.666 MHz = 133 MHz */
> > > - sp->dclk = DIV_ROUND_UP((16667 * dclk_ratio * dclk_reference) + 500, 1000);
> > > + sp->dclk = ((16667 * dclk_ratio * dclk_reference) + 500) / 1000;
> > >
> > > val = intel_uncore_read(&dev_priv->uncore, SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
> > > if (val & DG1_GEAR_TYPE)
> > > @@ -87,7 +87,7 @@ static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
> > > return ret;
> > >
> > > dclk = val & 0xffff;
> > > - sp->dclk = DIV_ROUND_UP((16667 * dclk) + (DISPLAY_VER(dev_priv) > 11 ? 500 : 0), 1000);
> > > + sp->dclk = ((16667 * dclk) + (DISPLAY_VER(dev_priv) > 11 ? 500 : 0)) / 1000;
> > > sp->t_rp = (val & 0xff0000) >> 16;
> > > sp->t_rcd = (val & 0xff000000) >> 24;
> > >
> > > @@ -179,7 +179,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv,
> > > val2 = intel_uncore_read(&dev_priv->uncore,
> > > MTL_MEM_SS_INFO_QGV_POINT_HIGH(point));
> > > dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
> > > - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000);
> > > + sp->dclk = (16667 * dclk) / 1000;
> >
> > Not related to this patch. But as per Bspec 64631 and 64636
> > sp->dclk = (16667 * dclk + 500) / 1000;
> >
> > Does that need to be corrected as well?
> >
> > BR
> > vinod
> >
> >
> > > sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
> > > sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
> > >
> > > @@ -425,7 +425,7 @@ static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct
> > > intel
> > > */
> > > ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd +
> > > (clpchgroup - 1) * qi.t_bl + sp->t_rdpre);
> > > - bw = DIV_ROUND_UP(sp->dclk * clpchgroup * 32 * num_channels, ct);
> > > + bw = (sp->dclk * clpchgroup * 32 * num_channels) / ct;
> > >
> > > bi->deratedbw[j] = min(maxdebw,
> > > bw * (100 - sa->derating) / 100);
> > > @@ -527,7 +527,7 @@ static int tgl_get_bw_info(struct drm_i915_private *dev_priv, const struct
> > > intel
> > > */
> > > ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd +
> > > (clpchgroup - 1) * qi.t_bl + sp->t_rdpre);
> > > - bw = DIV_ROUND_UP(sp->dclk * clpchgroup * 32 * num_channels, ct);
> > > + bw = (sp->dclk * clpchgroup * 32 * num_channels) / ct;
> > >
> > > bi->deratedbw[j] = min(maxdebw,
> > > bw * (100 - sa->derating) / 100);
> >
>
next prev parent reply other threads:[~2023-03-15 7:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 14:40 [Intel-gfx] [PATCH] drm/i915: Power management SAGV/QGV calculation rounding fix Stanislav Lisovskiy
2023-03-14 9:27 ` Govindapillai, Vinod
2023-03-14 9:50 ` Govindapillai, Vinod
2023-03-15 7:49 ` Lisovskiy, Stanislav [this message]
2023-03-15 7:54 ` Lisovskiy, Stanislav
2023-03-15 9:08 ` Govindapillai, Vinod
2023-03-15 9:38 ` Lisovskiy, Stanislav
2023-03-15 9:58 ` Lisovskiy, Stanislav
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=ZBF4ld2EIvTjK28i@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.d.roper@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox