From: Ulf Hansson <ulf.hansson@linaro.org>
To: Kamlesh Gurudasani <kamlesh@ti.com>
Cc: vigneshr@ti.com, d-gole@ti.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] pmdomain: core: add support for writeble power domain state
Date: Fri, 28 Feb 2025 13:39:44 +0100 [thread overview]
Message-ID: <CAPDyKFr+P9oi-ofXOkfoBHSCLaCAREW_efjJ6TctTeo_AVCzDA@mail.gmail.com> (raw)
In-Reply-To: <20250221-pm-debug-v1-1-e5bd815f7ca4@ti.com>
On Fri, 21 Feb 2025 at 14:48, Kamlesh Gurudasani <kamlesh@ti.com> wrote:
>
> Add support for writeable power domain states from debugfs.
>
> Defining GENPD_ALLOW_WRITE_DEBUGFS will enable writeable pd_state
> node in debugfs.
>
> Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
> ---
> This has turn out to be really helpful when debugging SCMI protocol
> for power domain management.
>
> Reference has been taken from clock framework which provides similar
> CLOCK_ALLOW_WRITE_DEBUGFS, which helps to test clocks from debugfs.
> ---
> drivers/pmdomain/core.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> index 9b2f28b34bb5..6aba0c672da0 100644
> --- a/drivers/pmdomain/core.c
> +++ b/drivers/pmdomain/core.c
> @@ -1298,6 +1298,60 @@ late_initcall_sync(genpd_power_off_unused);
>
> #ifdef CONFIG_PM_SLEEP
>
> +#ifdef GENPD_ALLOW_WRITE_DEBUGFS
> +/*
> + * This can be dangerous, therefore don't provide any real compile time
> + * configuration option for this feature.
> + * People who want to use this will need to modify the source code directly.
> + */
> +static int genpd_state_set(void *data, u64 val)
> +{
> +
> + struct generic_pm_domain *genpd = data;
> + int ret = 0;
> +
> + ret = genpd_lock_interruptible(genpd);
> + if (ret)
> + return -ERESTARTSYS;
> +
> + if (val == 1) {
> + genpd->power_on(genpd);
> + genpd->status = GENPD_STATE_ON;
> + } else if (val == 0) {
> + genpd->power_off(genpd);
> + genpd->status = GENPD_STATE_OFF;
> + }
> +
> + genpd_unlock(genpd);
> + return 0;
This makes the behaviour in genpd inconsistent and I am worried about
that, even if it's for debugging/development.
For example, what if there is a device hooked up to the genpd which
requires its PM domain to stay on? And what about child domains?
> +}
> +
> +#define pd_state_mode 0644
> +
> +static int genpd_state_get(void *data, u64 *val)
> +{
> +
> + struct generic_pm_domain *genpd = data;
> + int ret = 0;
> +
> + ret = genpd_lock_interruptible(genpd);
> + if (ret)
> + return -ERESTARTSYS;
> +
> + if (genpd->status == GENPD_STATE_OFF)
> + *val = 0;
> + else
> + *val = 1;
> +
> + genpd_unlock(genpd);
> + return ret;
> +}
> +
> +DEFINE_DEBUGFS_ATTRIBUTE(pd_state_fops, genpd_state_get,
> + genpd_state_set, "%llu\n");
> +
> +#endif /* GENPD_ALLOW_WRITE_DEBUGFS */
> +
> /**
> * genpd_sync_power_off - Synchronously power off a PM domain and its parents.
> * @genpd: PM domain to power off, if possible.
> @@ -3639,6 +3693,11 @@ static void genpd_debug_add(struct generic_pm_domain *genpd)
> if (genpd->set_performance_state)
> debugfs_create_file("perf_state", 0444,
> d, genpd, &perf_state_fops);
> +#ifdef GENPD_ALLOW_WRITE_DEBUGFS
> + debugfs_create_file("pd_state", 0644, d, genpd,
> + &pd_state_fops);
> +#endif /* GENPD_ALLOW_WRITE_DEBUGFS */
> +
> }
>
> static int __init genpd_debug_init(void)
> @@ -3653,6 +3712,24 @@ static int __init genpd_debug_init(void)
> list_for_each_entry(genpd, &gpd_list, gpd_list_node)
> genpd_debug_add(genpd);
>
> +#ifdef GENPD_ALLOW_WRITE_DEBUGFS
> + pr_warn("\n");
> + pr_warn("********************************************************************\n");
> + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
> + pr_warn("** **\n");
> + pr_warn("** WRITEABLE POWER DOMAIN STATE DEBUGFS SUPPORT HAS BEEN ENABLED **\n");
> + pr_warn("** IN THIS KERNEL **\n");
> + pr_warn("** This means that this kernel is built to expose pd operations **\n");
> + pr_warn("** such as enabling, disabling, etc. **\n");
> + pr_warn("** to userspace, which may compromise security on your system. **\n");
> + pr_warn("** **\n");
> + pr_warn("** If you see this message and you are not debugging the **\n");
> + pr_warn("** kernel, report this immediately to your vendor! **\n");
> + pr_warn("** **\n");
> + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
> + pr_warn("********************************************************************\n");
> +#endif /* GENPD_ALLOW_WRITE_DEBUGFS */
> +
> return 0;
> }
> late_initcall(genpd_debug_init);
>
> ---
> base-commit: d4b0fd87ff0d4338b259dc79b2b3c6f7e70e8afa
> change-id: 20250221-pm-debug-0824da30890f
>
> Best regards,
> --
> Kamlesh Gurudasani <kamlesh@ti.com>
>
When working with genpd and SCMI PM domains, a more robust way to
debug things would be to implement a slim skeleton driver for a
consumer device. In principle it just needs some basic runtime PM
support and the corresponding device hooked up to the SCMI PM domain
in DT. In this way, we can use the existing sysfs interface for
runtime PM, to control and debug the behaviour of the genpd/SCMI PM
domain.
I have a bunch of local code/drivers for this already. Even for
testing the SCMI perf domain with OPPs. I can share them with you, if
you are interested?
Kind regards
Uffe
next prev parent reply other threads:[~2025-02-28 12:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 13:48 Kamlesh Gurudasani
2025-02-28 11:11 ` Dhruva Gole
2025-02-28 12:39 ` Ulf Hansson [this message]
2025-03-03 9:58 ` Dhruva Gole
2025-03-05 14:38 ` Ulf Hansson
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=CAPDyKFr+P9oi-ofXOkfoBHSCLaCAREW_efjJ6TctTeo_AVCzDA@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=d-gole@ti.com \
--cc=kamlesh@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=vigneshr@ti.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®