| Message ID | 20190412100227.15024-1-sudeep.holla@arm.com |
|---|---|
| State | Accepted |
| Commit | 4302e381a870aafb547e6139830e5a4ee2cb8261 |
| Headers | show |
| Series | [v3] firmware/psci: add support for SYSTEM_RESET2 | expand |
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 <lorenzo.pieralisi@arm.com> > Acked-by: Mark Rutland <mark.rutland@arm.com> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > 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 <lorenzo.pieralisi@arm.com> > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > 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 <sudeep.holla@arm.com> 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 <lorenzo.pieralisi@arm.com> > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > --- > > > 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 <sudeep.holla@arm.com> 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 <lorenzo.pieralisi@arm.com> > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > --- > > > > 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 <sudeep.holla@arm.com> 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 <lorenzo.pieralisi@arm.com> > > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > > --- > > > > > 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 [sudeep.holla@arm.com]: > 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 <lorenzo.pieralisi@arm.com> > Acked-by: Mark Rutland <mark.rutland@arm.com> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com> Thanks, A.
On Fri, 12 Apr 2019 at 16:19, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 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 <sudeep.holla@arm.com> 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 <lorenzo.pieralisi@arm.com> > > > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > > > --- > > > > > > 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
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