[PATCH] drm/i915/gt: debugfs: Evaluate forcewake usage within locks

Andi Shyti andi.shyti at linux.intel.com
Tue Jun 11 13:35:09 UTC 2024


Hi Rodrigo,

...

> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > index 4fcba42cfe34..0437fd8217e0 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > @@ -71,6 +71,8 @@ static int fw_domains_show(struct seq_file *m, void *data)
> >  	struct intel_uncore_forcewake_domain *fw_domain;
> >  	unsigned int tmp;
> >  
> > +	spin_lock_irq(&uncore->lock);
> > +
> >  	seq_printf(m, "user.bypass_count = %u\n",
> >  		   uncore->user_forcewake_count);
> >  
> > @@ -79,6 +81,8 @@ static int fw_domains_show(struct seq_file *m, void *data)
> >  			   intel_uncore_forcewake_domain_to_str(fw_domain->id),
> >  			   READ_ONCE(fw_domain->wake_count));
> >  
> > +	spin_unlock_irq(&uncore->lock);
> 
> I was going to ask to move all of this to a function inside intel_uncore.c
> so we keep the lock access in there.... But then I noticed it is already
> spread all over :(

Yeah... maybe some refactoring might be needed there.

> Well, perhaps we should start from here to set the precedence and move
> things to its own component... but well, I won't block or make it hard,
> we do need this change and the overall uncore cleanup could be orthogonal.
> 
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>

Thanks,
Andi


More information about the Intel-gfx mailing list