* [PATCH] drm/i915: Include register polling in reg_rw traces
@ 2019-02-04 21:16 Ville Syrjala
2019-02-04 21:33 ` Chris Wilson
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Ville Syrjala @ 2019-02-04 21:16 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
We generally omit register polling from the i915_reg_rw tracepoint.
Understandable since polling could generate a lot of noise in the
trace. The downside is that the trace is incomplete. As a compromise
let's trace the final register value observed while polling. That
should be generally sufficient to observe what the code should be
doing next.
I suppose in some cases it might make sense to also trace the initial
register value, and maybe the number of times we polled. But that
would require a separate tracepoint so let's leave it for the future.
The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
which I decided to leave alone.
Next we should do something to claw back the tracepoints for
planes and whatnot which were switched to _FW() a while back.
I guess just new macros for raw_rw+trace. The question is
what to call it?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++++++++++--
drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
drivers/gpu/drm/i915/intel_uncore.c | 3 +++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7aaa1ac4c99..7de90701f6f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2543,6 +2543,10 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
u32 mask, u32 val)
{
+ i915_reg_t reg = VLV_GTLC_PW_STATUS;
+ u32 reg_value;
+ int ret;
+
/* The HW does not like us polling for PW_STATUS frequently, so
* use the sleeping loop rather than risk the busy spin within
* intel_wait_for_register().
@@ -2550,8 +2554,12 @@ static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
* Transitioning between RC6 states should be at most 2ms (see
* valleyview_enable_rps) so use a 3ms timeout.
*/
- return wait_for((I915_READ_NOTRACE(VLV_GTLC_PW_STATUS) & mask) == val,
- 3);
+ ret = wait_for(((reg_value = I915_READ_NOTRACE(reg)) & mask) == val, 3);
+
+ /* just trace the final value */
+ trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
+
+ return ret;
}
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..36e3d99abc2b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1061,6 +1061,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
+
+ /* just trace the final value */
+ trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
+
if (!done)
DRM_ERROR("dp aux hw did not signal timeout!\n");
#undef C
@@ -1227,6 +1231,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
break;
msleep(1);
}
+ /* just trace the final value */
+ trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
if (try == 3) {
static u32 last_status = -1;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index e88f0252d77e..75646a1e0051 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1819,6 +1819,9 @@ int __intel_wait_for_register(struct drm_i915_private *dev_priv,
(reg_value & mask) == value,
slow_timeout_ms * 1000, 10, 1000);
+ /* just trace the final value */
+ trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
+
if (out_value)
*out_value = reg_value;
--
2.19.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] drm/i915: Include register polling in reg_rw traces
2019-02-04 21:16 [PATCH] drm/i915: Include register polling in reg_rw traces Ville Syrjala
@ 2019-02-04 21:33 ` Chris Wilson
2019-02-05 18:58 ` Ville Syrjälä
2019-02-04 21:47 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-02-04 22:39 ` ✓ Fi.CI.IGT: " Patchwork
2 siblings, 1 reply; 5+ messages in thread
From: Chris Wilson @ 2019-02-04 21:33 UTC (permalink / raw)
To: Ville Syrjala, intel-gfx
Quoting Ville Syrjala (2019-02-04 21:16:44)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We generally omit register polling from the i915_reg_rw tracepoint.
> Understandable since polling could generate a lot of noise in the
> trace. The downside is that the trace is incomplete. As a compromise
> let's trace the final register value observed while polling. That
> should be generally sufficient to observe what the code should be
> doing next.
Fair compromise; I admit the subject line had me freaking out.
> I suppose in some cases it might make sense to also trace the initial
> register value, and maybe the number of times we polled. But that
> would require a separate tracepoint so let's leave it for the future.
I postulate when you get down to wanting that amount of detail, you
throw in dedicated debug.
> The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
> which I decided to leave alone.
>
> Next we should do something to claw back the tracepoints for
> planes and whatnot which were switched to _FW() a while back.
> I guess just new macros for raw_rw+trace. The question is
> what to call it?
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.c | 12 ++++++++++--
> drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
> drivers/gpu/drm/i915/intel_uncore.c | 3 +++
> 3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7aaa1ac4c99..7de90701f6f1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2543,6 +2543,10 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
> static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
> u32 mask, u32 val)
> {
> + i915_reg_t reg = VLV_GTLC_PW_STATUS;
> + u32 reg_value;
> + int ret;
> +
> /* The HW does not like us polling for PW_STATUS frequently, so
> * use the sleeping loop rather than risk the busy spin within
> * intel_wait_for_register().
> @@ -2550,8 +2554,12 @@ static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
> * Transitioning between RC6 states should be at most 2ms (see
> * valleyview_enable_rps) so use a 3ms timeout.
> */
> - return wait_for((I915_READ_NOTRACE(VLV_GTLC_PW_STATUS) & mask) == val,
> - 3);
> + ret = wait_for(((reg_value = I915_READ_NOTRACE(reg)) & mask) == val, 3);
> +
> + /* just trace the final value */
> + trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
I feel like there's a pattern here that could benefit from a convenient
macro. Nevertheless,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Include register polling in reg_rw traces
2019-02-04 21:16 [PATCH] drm/i915: Include register polling in reg_rw traces Ville Syrjala
2019-02-04 21:33 ` Chris Wilson
@ 2019-02-04 21:47 ` Patchwork
2019-02-04 22:39 ` ✓ Fi.CI.IGT: " Patchwork
2 siblings, 0 replies; 5+ messages in thread
From: Patchwork @ 2019-02-04 21:47 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Include register polling in reg_rw traces
URL : https://patchwork.freedesktop.org/series/56201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12131
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/56201/revisions/1/mbox/
Known issues
------------
Here are the changes found in Patchwork_12131 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
#### Possible fixes ####
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
[fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
[fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (46 -> 43)
------------------------------
Additional (1): fi-icl-y
Missing (4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-------------
* Linux: CI_DRM_5536 -> Patchwork_12131
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12131: 1052a40a1a7d0249b1b80070f82c73d8e642abeb @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1052a40a1a7d drm/i915: Include register polling in reg_rw traces
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12131/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915: Include register polling in reg_rw traces
2019-02-04 21:16 [PATCH] drm/i915: Include register polling in reg_rw traces Ville Syrjala
2019-02-04 21:33 ` Chris Wilson
2019-02-04 21:47 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2019-02-04 22:39 ` Patchwork
2 siblings, 0 replies; 5+ messages in thread
From: Patchwork @ 2019-02-04 22:39 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Include register polling in reg_rw traces
URL : https://patchwork.freedesktop.org/series/56201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536_full -> Patchwork_12131_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_12131_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-b-legacy-gamma-reset:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: PASS -> FAIL [fdo#104873]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: PASS -> FAIL [fdo#102887] / [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-apl: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-apl: PASS -> FAIL [fdo#103166]
#### Possible fixes ####
* igt@gem_pwrite_pread@uncached-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-b-ctm-max:
- shard-apl: FAIL [fdo#108147] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- shard-kbl: DMESG-WARN [fdo#103313] / [fdo#105345] / [fdo#108473] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +3
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
#### Warnings ####
* igt@i915_suspend@shrink:
- shard-kbl: DMESG-WARN [fdo#109244] -> INCOMPLETE [fdo#103665] / [fdo#106886]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105345]: https://bugs.freedesktop.org/show_bug.cgi?id=105345
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (7 -> 5)
------------------------------
Missing (2): shard-skl shard-iclb
Build changes
-------------
* Linux: CI_DRM_5536 -> Patchwork_12131
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12131: 1052a40a1a7d0249b1b80070f82c73d8e642abeb @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12131/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] drm/i915: Include register polling in reg_rw traces
2019-02-04 21:33 ` Chris Wilson
@ 2019-02-05 18:58 ` Ville Syrjälä
0 siblings, 0 replies; 5+ messages in thread
From: Ville Syrjälä @ 2019-02-05 18:58 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Mon, Feb 04, 2019 at 09:33:08PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-02-04 21:16:44)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > We generally omit register polling from the i915_reg_rw tracepoint.
> > Understandable since polling could generate a lot of noise in the
> > trace. The downside is that the trace is incomplete. As a compromise
> > let's trace the final register value observed while polling. That
> > should be generally sufficient to observe what the code should be
> > doing next.
>
> Fair compromise; I admit the subject line had me freaking out.
>
> > I suppose in some cases it might make sense to also trace the initial
> > register value, and maybe the number of times we polled. But that
> > would require a separate tracepoint so let's leave it for the future.
>
> I postulate when you get down to wanting that amount of detail, you
> throw in dedicated debug.
>
> > The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
> > which I decided to leave alone.
> >
> > Next we should do something to claw back the tracepoints for
> > planes and whatnot which were switched to _FW() a while back.
> > I guess just new macros for raw_rw+trace. The question is
> > what to call it?
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 12 ++++++++++--
> > drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
> > drivers/gpu/drm/i915/intel_uncore.c | 3 +++
> > 3 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index a7aaa1ac4c99..7de90701f6f1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -2543,6 +2543,10 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
> > static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
> > u32 mask, u32 val)
> > {
> > + i915_reg_t reg = VLV_GTLC_PW_STATUS;
> > + u32 reg_value;
> > + int ret;
> > +
> > /* The HW does not like us polling for PW_STATUS frequently, so
> > * use the sleeping loop rather than risk the busy spin within
> > * intel_wait_for_register().
> > @@ -2550,8 +2554,12 @@ static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
> > * Transitioning between RC6 states should be at most 2ms (see
> > * valleyview_enable_rps) so use a 3ms timeout.
> > */
> > - return wait_for((I915_READ_NOTRACE(VLV_GTLC_PW_STATUS) & mask) == val,
> > - 3);
> > + ret = wait_for(((reg_value = I915_READ_NOTRACE(reg)) & mask) == val, 3);
> > +
> > + /* just trace the final value */
> > + trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
>
> I feel like there's a pattern here that could benefit from a convenient
> macro.
Entirely possible. I've not yet looked at the current _FW() users
to see if they share the same pattern in any signidicant numbers.
Which brings me back to the topic of what to do with _FW()...
Maybe I should just split _FW() into _FW() and FW_NOTRACE()?
Or if we go the other way, maybe add _FW_TRACE()? Bur all the
plane regs would want _FW_TRACE() which is a bit of an eyesore
if used extensively, so a better name would be nice. Alas,
I've not yet thought of one.
I guess I should first figure out how many instances of each
type there are.
> Nevertheless,
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ta. Pushed.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-02-05 18:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-04 21:16 [PATCH] drm/i915: Include register polling in reg_rw traces Ville Syrjala
2019-02-04 21:33 ` Chris Wilson
2019-02-05 18:58 ` Ville Syrjälä
2019-02-04 21:47 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-02-04 22:39 ` ✓ Fi.CI.IGT: " Patchwork
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.