* [PATCH] drm/i915: Handle runtime pm in the CRC setup code
@ 2014-11-24 15:23 Daniel Vetter
2014-11-24 15:36 ` Damien Lespiau
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Daniel Vetter @ 2014-11-24 15:23 UTC (permalink / raw)
To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter
The crc code doesn't handle anything really that could drop the
register state (by design so that we have less complexity). Which
means userspace may only start crc capture once the pipe is fully set
up.
With an i-g-t patch this will be the case, but there's still the
problem that this results in obscure unclaimed register write
failures. Which is a pain to debug.
So instead make sure we don't have the basic unclaimed register write
failure by grabbing runtime pm references. And reject completely
invalid requests with -EIO. This is still racy of course, but for a
test library we don't really care - if userspace shuts down the pipe
right afterwards the entire setup will be lost anyway.
References: https://bugs.freedesktop.org/show_bug.cgi?id=86092
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/i915/i915_debugfs.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 319da61354b0..68a76e58e8fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3309,6 +3309,14 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe,
if (pipe_crc->source && source)
return -EINVAL;
+ intel_runtime_pm_get(dev_priv);
+
+ if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe))) {
+ DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n");
+ ret = -EIO;
+ goto out;
+ }
+
if (IS_GEN2(dev))
ret = i8xx_pipe_crc_ctl_reg(&source, &val);
else if (INTEL_INFO(dev)->gen < 5)
@@ -3321,7 +3329,7 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe,
ret = ivb_pipe_crc_ctl_reg(dev, pipe, &source, &val);
if (ret != 0)
- return ret;
+ goto out;
/* none -> real source transition */
if (source) {
@@ -3331,8 +3339,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe,
pipe_crc->entries = kzalloc(sizeof(*pipe_crc->entries) *
INTEL_PIPE_CRC_ENTRIES_NR,
GFP_KERNEL);
- if (!pipe_crc->entries)
- return -ENOMEM;
+ if (!pipe_crc->entries) {
+ ret = -ENOMEM;
+ goto out;
+ }
/*
* When IPS gets enabled, the pipe CRC changes. Since IPS gets
@@ -3383,8 +3393,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe,
hsw_enable_ips(crtc);
}
+out:
+ intel_runtime_pm_get(dev_priv);
- return 0;
+ return ret;
}
/*
--
2.1.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-24 15:23 [PATCH] drm/i915: Handle runtime pm in the CRC setup code Daniel Vetter @ 2014-11-24 15:36 ` Damien Lespiau 2014-11-24 20:11 ` Daniel Vetter 2014-11-24 20:43 ` Daniel Vetter 2014-11-25 1:20 ` shuang.he 2 siblings, 1 reply; 11+ messages in thread From: Damien Lespiau @ 2014-11-24 15:36 UTC (permalink / raw) To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development On Mon, Nov 24, 2014 at 04:23:36PM +0100, Daniel Vetter wrote: > The crc code doesn't handle anything really that could drop the > register state (by design so that we have less complexity). Which > means userspace may only start crc capture once the pipe is fully set > up. > > With an i-g-t patch this will be the case, but there's still the > problem that this results in obscure unclaimed register write > failures. Which is a pain to debug. > > So instead make sure we don't have the basic unclaimed register write > failure by grabbing runtime pm references. And reject completely > invalid requests with -EIO. This is still racy of course, but for a > test library we don't really care - if userspace shuts down the pipe > right afterwards the entire setup will be lost anyway. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/i915/i915_debugfs.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > index 319da61354b0..68a76e58e8fd 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -3309,6 +3309,14 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, > if (pipe_crc->source && source) > return -EINVAL; > > + intel_runtime_pm_get(dev_priv); Do we need this intel_runtime_pm_get() here? > + if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe))) { > + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n"); > + ret = -EIO; > + goto out; > + } > + > if (IS_GEN2(dev)) > ret = i8xx_pipe_crc_ctl_reg(&source, &val); > else if (INTEL_INFO(dev)->gen < 5) > @@ -3321,7 +3329,7 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, > ret = ivb_pipe_crc_ctl_reg(dev, pipe, &source, &val); > > if (ret != 0) > - return ret; > + goto out; > > /* none -> real source transition */ > if (source) { > @@ -3331,8 +3339,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, > pipe_crc->entries = kzalloc(sizeof(*pipe_crc->entries) * > INTEL_PIPE_CRC_ENTRIES_NR, > GFP_KERNEL); > - if (!pipe_crc->entries) > - return -ENOMEM; > + if (!pipe_crc->entries) { > + ret = -ENOMEM; > + goto out; > + } > > /* > * When IPS gets enabled, the pipe CRC changes. Since IPS gets > @@ -3383,8 +3393,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, > > hsw_enable_ips(crtc); > } > +out: > + intel_runtime_pm_get(dev_priv); That's a second intel_runtime_pm_get(); > > - return 0; > + return ret; > } > > /* > -- > 2.1.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-24 15:36 ` Damien Lespiau @ 2014-11-24 20:11 ` Daniel Vetter 0 siblings, 0 replies; 11+ messages in thread From: Daniel Vetter @ 2014-11-24 20:11 UTC (permalink / raw) To: Damien Lespiau; +Cc: Daniel Vetter, Intel Graphics Development On Mon, Nov 24, 2014 at 4:36 PM, Damien Lespiau <damien.lespiau@intel.com> wrote: > On Mon, Nov 24, 2014 at 04:23:36PM +0100, Daniel Vetter wrote: >> The crc code doesn't handle anything really that could drop the >> register state (by design so that we have less complexity). Which >> means userspace may only start crc capture once the pipe is fully set >> up. >> >> With an i-g-t patch this will be the case, but there's still the >> problem that this results in obscure unclaimed register write >> failures. Which is a pain to debug. >> >> So instead make sure we don't have the basic unclaimed register write >> failure by grabbing runtime pm references. And reject completely >> invalid requests with -EIO. This is still racy of course, but for a >> test library we don't really care - if userspace shuts down the pipe >> right afterwards the entire setup will be lost anyway. >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >> --- >> drivers/gpu/drm/i915/i915_debugfs.c | 20 ++++++++++++++++---- >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c >> index 319da61354b0..68a76e58e8fd 100644 >> --- a/drivers/gpu/drm/i915/i915_debugfs.c >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c >> @@ -3309,6 +3309,14 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, >> if (pipe_crc->source && source) >> return -EINVAL; >> >> + intel_runtime_pm_get(dev_priv); > > > Do we need this intel_runtime_pm_get() here? intel_displaye_power_is_enabled needs it. I'm not sure whether we should move the check for rpm into it or not ... >> + if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe))) { >> + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n"); >> + ret = -EIO; >> + goto out; >> + } >> + >> if (IS_GEN2(dev)) >> ret = i8xx_pipe_crc_ctl_reg(&source, &val); >> else if (INTEL_INFO(dev)->gen < 5) >> @@ -3321,7 +3329,7 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, >> ret = ivb_pipe_crc_ctl_reg(dev, pipe, &source, &val); >> >> if (ret != 0) >> - return ret; >> + goto out; >> >> /* none -> real source transition */ >> if (source) { >> @@ -3331,8 +3339,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, >> pipe_crc->entries = kzalloc(sizeof(*pipe_crc->entries) * >> INTEL_PIPE_CRC_ENTRIES_NR, >> GFP_KERNEL); >> - if (!pipe_crc->entries) >> - return -ENOMEM; >> + if (!pipe_crc->entries) { >> + ret = -ENOMEM; >> + goto out; >> + } >> >> /* >> * When IPS gets enabled, the pipe CRC changes. Since IPS gets >> @@ -3383,8 +3393,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, >> >> hsw_enable_ips(crtc); >> } >> +out: >> + intel_runtime_pm_get(dev_priv); > > > That's a second intel_runtime_pm_get(); Oops, will fix. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-24 15:23 [PATCH] drm/i915: Handle runtime pm in the CRC setup code Daniel Vetter 2014-11-24 15:36 ` Damien Lespiau @ 2014-11-24 20:43 ` Daniel Vetter 2014-11-25 11:00 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he ` (2 more replies) 2014-11-25 1:20 ` shuang.he 2 siblings, 3 replies; 11+ messages in thread From: Daniel Vetter @ 2014-11-24 20:43 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in obscure unclaimed register write failures. Which is a pain to debug. So instead make sure we don't have the basic unclaimed register write failure by grabbing runtime pm references. And reject completely invalid requests with -EIO. This is still racy of course, but for a test library we don't really care - if userspace shuts down the pipe right afterwards the entire setup will be lost anyway. Note that we need the rpm_get/put to make power_is_enabled work properly. v2: Put instead of get, spotted by Damien. Also explain the runtime pm dance. References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 319da61354b0..2758aa64b8fa 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3309,6 +3309,14 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, if (pipe_crc->source && source) return -EINVAL; + intel_runtime_pm_get(dev_priv); + + if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe))) { + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n"); + ret = -EIO; + goto out; + } + if (IS_GEN2(dev)) ret = i8xx_pipe_crc_ctl_reg(&source, &val); else if (INTEL_INFO(dev)->gen < 5) @@ -3321,7 +3329,7 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, ret = ivb_pipe_crc_ctl_reg(dev, pipe, &source, &val); if (ret != 0) - return ret; + goto out; /* none -> real source transition */ if (source) { @@ -3331,8 +3339,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, pipe_crc->entries = kzalloc(sizeof(*pipe_crc->entries) * INTEL_PIPE_CRC_ENTRIES_NR, GFP_KERNEL); - if (!pipe_crc->entries) - return -ENOMEM; + if (!pipe_crc->entries) { + ret = -ENOMEM; + goto out; + } /* * When IPS gets enabled, the pipe CRC changes. Since IPS gets @@ -3383,8 +3393,10 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, hsw_enable_ips(crtc); } +out: + intel_runtime_pm_put(dev_priv); - return 0; + return ret; } /* -- 2.1.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup 2014-11-24 20:43 ` Daniel Vetter @ 2014-11-25 11:00 ` shuang.he 2014-11-25 12:12 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup code Damien Lespiau 2014-11-25 13:08 ` Daniel Vetter 2 siblings, 0 replies; 11+ messages in thread From: shuang.he @ 2014-11-25 11:00 UTC (permalink / raw) To: shuang.he, intel-gfx, daniel.vetter Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) -------------------------------------Summary------------------------------------- Platform Delta drm-intel-nightly Series Applied PNV 367/367 367/367 ILK -4 375/375 371/375 SNB 450/450 450/450 IVB -2 503/503 501/503 BYT 289/289 289/289 HSW -2 567/567 565/567 BDW 417/417 417/417 -------------------------------------Detailed------------------------------------- Platform Test drm-intel-nightly Series Applied ILK igt_gem_reset_stats_close-pending-fork-render TIMEOUT(13, M37M26)PASS(1, M26) TIMEOUT(1, M26) *ILK igt_kms_flip_flip-vs-dpms-off-vs-modeset PASS(2, M37M26) DMESG_WARN(1, M26) ILK igt_kms_flip_plain-flip DMESG_WARN(1, M26)PASS(3, M37M26) DMESG_WARN(1, M26) ILK igt_kms_flip_vblank-vs-hang TIMEOUT(13, M37M26)PASS(1, M26) TIMEOUT(1, M26) IVB igt_gem_bad_reloc_negative-reloc NSPT(14, M34M21M4)PASS(1, M21) NSPT(1, M34) IVB igt_gem_bad_reloc_negative-reloc-lut NSPT(3, M21M34M4)PASS(15, M21M34M4) NSPT(1, M34) HSW igt_gem_bad_reloc_negative-reloc-lut NSPT(24, M40M20M19)PASS(1, M20) NSPT(1, M20) *HSW igt_pm_rc6_residency_rc6-accuracy PASS(25, M20M40M19) FAIL(1, M20) Note: You need to pay more attention to line start with '*' _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-24 20:43 ` Daniel Vetter 2014-11-25 11:00 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he @ 2014-11-25 12:12 ` Damien Lespiau 2014-11-25 12:58 ` Daniel Vetter 2014-11-25 13:08 ` Daniel Vetter 2 siblings, 1 reply; 11+ messages in thread From: Damien Lespiau @ 2014-11-25 12:12 UTC (permalink / raw) To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development On Mon, Nov 24, 2014 at 09:43:12PM +0100, Daniel Vetter wrote: > Note that we need the rpm_get/put to make power_is_enabled work > properly. I still don't get that. intel_display_power_is_enabled() only checks for states kept in dev_priv. In particular, it doesn't touch the hardware and it looks at dev_priv->pm.suspended. So it seems we should be covered? -- amien _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-25 12:12 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup code Damien Lespiau @ 2014-11-25 12:58 ` Daniel Vetter 0 siblings, 0 replies; 11+ messages in thread From: Daniel Vetter @ 2014-11-25 12:58 UTC (permalink / raw) To: Damien Lespiau; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter On Tue, Nov 25, 2014 at 12:12:35PM +0000, Damien Lespiau wrote: > On Mon, Nov 24, 2014 at 09:43:12PM +0100, Daniel Vetter wrote: > > Note that we need the rpm_get/put to make power_is_enabled work > > properly. > > I still don't get that. intel_display_power_is_enabled() only checks for > states kept in dev_priv. In particular, it doesn't touch the hardware > and it looks at dev_priv->pm.suspended. So it seems we should be > covered? Hm, mixup on my side - we indeed don't check the hw state. Somehow the check_power_well_state thing confused me. I'll rip the get/put out. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-24 20:43 ` Daniel Vetter 2014-11-25 11:00 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he 2014-11-25 12:12 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup code Damien Lespiau @ 2014-11-25 13:08 ` Daniel Vetter 2014-11-25 13:33 ` Damien Lespiau 2014-11-26 7:32 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he 2 siblings, 2 replies; 11+ messages in thread From: Daniel Vetter @ 2014-11-25 13:08 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in obscure unclaimed register write failures. Which is a pain to debug. So instead make sure we don't have the basic unclaimed register write failure by grabbing runtime pm references. And reject completely invalid requests with -EIO. This is still racy of course, but for a test library we don't really care - if userspace shuts down the pipe right afterwards the entire setup will be lost anyway. v2: Put instead of get, spotted by Damien. Also explain the runtime pm dance. v3: There's really no need for rpm get/put since power_is_enabled only checks software state (Damien). References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 Cc: Damien Lespiau <damien.lespiau@intel.com> Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index b50458360a2d..1da809fcc1df 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3344,6 +3344,11 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, if (pipe_crc->source && source) return -EINVAL; + if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe))) { + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n"); + return -EIO; + } + if (IS_GEN2(dev)) ret = i8xx_pipe_crc_ctl_reg(&source, &val); else if (INTEL_INFO(dev)->gen < 5) -- 2.1.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup code 2014-11-25 13:08 ` Daniel Vetter @ 2014-11-25 13:33 ` Damien Lespiau 2014-11-26 7:32 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he 1 sibling, 0 replies; 11+ messages in thread From: Damien Lespiau @ 2014-11-25 13:33 UTC (permalink / raw) To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development On Tue, Nov 25, 2014 at 02:08:10PM +0100, Daniel Vetter wrote: > The crc code doesn't handle anything really that could drop the > register state (by design so that we have less complexity). Which > means userspace may only start crc capture once the pipe is fully set > up. > > With an i-g-t patch this will be the case, but there's still the > problem that this results in obscure unclaimed register write > failures. Which is a pain to debug. > > So instead make sure we don't have the basic unclaimed register write > failure by grabbing runtime pm references. And reject completely > invalid requests with -EIO. This is still racy of course, but for a > test library we don't really care - if userspace shuts down the pipe > right afterwards the entire setup will be lost anyway. > > v2: Put instead of get, spotted by Damien. Also explain the runtime pm > dance. > > v3: There's really no need for rpm get/put since power_is_enabled only > checks software state (Damien). > > References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 > Cc: Damien Lespiau <damien.lespiau@intel.com> > Tested-by: lu hua <huax.lu@intel.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> > --- > drivers/gpu/drm/i915/i915_debugfs.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > index b50458360a2d..1da809fcc1df 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -3344,6 +3344,11 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, > if (pipe_crc->source && source) > return -EINVAL; > > + if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe))) { > + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n"); > + return -EIO; > + } > + > if (IS_GEN2(dev)) > ret = i8xx_pipe_crc_ctl_reg(&source, &val); > else if (INTEL_INFO(dev)->gen < 5) > -- > 2.1.1 > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup 2014-11-25 13:08 ` Daniel Vetter 2014-11-25 13:33 ` Damien Lespiau @ 2014-11-26 7:32 ` shuang.he 1 sibling, 0 replies; 11+ messages in thread From: shuang.he @ 2014-11-26 7:32 UTC (permalink / raw) To: shuang.he, intel-gfx, daniel.vetter Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) -------------------------------------Summary------------------------------------- Platform Delta drm-intel-nightly Series Applied PNV 366/366 366/366 ILK -2 371/371 369/371 SNB -1 450/450 449/450 IVB 498/498 498/498 BYT 289/289 289/289 HSW 564/564 564/564 BDW 417/417 417/417 -------------------------------------Detailed------------------------------------- Platform Test drm-intel-nightly Series Applied ILK igt_gem_reset_stats_close-pending-fork-render TIMEOUT(18, M37M26)PASS(1, M26) TIMEOUT(1, M37) ILK igt_kms_flip_vblank-vs-hang TIMEOUT(17, M37M26)PASS(1, M26) TIMEOUT(1, M37) *SNB igt_kms_mmio_vs_cs_flip_setplane_vs_cs_flip PASS(2, M22) DMESG_WARN(1, M22) Note: You need to pay more attention to line start with '*' _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Handle runtime pm in the CRC setup 2014-11-24 15:23 [PATCH] drm/i915: Handle runtime pm in the CRC setup code Daniel Vetter 2014-11-24 15:36 ` Damien Lespiau 2014-11-24 20:43 ` Daniel Vetter @ 2014-11-25 1:20 ` shuang.he 2 siblings, 0 replies; 11+ messages in thread From: shuang.he @ 2014-11-25 1:20 UTC (permalink / raw) To: shuang.he, intel-gfx, daniel.vetter Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) -------------------------------------Summary------------------------------------- Platform Delta drm-intel-nightly Series Applied PNV 367/367 367/367 ILK -7 375/375 368/375 SNB -18 450/450 432/450 IVB -6 503/503 497/503 BYT 289/289 289/289 HSW -23 567/567 544/567 BDW 417/417 417/417 -------------------------------------Detailed------------------------------------- Platform Test drm-intel-nightly Series Applied ILK igt_gem_reset_stats_close-pending-fork-render TIMEOUT(8, M37M26)PASS(1, M26) TIMEOUT(1, M26) ILK igt_kms_flip_nonexisting-fb DMESG_WARN(2, M26)PASS(2, M37M26) DMESG_WARN(1, M26) ILK igt_kms_pipe_crc_basic_bad-nb-words-3 PASS(2, M37M26) DMESG_WARN(1, M26) ILK igt_kms_render_direct-render PASS(3, M37M26) DMESG_WARN(1, M26) ILK igt_kms_flip_rcs-flip-vs-modeset-interruptible PASS(2, M37M26) DMESG_WARN(1, M26) ILK igt_kms_flip_vblank-vs-hang TIMEOUT(8, M37M26)PASS(1, M26) TIMEOUT(1, M26) ILK igt_kms_flip_wf_vblank-ts-check-interruptible DMESG_WARN(1, M26)PASS(3, M37M26) DMESG_WARN(1, M26) SNB igt_pm_rpm_cursor PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_cursor-dpms PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_debugfs-forcewake-user PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_dpms-mode-unset-non-lpsp PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_dpms-non-lpsp PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_drm-resources-equal PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_fences PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_fences-dpms PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_gem-execbuf PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_gem-idle PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_gem-mmap-cpu PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_gem-mmap-gtt PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_gem-pread PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_i2c PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_modeset-non-lpsp PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_pci-d3-state PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_reg-read-ioctl PASS(2, M22M35) FAIL(1, M35) SNB igt_pm_rpm_rte PASS(2, M22M35) FAIL(1, M35) IVB igt_gem_bad_reloc_negative-reloc NSPT(13, M34M21M4)PASS(1, M21) NSPT(1, M34) IVB igt_gem_bad_reloc_negative-reloc-lut NSPT(3, M21M34M4)PASS(14, M21M34M4) NSPT(1, M34) IVB igt_kms_plane_plane-panning-bottom-right-pipe-C-plane-2 PASS(2, M21M34) DMESG_WARN(1, M34) IVB igt_kms_plane_plane-panning-top-left-pipe-C-plane-1 PASS(3, M21M34) DMESG_WARN(1, M34) IVB igt_kms_plane_plane-position-covered-pipe-C-plane-1 PASS(3, M21M34) DMESG_WARN(1, M34) IVB igt_kms_plane_plane-position-hole-pipe-C-plane-1 PASS(3, M21M34) DMESG_WARN(1, M34) HSW igt_gem_bad_reloc_negative-reloc-lut NSPT(23, M40M20M19)PASS(1, M20) NSPT(1, M19) HSW igt_kms_flip_vblank-vs-dpms-rpm PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rc6_residency_rc6-accuracy PASS(24, M20M40M19) FAIL(1, M19) HSW igt_pm_rpm_cursor PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_cursor-dpms PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_debugfs-forcewake-user PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_debugfs-read PASS(4, M20M40M19) FAIL(1, M19) HSW igt_pm_rpm_dpms-mode-unset-non-lpsp PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_dpms-non-lpsp PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_drm-resources-equal PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_fences PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_fences-dpms PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_gem-execbuf PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_gem-idle PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_gem-mmap-cpu PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_gem-mmap-gtt PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_gem-pread PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_i2c PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_modeset-non-lpsp PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_pci-d3-state PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_reg-read-ioctl PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_rte PASS(2, M20M19) FAIL(1, M19) HSW igt_pm_rpm_sysfs-read PASS(2, M20M19) FAIL(1, M19) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-11-26 7:32 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-24 15:23 [PATCH] drm/i915: Handle runtime pm in the CRC setup code Daniel Vetter 2014-11-24 15:36 ` Damien Lespiau 2014-11-24 20:11 ` Daniel Vetter 2014-11-24 20:43 ` Daniel Vetter 2014-11-25 11:00 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he 2014-11-25 12:12 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup code Damien Lespiau 2014-11-25 12:58 ` Daniel Vetter 2014-11-25 13:08 ` Daniel Vetter 2014-11-25 13:33 ` Damien Lespiau 2014-11-26 7:32 ` [PATCH] drm/i915: Handle runtime pm in the CRC setup shuang.he 2014-11-25 1:20 ` shuang.he
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox