RE: [PATCH v11 1/8] cpufreq: amd-pstate: Document *_limit_* fields in struct amd_cpudata

From: Yuan, Perry
Date: Tue Apr 23 2024 - 23:05:59 EST


[AMD Official Use Only - General]

Hi Ray,

> -----Original Message-----
> From: Huang, Ray <Ray.Huang@xxxxxxx>
> Sent: Tuesday, April 23, 2024 6:23 PM
> To: Yuan, Perry <Perry.Yuan@xxxxxxx>
> Cc: rafael.j.wysocki@xxxxxxxxx; Limonciello, Mario
> <Mario.Limonciello@xxxxxxx>; viresh.kumar@xxxxxxxxxx; Shenoy, Gautham
> Ranjal <gautham.shenoy@xxxxxxx>; Petkov, Borislav
> <Borislav.Petkov@xxxxxxx>; Deucher, Alexander
> <Alexander.Deucher@xxxxxxx>; Huang, Shimmer
> <Shimmer.Huang@xxxxxxx>; oleksandr@xxxxxxxxxxxxxx; Du, Xiaojian
> <Xiaojian.Du@xxxxxxx>; Meng, Li (Jassmine) <Li.Meng@xxxxxxx>; linux-
> pm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v11 1/8] cpufreq: amd-pstate: Document *_limit_* fields
> in struct amd_cpudata
>
> On Tue, Apr 23, 2024 at 03:58:17PM +0800, Yuan, Perry wrote:
> > From: "Gautham R. Shenoy" <gautham.shenoy@xxxxxxx>
> >
> > The four fields of struct cpudata namely min_limit_perf,
> > max_limit_perf, min_limit_freq, max_limit_freq introduced in the
> > commit febab20caeba("cpufreq/amd-pstate: Fix scaling_min_freq and
> > scaling_max_freq update") are currently undocumented
> >
> > Add comments describing these fields
> >
> > Acked-by: Huang Rui <ray.huang@xxxxxxx>
> > Fixes: febab20caeba("cpufreq/amd-pstate: Fix scaling_min_freq and
> > scaling_max_freq update")
> > Reviewed-by: Li Meng <li.meng@xxxxxxx>
> > Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@xxxxxxx>
> > Signed-off-by: Gautham R. Shenoy <gautham.shenoy@xxxxxxx>
> > Signed-off-by: Perry Yuan <perry.yuan@xxxxxxx>
> > ---
> > include/linux/amd-pstate.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/linux/amd-pstate.h b/include/linux/amd-pstate.h
> > index d21838835abd..212f377d615b 100644
> > --- a/include/linux/amd-pstate.h
> > +++ b/include/linux/amd-pstate.h
> > @@ -49,6 +49,10 @@ struct amd_aperf_mperf {
> > * @lowest_perf: the absolute lowest performance level of the processor
> > * @prefcore_ranking: the preferred core ranking, the higher value indicates
> a higher
> > * priority.
> > + * @min_limit_perf: Cached value of the perf corresponding to
> > + policy->min
> > + * @max_limit_perf: Cached value of the perf corresponding to
> > + policy->max
>
> Perry, you didn't address the comment in the latest version.
>
> https://lore.kernel.org/lkml/ZhyEwE3Hr8Waf620@xxxxxxx/
>
> Thanks,
> Ray

I had explained why the perf is the better words used here than performance in v10.
https://lore.kernel.org/lkml/CYYPR12MB8655D251FC00EF8207C771BD9C0E2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
if you still have concerns for the single word, I can change it in v12 as you want.


Perry.

>
> > + * @min_limit_freq: Cached value of policy->min
> > + * @max_limit_freq: Cached value of policy->max
> > * @max_freq: the frequency that mapped to highest_perf
> > * @min_freq: the frequency that mapped to lowest_perf
> > * @nominal_freq: the frequency that mapped to nominal_perf
> > --
> > 2.34.1
> >