Message ID | c50374885172571e1c25d95552dec8467c37ea24.1713858800.git.perry.yuan@amd.com |
---|---|
State | Superseded |
Headers | show |
Series | AMD Pstate Fixes And Enhancements | expand |
[AMD Official Use Only - General] Hi Ray, > -----Original Message----- > From: Huang, Ray <Ray.Huang@amd.com> > Sent: Tuesday, April 23, 2024 6:23 PM > To: Yuan, Perry <Perry.Yuan@amd.com> > Cc: rafael.j.wysocki@intel.com; Limonciello, Mario > <Mario.Limonciello@amd.com>; viresh.kumar@linaro.org; Shenoy, Gautham > Ranjal <gautham.shenoy@amd.com>; Petkov, Borislav > <Borislav.Petkov@amd.com>; Deucher, Alexander > <Alexander.Deucher@amd.com>; Huang, Shimmer > <Shimmer.Huang@amd.com>; oleksandr@natalenko.name; Du, Xiaojian > <Xiaojian.Du@amd.com>; Meng, Li (Jassmine) <Li.Meng@amd.com>; linux- > pm@vger.kernel.org; linux-kernel@vger.kernel.org > 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@amd.com> > > > > 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@amd.com> > > Fixes: febab20caeba("cpufreq/amd-pstate: Fix scaling_min_freq and > > scaling_max_freq update") > > Reviewed-by: Li Meng <li.meng@amd.com> > > Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> > > Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> > > Signed-off-by: Perry Yuan <perry.yuan@amd.com> > > --- > > 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@amd.com/ > > Thanks, > Ray I had explained why the perf is the better words used here than performance in v10. https://lore.kernel.org/lkml/CYYPR12MB8655D251FC00EF8207C771BD9C0E2@CYYPR12MB8655.namprd12.prod.outlook.com/ 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 > >
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 + * @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