From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: intel-gfx@lists.freedesktop.org, ville.syrjala@intel.com,
martin.peres@intel.com
Subject: Re: [PATCH v2] drm/i915: Add TigerLake bandwidth checking
Date: Wed, 18 Sep 2019 16:29:11 +0300 [thread overview]
Message-ID: <20190918132911.GJ1208@intel.com> (raw)
In-Reply-To: <20190918092201.679-1-stanislav.lisovskiy@intel.com>
On Wed, Sep 18, 2019 at 12:22:01PM +0300, Stanislav Lisovskiy wrote:
> Added bandwidth calculation algorithm and checks,
> similar way as it was done for ICL, some constants
> were corrected according to BSpec.
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
>
> v2: Start using same icl_get_bw_info function to avoid
> code duplication. Moved mpagesize to memory info
> related structure as it is now dependant on memory type.
> Fixed qi.t_bl field assignment.
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111600
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 31 ++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index 688858ebe4d0..c89fcdccac7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -19,6 +19,7 @@ struct intel_qgv_info {
> u8 num_points;
> u8 num_channels;
> u8 t_bl;
> + u8 mpagesize;
Looks like we're not using this at all. Probably easier to just rip it out
entirely.
> enum intel_dram_type dram_type;
> };
>
> @@ -56,7 +57,13 @@ static int icl_pcode_read_mem_global_info(struct drm_i915_private *dev_priv,
> qi->num_channels = (val & 0xf0) >> 4;
> qi->num_points = (val & 0xf00) >> 8;
>
> - qi->t_bl = qi->dram_type == INTEL_DRAM_DDR4 ? 4 : 8;
> + if (IS_GEN(dev_priv, 11)) {
> + qi->mpagesize = 16;
> + qi->t_bl = qi->dram_type == INTEL_DRAM_DDR4 ? 4 : 8;
> + } else if (IS_GEN(dev_priv, 12)) {
> + qi->mpagesize = qi->dram_type == INTEL_DRAM_DDR4 ? 16 : 32;
> + qi->t_bl = qi->dram_type == INTEL_DRAM_DDR4 ? 4 : 16;
> + }
>
> return 0;
> }
> @@ -132,20 +139,26 @@ static int icl_sagv_max_dclk(const struct intel_qgv_info *qi)
> }
>
> struct intel_sa_info {
> - u8 deburst, mpagesize, deprogbwlimit, displayrtids;
> + u16 displayrtids;
> + u8 deburst, deprogbwlimit;
> };
>
> static const struct intel_sa_info icl_sa_info = {
> .deburst = 8,
> - .mpagesize = 16,
> .deprogbwlimit = 25, /* GB/s */
> .displayrtids = 128,
> };
>
> -static int icl_get_bw_info(struct drm_i915_private *dev_priv)
> +static const struct intel_sa_info tgl_sa_info = {
> + .deburst = 16,
> + .deprogbwlimit = 34, /* GB/s */
> + .displayrtids = 256,
> +};
> +
> +
Double newline. checkpatch should have complained I think.
> +static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct intel_sa_info *sa)
> {
> struct intel_qgv_info qi = {};
> - const struct intel_sa_info *sa = &icl_sa_info;
> bool is_y_tile = true; /* assume y tile may be used */
> int num_channels;
> int deinterleave;
> @@ -234,7 +247,9 @@ static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
> void intel_bw_init_hw(struct drm_i915_private *dev_priv)
> {
> if (IS_GEN(dev_priv, 11))
> - icl_get_bw_info(dev_priv);
> + icl_get_bw_info(dev_priv, &icl_sa_info);
> + else if (IS_GEN(dev_priv, 12))
> + icl_get_bw_info(dev_priv, &tgl_sa_info);
The usual approach is to put the newer platform first.
> }
>
> static unsigned int intel_max_data_rate(struct drm_i915_private *dev_priv,
> @@ -249,6 +264,10 @@ static unsigned int intel_max_data_rate(struct drm_i915_private *dev_priv,
> return min3(icl_max_bw(dev_priv, num_planes, 0),
> icl_max_bw(dev_priv, num_planes, 1),
> icl_max_bw(dev_priv, num_planes, 2));
> + else if (IS_GEN(dev_priv, 12))
> + return min3(icl_max_bw(dev_priv, num_planes, 0),
> + icl_max_bw(dev_priv, num_planes, 1),
> + icl_max_bw(dev_priv, num_planes, 2));
Why add another identical branch?
> else
> return UINT_MAX;
> }
> --
> 2.17.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2019-09-18 13:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 9:22 [PATCH v2] drm/i915: Add TigerLake bandwidth checking Stanislav Lisovskiy
2019-09-18 10:39 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add TigerLake bandwidth checking (rev2) Patchwork
2019-09-18 11:01 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-18 13:29 ` Ville Syrjälä [this message]
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=20190918132911.GJ1208@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=martin.peres@intel.com \
--cc=stanislav.lisovskiy@intel.com \
--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