[Intel-gfx] [PATCH] drm/i915/debugfs: Missing intel_runtime_pm_*

[Chris Wilson]

On Thu, Jun 02, 2016 at 11:31:03AM +0300, David Weinehall wrote:
> On Thu, Jun 02, 2016 at 09:15:00AM +0100, Chris Wilson wrote:
> > On Thu, Jun 02, 2016 at 11:02:29AM +0300, David Weinehall wrote:
> > > i915_sseu_status() was missing intel_runtime_pm_{get,put},
> > > meaning that in some cases access to HW would be attempted
> > > while the device is suspended.
> > > 
> > > Testcase: igt/pm_rpm/debugfs-read
> > > Signed-off-by: David Weinehall <david.weinehall at linux.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 e4f2c55d9697..694b0d394c7b 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -5290,11 +5290,14 @@ static int i915_sseu_status(struct seq_file *m, void *unused)
> > >  {
> > >  	struct drm_info_node *node = (struct drm_info_node *) m->private;
> > >  	struct drm_device *dev = node->minor->dev;
> > > +	struct drm_i915_private *dev_priv = dev->dev_private;

Oh, this definitely should be to_i915(dev)

> > >  	struct sseu_dev_status stat;
> > >  
> > >  	if (INTEL_INFO(dev)->gen < 8)
> > 
> > whilst here: INTEL_GEN(dev_priv) and may as well fix any other dev in
> > the function.
> > 
> > >  		return -ENODEV;
> > >  
> > > +	intel_runtime_pm_get(dev_priv);
> > 
> > I was wondering if instead we wanted a 
> > 
> > ...sw dump...
> > if (intel_runtime_pm_get_if_noidle(dev_priv)) {
> > 	...hw dump...
> > 	intel_runtime_pm_put();
> > } else {
> > 	seq_printf(m, "Device powered down, not probing current HW configuration.\n");
> > }
> 
> There are a lot of cases in the file with similar behaviour.
> Maybe a separate patch to clear them all up at once would make sense.
> The same goes for dev -> dev_priv (one patch for each of these two
> transitions).

There are schools here:

1) big patches doing mechanical change
2) small patches fixing up surrounding code as you drive by


Both have their advantages (small patches -> less conflict, more likely
to tidy up surrouding code, big patches -> more chance of conflict, more
or less needs sed/coccinelle, artifacts from mechanical changes).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre