[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