All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: kbuild-all@lists.01.org, chris@chris-wilson.co.uk
Subject: Re: [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes
Date: Mon, 1 Jun 2020 04:03:06 +0800	[thread overview]
Message-ID: <202006010327.mshUuR6X%lkp@intel.com> (raw)
In-Reply-To: <20200526094852.6967-1-stanislav.lisovskiy@intel.com>

Hi Stanislav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-intel/drm-intel-next-queued]
[cannot apply to drm-intel/for-linux-next v5.7-rc7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Fix-wrong-CDCLK-adjustment-changes/20200526-180642
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>


cppcheck warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/display/intel_bw.c:453:36: warning: Uninitialized variable: pipe [uninitvar]
     crtc_bw = &new_bw_state->dbuf_bw[pipe];
                                      ^

vim +453 drivers/gpu/drm/i915/display/intel_bw.c

   430	
   431	int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
   432	{
   433		struct drm_i915_private *dev_priv = to_i915(state->base.dev);
   434		struct intel_bw_state *new_bw_state = NULL;
   435		struct intel_bw_state *old_bw_state = NULL;
   436		const struct intel_crtc_state *crtc_state;
   437		struct intel_crtc *crtc;
   438		int max_bw = 0;
   439		int slice_id;
   440		enum pipe pipe;
   441		int i;
   442	
   443		for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
   444			enum plane_id plane_id;
   445			struct intel_dbuf_bw *crtc_bw;
   446	
   447			new_bw_state = intel_atomic_get_bw_state(state);
   448			if (IS_ERR(new_bw_state))
   449				return PTR_ERR(new_bw_state);
   450	
   451			old_bw_state = intel_atomic_get_old_bw_state(state);
   452	
 > 453			crtc_bw = &new_bw_state->dbuf_bw[pipe];
   454	
   455			memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
   456	
   457			for_each_plane_id_on_crtc(crtc, plane_id) {
   458				const struct skl_ddb_entry *plane_alloc =
   459					&crtc_state->wm.skl.plane_ddb_y[plane_id];
   460				const struct skl_ddb_entry *uv_plane_alloc =
   461					&crtc_state->wm.skl.plane_ddb_uv[plane_id];
   462				unsigned int data_rate = crtc_state->data_rate[plane_id];
   463				unsigned int dbuf_mask = 0;
   464	
   465				dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, plane_alloc);
   466				dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, uv_plane_alloc);
   467	
   468				/*
   469				 * FIXME: To calculate that more properly we probably
   470				 * need to to split per plane data_rate into data_rate_y
   471				 * and data_rate_uv for multiplanar formats in order not
   472				 * to get accounted those twice if they happen to reside
   473				 * on different slices.
   474				 * However for pre-icl this would work anyway because
   475				 * we have only single slice and for icl+ uv plane has
   476				 * non-zero data rate.
   477				 * So in worst case those calculation are a bit
   478				 * pessimistic, which shouldn't pose any significant
   479				 * problem anyway.
   480				 */
   481				for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
   482					crtc_bw->used_bw[slice_id] += data_rate;
   483			}
   484		}
   485	
   486		if (!old_bw_state)
   487			return 0;
   488	
   489		for_each_pipe(dev_priv, pipe) {
   490			struct intel_dbuf_bw *crtc_bw;
   491	
   492			crtc_bw = &new_bw_state->dbuf_bw[pipe];
   493	
   494			for_each_dbuf_slice(slice_id) {
   495				/*
   496				 * Current experimental observations show that contrary
   497				 * to BSpec we get underruns once we exceed 64 * CDCLK
   498				 * for slices in total.
   499				 * As a temporary measure in order not to keep CDCLK
   500				 * bumped up all the time we calculate CDCLK according
   501				 * to this formula for  overall bw consumed by slices.
   502				 */
   503				max_bw += crtc_bw->used_bw[slice_id];
   504			}
   505		}
   506	
   507		new_bw_state->min_cdclk = max_bw / 64;
   508	
   509		if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
   510			int ret = intel_atomic_lock_global_state(&new_bw_state->base);
   511	
   512			if (ret)
   513				return ret;
   514		}
   515	
   516		return 0;
   517	}
   518	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: kbuild test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes
Date: Mon, 01 Jun 2020 04:03:06 +0800	[thread overview]
Message-ID: <202006010327.mshUuR6X%lkp@intel.com> (raw)
In-Reply-To: <20200526094852.6967-1-stanislav.lisovskiy@intel.com>

