[Intel-gfx] [PATCH] drm/i915/guc/slpc: Disable rps_boost debugfs
Dixit, Ashutosh
ashutosh.dixit at intel.com
Tue May 16 00:22:12 UTC 2023
On Mon, 15 May 2023 15:58:26 -0700, Dixit, Ashutosh wrote:
>
> On Mon, 15 May 2023 15:23:58 -0700, Belgaumkar, Vinay wrote:
> >
> >
> > On 5/12/2023 5:39 PM, Dixit, Ashutosh wrote:
> > > On Fri, 12 May 2023 16:56:03 -0700, Vinay Belgaumkar wrote:
> > > Hi Vinay,
> > >
> > >> rps_boost debugfs shows host turbo related info. This is not valid
> > >> when SLPC is enabled.
> > > A couple of thoughts about this. It appears people are know only about
> > > rps_boost_info and don't know about guc_slpc_info? So:
> > >
> > > a. Instead of hiding the rps_boost_info file do we need to print there
> > > saying "SLPC is enabled, go look at guc_slpc_info"?
> > rps_boost_info has an eval() function which disables the interface when RPS
> > is OFF. This is indeed the case here, so shouldn't we just follow that
> > instead of trying to link the two?
> > >
> > > b. Or, even just call guc_slpc_info_show from rps_boost_show (so the two
> > > files will show the same SLPC information)?
> >
> > slpc_info has a lot of other info like the SLPC state, not sure that
> > matches up with the rps_boost_info name.
>
> OK, I have asked in https://gitlab.freedesktop.org/drm/intel/-/issues/7632:
>
> @mattst88: is it acceptable to hide the
> /sys/kernel/debug/dri/0/i915_rps_boost_info file so that it doesn't cause
> confusion. And then user would have to go look at
> /sys/kernel/debug/dri/0/i915_guc_slpc_info or some such file when SLPC is
> being used? That's what the patch above is doing.
>
> Let's see what we hear from @mattst88.
@mattst88 agreed on #intel-gfx IRC, so ok by me:
Reviewed-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
>
> > >
> > >> guc_slpc_info already shows the number of boosts. Add num_waiters there
> > >> as well and disable rps_boost when SLPC is enabled.
> > >>
> > >> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7632
> > >> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
>
> Thanks.
> --
> Ashutosh
More information about the Intel-gfx
mailing list