From: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
To: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Roper, Matthew D" <matthew.d.roper@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Power management SAGV/QGV calculation rounding fix
Date: Tue, 14 Mar 2023 09:50:20 +0000 [thread overview]
Message-ID: <9ffb0ff303cb4141e71a2766f14ec746988c42db.camel@intel.com> (raw)
In-Reply-To: <7ddeaf24abf10e7e2728150310e154f4366a076c.camel@intel.com>
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
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-14 9:50 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 [this message]
2023-03-15 7:49 ` Lisovskiy, Stanislav
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=9ffb0ff303cb4141e71a2766f14ec746988c42db.camel@intel.com \
--to=vinod.govindapillai@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.d.roper@intel.com \
--cc=stanislav.lisovskiy@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