[-- Attachment #1: Type: text/plain, Size: 4576 bytes --]

Hi Stanislav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-intel/drm-intel-next-queued]
[cannot apply to drm-intel/for-linux-next v5.7-rc7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Fix-wrong-CDCLK-adjustment-changes/20200526-180642
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>


cppcheck warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/display/intel_bw.c:453:36: warning: Uninitialized variable: pipe [uninitvar]
     crtc_bw = &new_bw_state->dbuf_bw[pipe];
                                      ^

vim +453 drivers/gpu/drm/i915/display/intel_bw.c

   430	
   431	int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
   432	{
   433		struct drm_i915_private *dev_priv = to_i915(state->base.dev);
   434		struct intel_bw_state *new_bw_state = NULL;
   435		struct intel_bw_state *old_bw_state = NULL;
   436		const struct intel_crtc_state *crtc_state;
   437		struct intel_crtc *crtc;
   438		int max_bw = 0;
   439		int slice_id;
   440		enum pipe pipe;
   441		int i;
   442	
   443		for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
   444			enum plane_id plane_id;
   445			struct intel_dbuf_bw *crtc_bw;
   446	
   447			new_bw_state = intel_atomic_get_bw_state(state);
   448			if (IS_ERR(new_bw_state))
   449				return PTR_ERR(new_bw_state);
   450	
   451			old_bw_state = intel_atomic_get_old_bw_state(state);
   452	
 > 453			crtc_bw = &new_bw_state->dbuf_bw[pipe];
   454	
   455			memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
   456	
   457			for_each_plane_id_on_crtc(crtc, plane_id) {
   458				const struct skl_ddb_entry *plane_alloc =
   459					&crtc_state->wm.skl.plane_ddb_y[plane_id];
   460				const struct skl_ddb_entry *uv_plane_alloc =
   461					&crtc_state->wm.skl.plane_ddb_uv[plane_id];
   462				unsigned int data_rate = crtc_state->data_rate[plane_id];
   463				unsigned int dbuf_mask = 0;
   464	
   465				dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, plane_alloc);
   466				dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, uv_plane_alloc);
   467	
   468				/*
   469				 * FIXME: To calculate that more properly we probably
   470				 * need to to split per plane data_rate into data_rate_y
   471				 * and data_rate_uv for multiplanar formats in order not
   472				 * to get accounted those twice if they happen to reside
   473				 * on different slices.
   474				 * However for pre-icl this would work anyway because
   475				 * we have only single slice and for icl+ uv plane has
   476				 * non-zero data rate.
   477				 * So in worst case those calculation are a bit
   478				 * pessimistic, which shouldn't pose any significant
   479				 * problem anyway.
   480				 */
   481				for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
   482					crtc_bw->used_bw[slice_id] += data_rate;
   483			}
   484		}
   485	
   486		if (!old_bw_state)
   487			return 0;
   488	
   489		for_each_pipe(dev_priv, pipe) {
   490			struct intel_dbuf_bw *crtc_bw;
   491	
   492			crtc_bw = &new_bw_state->dbuf_bw[pipe];
   493	
   494			for_each_dbuf_slice(slice_id) {
   495				/*
   496				 * Current experimental observations show that contrary
   497				 * to BSpec we get underruns once we exceed 64 * CDCLK
   498				 * for slices in total.
   499				 * As a temporary measure in order not to keep CDCLK
   500				 * bumped up all the time we calculate CDCLK according
   501				 * to this formula for  overall bw consumed by slices.
   502				 */
   503				max_bw += crtc_bw->used_bw[slice_id];
   504			}
   505		}
   506	
   507		new_bw_state->min_cdclk = max_bw / 64;
   508	
   509		if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
   510			int ret = intel_atomic_lock_global_state(&new_bw_state->base);
   511	
   512			if (ret)
   513				return ret;
   514		}
   515	
   516		return 0;
   517	}
   518	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

  parent reply	other threads:[~2020-05-31 20:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  9:48 [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes Stanislav Lisovskiy
2020-05-26 10:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-05-26 13:40 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-05-29 23:57 ` [Intel-gfx] [PATCH v1] " Manasi Navare
2020-06-01  7:49   ` Lisovskiy, Stanislav
2020-06-01 20:37     ` Manasi Navare
2020-05-31 20:03 ` kbuild test robot [this message]
2020-05-31 20:03   ` kbuild test robot
2020-06-01 14:01 ` Dan Carpenter
2020-06-01 14:01   ` Dan Carpenter
2020-06-01 14:01   ` Dan Carpenter
2020-06-01 14:12   ` Lisovskiy, Stanislav
2020-06-01 14:12     ` Lisovskiy, Stanislav
2020-05-31 23:41 kbuild test robot

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=202006010327.mshUuR6X%lkp@intel.com \
    --to=lkp@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kbuild-all@lists.01.org \
    --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 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.