From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Perry Yuan <perry.yuan@amd.com>,
rafael.j.wysocki@intel.com, ray.huang@amd.com,
viresh.kumar@linaro.org
Cc: Deepak.Sharma@amd.com, Nathan.Fontenot@amd.com,
Alexander.Deucher@amd.com, Shimmer.Huang@amd.com,
Xiaojian.Du@amd.com, Li.Meng@amd.com, wyes.karny@amd.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 08/11] cpufreq: amd_pstate: add driver working mode status sysfs entry
Date: Fri, 2 Dec 2022 09:57:06 -0600 [thread overview]
Message-ID: <b984800e-9d70-3f43-1af2-7f3d85d356bd@amd.com> (raw)
In-Reply-To: <20221202074719.623673-9-perry.yuan@amd.com>
On 12/2/2022 01:47, Perry Yuan wrote:
> From: Perry Yuan <Perry.Yuan@amd.com>
>
> While amd-pstate driver was loaded with specific driver mode, it will
The *driver* doesn't need to check which mode is enabled from the sysfs
file, but userspace may want to check this. I think you should reword
this accordingly in the commit message.
> need to check which mode is enabled for the pstate driver,add this sysfs
> entry to show the current status
>
> $ cat /sys/devices/system/cpu/amd-pstate/status
> active
>
> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com>
> ---
> drivers/cpufreq/amd-pstate.c | 44 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 6936df6e8642..7f748a579023 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -66,6 +66,8 @@ static bool cppc_active;
> static int cppc_load __initdata;
>
> static struct cpufreq_driver *default_pstate_driver;
> +static struct cpufreq_driver amd_pstate_epp_driver;
> +static struct cpufreq_driver amd_pstate_driver;
> static struct amd_cpudata **all_cpu_data;
> static struct amd_pstate_params global_params;
>
> @@ -807,6 +809,46 @@ static ssize_t store_boost(struct kobject *a,
> return count;
> }
>
> +static ssize_t amd_pstate_show_status(char *buf)
> +{
> + if (!default_pstate_driver)
> + return sysfs_emit(buf, "off\n");
> +
> + return sysfs_emit(buf, "%s\n", default_pstate_driver == &amd_pstate_epp_driver ?
> + "active" : "passive");
> +}
> +
> +static int amd_pstate_update_status(const char *buf, size_t size)
> +{
> + /* FIXME! */
> + return -EOPNOTSUPP;
> +}
Why not just fix this as part of the series? It should be no different
than unloading the driver and reloading it in the appropriate mode, right?
Is this going to be a short term FIXME/TODO or a long term? If it's
long term, it might be better to just make the attribute ro and and have
just the show callback. Then when you're ready to make it rw you can
add the store callback, change it from ro to rw and update documentation
at that time.
> +
> +static ssize_t show_status(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + ssize_t ret;
> +
> + mutex_lock(&amd_pstate_driver_lock);
> + ret = amd_pstate_show_status(buf);
> + mutex_unlock(&amd_pstate_driver_lock);
> +
> + return ret;
> +}
> +
> +static ssize_t store_status(struct kobject *a, struct kobj_attribute *b,
> + const char *buf, size_t count)
> +{
> + char *p = memchr(buf, '\n', count);
> + int ret;
> +
> + mutex_lock(&amd_pstate_driver_lock);
> + ret = amd_pstate_update_status(buf, p ? p - buf : count);
> + mutex_unlock(&amd_pstate_driver_lock);
> +
> + return ret < 0 ? ret : count;
> +}
> +
> cpufreq_freq_attr_ro(amd_pstate_max_freq);
> cpufreq_freq_attr_ro(amd_pstate_lowest_nonlinear_freq);
>
> @@ -814,6 +856,7 @@ cpufreq_freq_attr_ro(amd_pstate_highest_perf);
> cpufreq_freq_attr_rw(energy_performance_preference);
> cpufreq_freq_attr_ro(energy_performance_available_preferences);
> define_one_global_rw(boost);
> +define_one_global_rw(status);
>
> static struct freq_attr *amd_pstate_attr[] = {
> &amd_pstate_max_freq,
> @@ -833,6 +876,7 @@ static struct freq_attr *amd_pstate_epp_attr[] = {
>
> static struct attribute *pstate_global_attributes[] = {
> &boost.attr,
> + &status.attr,
In the series I didn't see a matching Documentation update for the new
sysfs file, can you please add one?
> NULL
> };
>
next prev parent reply other threads:[~2022-12-02 15:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 7:47 [PATCH v6 00/11] Implement AMD Pstate EPP Driver Perry Yuan
2022-12-02 7:47 ` [PATCH v6 01/11] ACPI: CPPC: Add AMD pstate energy performance preference cppc control Perry Yuan
2022-12-02 16:58 ` Limonciello, Mario
2022-12-05 15:17 ` Yuan, Perry
2022-12-02 7:47 ` [PATCH v6 02/11] Documentation: amd-pstate: add EPP profiles introduction Perry Yuan
2022-12-02 7:47 ` [PATCH v6 03/11] cpufreq: intel_pstate: use common macro definition for Energy Preference Performance(EPP) Perry Yuan
2022-12-05 11:48 ` Huang Rui
2022-12-05 14:40 ` Yuan, Perry
2022-12-05 16:44 ` Limonciello, Mario
2022-12-08 14:40 ` Yuan, Perry
2022-12-08 16:46 ` Limonciello, Mario
2022-12-02 7:47 ` [PATCH v6 04/11] cpufreq: amd_pstate: implement Pstate EPP support for the AMD processors Perry Yuan
2022-12-02 17:36 ` Limonciello, Mario
2022-12-08 15:51 ` Yuan, Perry
2022-12-03 19:52 ` kernel test robot
2022-12-05 12:22 ` Huang Rui
2022-12-08 15:43 ` Yuan, Perry
2022-12-02 7:47 ` [PATCH v6 05/11] cpufreq: amd_pstate: implement amd pstate cpu online and offline callback Perry Yuan
2022-12-02 7:47 ` [PATCH v6 06/11] cpufreq: amd-pstate: implement suspend and resume callbacks Perry Yuan
2022-12-02 7:47 ` [PATCH v6 07/11] cpufreq: amd-pstate: add frequency dynamic boost sysfs control Perry Yuan
2022-12-02 15:59 ` Limonciello, Mario
2022-12-05 15:19 ` Yuan, Perry
2022-12-02 7:47 ` [PATCH v6 08/11] cpufreq: amd_pstate: add driver working mode status sysfs entry Perry Yuan
2022-12-02 15:57 ` Limonciello, Mario [this message]
2022-12-08 15:55 ` Yuan, Perry
2022-12-02 7:47 ` [PATCH v6 09/11] Documentation: amd-pstate: add amd pstate driver mode introduction Perry Yuan
2022-12-02 7:47 ` [PATCH v6 10/11] Documentation: introduce amd pstate active mode kernel command line options Perry Yuan
2022-12-02 7:47 ` [PATCH v6 11/11] cpufreq: amd_pstate: convert sprintf with sysfs_emit() Perry Yuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b984800e-9d70-3f43-1af2-7f3d85d356bd@amd.com \
--to=mario.limonciello@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Deepak.Sharma@amd.com \
--cc=Li.Meng@amd.com \
--cc=Nathan.Fontenot@amd.com \
--cc=Shimmer.Huang@amd.com \
--cc=Xiaojian.Du@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=perry.yuan@amd.com \
--cc=rafael.j.wysocki@intel.com \
--cc=ray.huang@amd.com \
--cc=viresh.kumar@linaro.org \
--cc=wyes.karny@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®