linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-arm-kernel@lists.infradead.org, soc@kernel.org,
	linux-pm@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: Re: [RESEND PATCH v2] firmware/psci: Add debugfs support to ease debugging
Date: Mon, 26 Sep 2022 13:38:50 +0200	[thread overview]
Message-ID: <CAPDyKFqAgukYVPvkrE=mzM88e+PfFnecwPLxdRogjnwHgLq=Jw@mail.gmail.com> (raw)
In-Reply-To: <20220926110758.666922-1-dmitry.baryshkov@linaro.org>

On Mon, 26 Sept 2022 at 13:08, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> To ease debugging of PSCI supported features, add debugfs file called
> 'psci' describing PSCI and SMC CC versions, enabled features and
> options.
>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> I sketched this while trying to narrow down the particular issue on
> the Qualcomm platform (which started as an attempt to implement PSCI
> domains, but then led to understanding that while the platform claims
> supports OSI, it doesn't support SET_SUSPEND). We were going to use
> this to help to narrow down issues with the PSCI support on other
> platforms as well.
>
> Changes since v1:
> - Extended the table to include MEM_PROTECT functions (noted by Mark
>   Brown)
> - Switched to seq_puts where possible
> - Changed S_IRUGO to 0444
>
> The patch is resent to include soc@kernel.org
> ---
>  drivers/firmware/psci/psci.c | 116 ++++++++++++++++++++++++++++++++++-
>  include/uapi/linux/psci.h    |  14 +++++
>  2 files changed, 129 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index cfb448eabdaa..9fdcb6bff403 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -9,6 +9,7 @@
>  #include <linux/acpi.h>
>  #include <linux/arm-smccc.h>
>  #include <linux/cpuidle.h>
> +#include <linux/debugfs.h>
>  #include <linux/errno.h>
>  #include <linux/linkage.h>
>  #include <linux/of.h>
> @@ -324,12 +325,125 @@ static void psci_sys_poweroff(void)
>         invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>
> -static int __init psci_features(u32 psci_func_id)
> +static int psci_features(u32 psci_func_id)
>  {
>         return invoke_psci_fn(PSCI_1_0_FN_PSCI_FEATURES,
>                               psci_func_id, 0, 0);
>  }
>
> +#ifdef CONFIG_DEBUG_FS
> +
> +#define PSCI_ID(ver, _name) \
> +       { .fn = PSCI_##ver##_FN_##_name, .name = #_name, }
> +#define PSCI_ID_NATIVE(ver, _name) \
> +       { .fn = PSCI_FN_NATIVE(ver, _name), .name = #_name, }
> +
> +/* A table of all optional functions */
> +static const struct {
> +       u32 fn;
> +       const char *name;
> +} psci_fn_ids[] = {
> +       PSCI_ID_NATIVE(0_2, MIGRATE),
> +       PSCI_ID(0_2, MIGRATE_INFO_TYPE),
> +       PSCI_ID_NATIVE(0_2, MIGRATE_INFO_UP_CPU),
> +       PSCI_ID(1_0, CPU_FREEZE),
> +       PSCI_ID_NATIVE(1_0, CPU_DEFAULT_SUSPEND),
> +       PSCI_ID_NATIVE(1_0, NODE_HW_STATE),
> +       PSCI_ID_NATIVE(1_0, SYSTEM_SUSPEND),
> +       PSCI_ID(1_0, SET_SUSPEND_MODE),
> +       PSCI_ID_NATIVE(1_0, STAT_RESIDENCY),
> +       PSCI_ID_NATIVE(1_0, STAT_COUNT),
> +       PSCI_ID_NATIVE(1_1, SYSTEM_RESET2),
> +       PSCI_ID(1_1, MEM_PROTECT),
> +       PSCI_ID_NATIVE(1_1, MEM_PROTECT_CHECK_RANGE),
> +};
> +
> +static int psci_debugfs_read(struct seq_file *s, void *data)
> +{
> +       int feature, type, i;
> +       u32 ver;
> +
> +       ver = psci_ops.get_version();

This call and some other calls below, triggers calls into the PSCI FW
(via smc calls). Rather than having to do that, each time user space
wants to read the debugfs data, we could cache/store that data during
the "probe" sequence of the psci fw driver. In this way, we don't need
to run the smc calls each time, but just once when probing.

Did you consider that option? Or perhaps there are other problems of doing that?

> +       seq_printf(s, "PSCIv%d.%d\n",
> +                  PSCI_VERSION_MAJOR(ver),
> +                  PSCI_VERSION_MINOR(ver));
> +
> +       /* PSCI_FEATURES is available only starting from 1.0 */
> +       if (PSCI_VERSION_MAJOR(ver) < 1)
> +               return 0;
> +
> +       feature = psci_features(ARM_SMCCC_VERSION_FUNC_ID);
> +       if (feature != PSCI_RET_NOT_SUPPORTED) {
> +               ver = invoke_psci_fn(ARM_SMCCC_VERSION_FUNC_ID, 0, 0, 0);
> +               seq_printf(s, "SMC Calling Convention v%d.%d\n",
> +                          PSCI_VERSION_MAJOR(ver),
> +                          PSCI_VERSION_MINOR(ver));
> +       } else {
> +               seq_puts(s, "SMC Calling Convention v1.0 is assumed\n");
> +       }
> +
> +       feature = psci_features(PSCI_FN_NATIVE(0_2, CPU_SUSPEND));
> +       if (feature < 0) {
> +               seq_printf(s, "PSCI_FEATURES(CPU_SUSPEND) error (%d)\n", feature);
> +       } else {
> +               seq_printf(s, "OSI is %ssupported\n",
> +                          (feature & BIT(0)) ? "" : "not ");
> +               seq_printf(s, "%s StateID format is used\n",
> +                          (feature & BIT(1)) ? "Extended" : "Original");
> +       }
> +
> +       type = psci_ops.migrate_info_type();
> +       if (type == PSCI_0_2_TOS_UP_MIGRATE ||
> +           type == PSCI_0_2_TOS_UP_NO_MIGRATE) {
> +               unsigned long cpuid;
> +
> +               seq_printf(s, "Trusted OS %smigrate capable\n",
> +                          type == PSCI_0_2_TOS_UP_NO_MIGRATE ? "not " : "");
> +               cpuid = psci_migrate_info_up_cpu();
> +               seq_printf(s, "Trusted OS resident on physical CPU 0x%lx (#%d)\n",
> +                          cpuid, resident_cpu);
> +       } else if (type == PSCI_0_2_TOS_MP) {
> +               seq_puts(s, "Trusted OS migration not required\n");
> +       } else {
> +               if (type != PSCI_RET_NOT_SUPPORTED)
> +                       seq_printf(s, "MIGRATE_INFO_TYPE returned unknown type (%d)\n", type);
> +       }
> +
> +       for (i = 0; i < ARRAY_SIZE(psci_fn_ids); i++) {
> +               feature = psci_features(psci_fn_ids[i].fn);
> +               if (feature == PSCI_RET_NOT_SUPPORTED)
> +                       continue;
> +               if (feature < 0)
> +                       seq_printf(s, "PSCI_FEATURES(%s) error (%d)\n",
> +                                  psci_fn_ids[i].name, feature);
> +               else
> +                       seq_printf(s, "%s is supported\n", psci_fn_ids[i].name);
> +       }
> +
> +       return 0;
> +}

[...]

Kind regards
Uffe

  reply	other threads:[~2022-09-26 13:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 11:07 [RESEND PATCH v2] firmware/psci: Add debugfs support to ease debugging Dmitry Baryshkov
2022-09-26 11:38 ` Ulf Hansson [this message]
2022-09-26 12:04   ` Dmitry Baryshkov
2022-09-26 13:50     ` 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='CAPDyKFqAgukYVPvkrE=mzM88e+PfFnecwPLxdRogjnwHgLq=Jw@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rafael@kernel.org \
    --cc=soc@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).