PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
where the semantics are described by the PSCI specification itself as
well as vendor-specific resets. Currently only system warm reset
semantics is defined as part of architectural resets by the specification.
This patch implements support for SYSTEM_RESET2 by making using of
reboot_mode passed by the reboot infrastructure in the kernel.
Cc: Lorenzo Pieralisi <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
include/uapi/linux/psci.h | 2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
v2->v3:
- Added else condition so that if SYSTEM_RESET2 fails, it ends
up doing a system halt
- Wrap single statement if..else with braces because of presence
of multiple line comment
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d03274..c9ea8f38bd42 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -88,6 +88,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
static u32 psci_cpu_suspend_feature;
+static bool psci_system_reset2_supported;
static inline bool psci_has_ext_power_state(void)
{
@@ -253,7 +254,17 @@ static int get_set_conduit_method(struct device_node *np)
static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
{
- invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+ if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
+ psci_system_reset2_supported) {
+ /*
+ * reset_type[31] = 0 (architectural)
+ * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
+ * cookie = 0 (ignored by the implementation)
+ */
+ invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
+ } else {
+ invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+ }
}
static void psci_sys_poweroff(void)
@@ -451,6 +462,16 @@ static const struct platform_suspend_ops psci_suspend_ops = {
.enter = psci_system_suspend_enter,
};
+static void __init psci_init_system_reset2(void)
+{
+ int ret;
+
+ ret = psci_features(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2));
+
+ if (ret != PSCI_RET_NOT_SUPPORTED)
+ psci_system_reset2_supported = true;
+}
+
static void __init psci_init_system_suspend(void)
{
int ret;
@@ -588,6 +609,7 @@ static int __init psci_probe(void)
psci_init_smccc();
psci_init_cpu_suspend();
psci_init_system_suspend();
+ psci_init_system_reset2();
}
return 0;
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index b3bcabe380da..5b0ba0062541 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -49,8 +49,10 @@
#define PSCI_1_0_FN_PSCI_FEATURES PSCI_0_2_FN(10)
#define PSCI_1_0_FN_SYSTEM_SUSPEND PSCI_0_2_FN(14)
+#define PSCI_1_1_FN_SYSTEM_RESET2 PSCI_0_2_FN(18)
#define PSCI_1_0_FN64_SYSTEM_SUSPEND PSCI_0_2_FN64(14)
+#define PSCI_1_1_FN64_SYSTEM_RESET2 PSCI_0_2_FN64(18)
/* PSCI v0.2 power state encoding for CPU_SUSPEND function */
#define PSCI_0_2_POWER_STATE_ID_MASK 0xffff
--
2.17.1
On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> where the semantics are described by the PSCI specification itself as
> well as vendor-specific resets. Currently only system warm reset
> semantics is defined as part of architectural resets by the specification.
>
> This patch implements support for SYSTEM_RESET2 by making using of
> reboot_mode passed by the reboot infrastructure in the kernel.
>
> Cc: Lorenzo Pieralisi <[email protected]>
> Acked-by: Mark Rutland <[email protected]>
> Signed-off-by: Sudeep Holla <[email protected]>
> ---
> drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
> include/uapi/linux/psci.h | 2 ++
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> v2->v3:
> - Added else condition so that if SYSTEM_RESET2 fails, it ends
> up doing a system halt
> - Wrap single statement if..else with braces because of presence
> of multiple line comment
>
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index c80ec1d03274..c9ea8f38bd42 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -88,6 +88,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
> PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
>
> static u32 psci_cpu_suspend_feature;
> +static bool psci_system_reset2_supported;
>
> static inline bool psci_has_ext_power_state(void)
> {
> @@ -253,7 +254,17 @@ static int get_set_conduit_method(struct device_node
> *np)
>
> static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
> {
> - invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
> + if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> + psci_system_reset2_supported) {
> + /*
> + * reset_type[31] = 0 (architectural)
> + * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
> + * cookie = 0 (ignored by the implementation)
> + */
> + invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
> + } else {
> + invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
> + }
> }
>
> static void psci_sys_poweroff(void)
> @@ -451,6 +462,16 @@ static const struct platform_suspend_ops
> psci_suspend_ops = { .enter = psci_system_suspend_enter,
> };
>
> +static void __init psci_init_system_reset2(void)
> +{
> + int ret;
> +
> + ret = psci_features(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2));
> +
> + if (ret != PSCI_RET_NOT_SUPPORTED)
> + psci_system_reset2_supported = true;
> +}
> +
> static void __init psci_init_system_suspend(void)
> {
> int ret;
> @@ -588,6 +609,7 @@ static int __init psci_probe(void)
> psci_init_smccc();
> psci_init_cpu_suspend();
> psci_init_system_suspend();
> + psci_init_system_reset2();
> }
>
> return 0;
> diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
> index b3bcabe380da..5b0ba0062541 100644
> --- a/include/uapi/linux/psci.h
> +++ b/include/uapi/linux/psci.h
> @@ -49,8 +49,10 @@
>
> #define PSCI_1_0_FN_PSCI_FEATURES PSCI_0_2_FN(10)
> #define PSCI_1_0_FN_SYSTEM_SUSPEND PSCI_0_2_FN(14)
> +#define PSCI_1_1_FN_SYSTEM_RESET2 PSCI_0_2_FN(18)
>
> #define PSCI_1_0_FN64_SYSTEM_SUSPEND PSCI_0_2_FN64(14)
> +#define PSCI_1_1_FN64_SYSTEM_RESET2 PSCI_0_2_FN64(18)
>
> /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
> #define PSCI_0_2_POWER_STATE_ID_MASK 0xffff
> --
So I queued up the PSCI series from Ulf which clashes with this patch.
I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
result. :-)
On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> > PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> > where the semantics are described by the PSCI specification itself as
> > well as vendor-specific resets. Currently only system warm reset
> > semantics is defined as part of architectural resets by the specification.
> >
> > This patch implements support for SYSTEM_RESET2 by making using of
> > reboot_mode passed by the reboot infrastructure in the kernel.
> >
> > Cc: Lorenzo Pieralisi <[email protected]>
> > Acked-by: Mark Rutland <[email protected]>
> > Signed-off-by: Sudeep Holla <[email protected]>
> > ---
> > drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
> > include/uapi/linux/psci.h | 2 ++
> > 2 files changed, 25 insertions(+), 1 deletion(-)
[...]
> > --
>
> So I queued up the PSCI series from Ulf which clashes with this patch.
>
Ah OK, I wasn't aware(just back from holiday) that it's going through
your tree. No worries, I will rebase and repost soon. I want testing
by xilinx or Aaro Koskinen before that.
> I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> result. :-)
>
I can understand, I assure it's one off :)
--
Regards,
Sudeep
Sudeep, Lorenzo, Mark
On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <[email protected]> wrote:
>
> On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> > > PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> > > where the semantics are described by the PSCI specification itself as
> > > well as vendor-specific resets. Currently only system warm reset
> > > semantics is defined as part of architectural resets by the specification.
> > >
> > > This patch implements support for SYSTEM_RESET2 by making using of
> > > reboot_mode passed by the reboot infrastructure in the kernel.
> > >
> > > Cc: Lorenzo Pieralisi <[email protected]>
> > > Acked-by: Mark Rutland <[email protected]>
> > > Signed-off-by: Sudeep Holla <[email protected]>
> > > ---
> > > drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
> > > include/uapi/linux/psci.h | 2 ++
> > > 2 files changed, 25 insertions(+), 1 deletion(-)
>
> [...]
>
> > > --
> >
> > So I queued up the PSCI series from Ulf which clashes with this patch.
> >
>
> Ah OK, I wasn't aware(just back from holiday) that it's going through
> your tree. No worries, I will rebase and repost soon. I want testing
> by xilinx or Aaro Koskinen before that.
>
> > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > result. :-)
> >
>
> I can understand, I assure it's one off :)
Speaking about that. I would gladly help out to host a git tree to
collect patches that you have acked. In this way, we can, for example,
get the patches pre-tested in linux next before we send the
pull-request.
If you think sounds like a good idea, just tell me so I can prepare a
tree for the next release cycle...
Kind regards
Uffe
On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> Sudeep, Lorenzo, Mark
>
> On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <[email protected]> wrote:
> >
> > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> > > > PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> > > > where the semantics are described by the PSCI specification itself as
> > > > well as vendor-specific resets. Currently only system warm reset
> > > > semantics is defined as part of architectural resets by the specification.
> > > >
> > > > This patch implements support for SYSTEM_RESET2 by making using of
> > > > reboot_mode passed by the reboot infrastructure in the kernel.
> > > >
> > > > Cc: Lorenzo Pieralisi <[email protected]>
> > > > Acked-by: Mark Rutland <[email protected]>
> > > > Signed-off-by: Sudeep Holla <[email protected]>
> > > > ---
> > > > drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
> > > > include/uapi/linux/psci.h | 2 ++
> > > > 2 files changed, 25 insertions(+), 1 deletion(-)
> >
> > [...]
> >
> > > > --
> > >
> > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > >
> >
> > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > your tree. No worries, I will rebase and repost soon. I want testing
> > by xilinx or Aaro Koskinen before that.
> >
> > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > result. :-)
> > >
> >
> > I can understand, I assure it's one off :)
>
> Speaking about that. I would gladly help out to host a git tree to
> collect patches that you have acked. In this way, we can, for example,
> get the patches pre-tested in linux next before we send the
> pull-request.
>
> If you think sounds like a good idea, just tell me so I can prepare a
> tree for the next release cycle...
>
For now, I just have this one patch. So if Rafael has queued all your
patches, I can just rebase and post it once I get tested-by from Aaro
Koskinen, so that Rafael can queue this too. Or are you planning to
send PR to Rafael, sorry if I missed details already discussed on the
list.
--
Regards,
Sudeep
On Fri, Apr 12, 2019 at 02:42:22PM +0100, Sudeep Holla wrote:
> On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> > Sudeep, Lorenzo, Mark
> >
> > On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <[email protected]> wrote:
> > >
> > > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > > On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> > > > > PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> > > > > where the semantics are described by the PSCI specification itself as
> > > > > well as vendor-specific resets. Currently only system warm reset
> > > > > semantics is defined as part of architectural resets by the specification.
> > > > >
> > > > > This patch implements support for SYSTEM_RESET2 by making using of
> > > > > reboot_mode passed by the reboot infrastructure in the kernel.
> > > > >
> > > > > Cc: Lorenzo Pieralisi <[email protected]>
> > > > > Acked-by: Mark Rutland <[email protected]>
> > > > > Signed-off-by: Sudeep Holla <[email protected]>
> > > > > ---
> > > > > drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
> > > > > include/uapi/linux/psci.h | 2 ++
> > > > > 2 files changed, 25 insertions(+), 1 deletion(-)
> > >
> > > [...]
> > >
> > > > > --
> > > >
> > > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > > >
> > >
> > > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > > your tree. No worries, I will rebase and repost soon. I want testing
> > > by xilinx or Aaro Koskinen before that.
> > >
> > > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > > result. :-)
> > > >
> > >
> > > I can understand, I assure it's one off :)
> >
> > Speaking about that. I would gladly help out to host a git tree to
> > collect patches that you have acked. In this way, we can, for example,
> > get the patches pre-tested in linux next before we send the
> > pull-request.
> >
> > If you think sounds like a good idea, just tell me so I can prepare a
> > tree for the next release cycle...
> >
>
> For now, I just have this one patch. So if Rafael has queued all your
> patches, I can just rebase and post it once I get tested-by from Aaro
> Koskinen, so that Rafael can queue this too. Or are you planning to
> send PR to Rafael, sorry if I missed details already discussed on the
> list.
Mark and I can queue PSCI patches as we usually do, we agreed they would
go via Rafael's tree (thanks) because of dependencies with the PM tree
(that did not turn out to be there so we could have sent them to arm-soc
just as well as we usually do), next cycle if and when there are patches
to be queued we will queue them up and send them upstream ourselves.
Thanks,
Lorenzo
Hi,
From: Sudeep Holla [[email protected]]:
> PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> where the semantics are described by the PSCI specification itself as
> well as vendor-specific resets. Currently only system warm reset
> semantics is defined as part of architectural resets by the specification.
>
> This patch implements support for SYSTEM_RESET2 by making using of
> reboot_mode passed by the reboot infrastructure in the kernel.
>
> Cc: Lorenzo Pieralisi <[email protected]>
> Acked-by: Mark Rutland <[email protected]>
> Signed-off-by: Sudeep Holla <[email protected]>
Tested-by: Aaro Koskinen <[email protected]>
Thanks,
A.
On Fri, 12 Apr 2019 at 16:19, Lorenzo Pieralisi
<[email protected]> wrote:
>
> On Fri, Apr 12, 2019 at 02:42:22PM +0100, Sudeep Holla wrote:
> > On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> > > Sudeep, Lorenzo, Mark
> > >
> > > On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <[email protected]> wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > > > On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> > > > > > PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> > > > > > where the semantics are described by the PSCI specification itself as
> > > > > > well as vendor-specific resets. Currently only system warm reset
> > > > > > semantics is defined as part of architectural resets by the specification.
> > > > > >
> > > > > > This patch implements support for SYSTEM_RESET2 by making using of
> > > > > > reboot_mode passed by the reboot infrastructure in the kernel.
> > > > > >
> > > > > > Cc: Lorenzo Pieralisi <[email protected]>
> > > > > > Acked-by: Mark Rutland <[email protected]>
> > > > > > Signed-off-by: Sudeep Holla <[email protected]>
> > > > > > ---
> > > > > > drivers/firmware/psci.c | 24 +++++++++++++++++++++++-
> > > > > > include/uapi/linux/psci.h | 2 ++
> > > > > > 2 files changed, 25 insertions(+), 1 deletion(-)
> > > >
> > > > [...]
> > > >
> > > > > > --
> > > > >
> > > > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > > > >
> > > >
> > > > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > > > your tree. No worries, I will rebase and repost soon. I want testing
> > > > by xilinx or Aaro Koskinen before that.
> > > >
> > > > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > > > result. :-)
> > > > >
> > > >
> > > > I can understand, I assure it's one off :)
> > >
> > > Speaking about that. I would gladly help out to host a git tree to
> > > collect patches that you have acked. In this way, we can, for example,
> > > get the patches pre-tested in linux next before we send the
> > > pull-request.
> > >
> > > If you think sounds like a good idea, just tell me so I can prepare a
> > > tree for the next release cycle...
> > >
> >
> > For now, I just have this one patch. So if Rafael has queued all your
> > patches, I can just rebase and post it once I get tested-by from Aaro
> > Koskinen, so that Rafael can queue this too. Or are you planning to
> > send PR to Rafael, sorry if I missed details already discussed on the
> > list.
>
> Mark and I can queue PSCI patches as we usually do, we agreed they would
> go via Rafael's tree (thanks) because of dependencies with the PM tree
> (that did not turn out to be there so we could have sent them to arm-soc
> just as well as we usually do), next cycle if and when there are patches
> to be queued we will queue them up and send them upstream ourselves.
Why I wanted them queued via Rafael's tree, is because of the
following series for PSCI that I will post in a a day or two, that has
dependencies to new changes to genpd.
My proposal with a git tree was mainly because of allowing patches to
be pre-tested in Stephen Rothwell's linux-next tree, before you send
the pull request to arm-soc. Or are you saying you already have a tree
for this, but not listed in MAINTAINERS?
In any case, it was just a suggestion to improve the working flow for
better tests etc. Feel free to ignore it.
Kind regards
Uffe