lkml.org 
[lkml]   [2018]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v10 17/27] drivers: firmware: psci: Prepare to support PM domains
On Thu, 20 Dec 2018 at 15:19, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
> On 29/11/2018 18:46, Ulf Hansson wrote:
> > Following changes are about to implement support for PM domains to PSCI.
> > Those changes are mainly going to be implemented in a new separate file,
> > hence a couple of the internal PSCI functions needs to be shared to be
> > accessible. So, let's do that via adding new PSCI header file.
> >
> > Moreover, the changes deploying support for PM domains, needs to be able to
> > switch the PSCI FW into the OS initiated mode. For that reason, let's add a
> > new function that deals with this and share it via the new PSCI header
> > file.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> >
> > Changes in v10:
> > - New patch. Re-places the earlier patch: "drivers: firmware: psci:
> > Share a few internal PSCI functions".
> >
> > ---
> > drivers/firmware/psci/psci.c | 28 +++++++++++++++++++++-------
> > drivers/firmware/psci/psci.h | 14 ++++++++++++++
> > 2 files changed, 35 insertions(+), 7 deletions(-)
> > create mode 100644 drivers/firmware/psci/psci.h
> >
> > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > index 8dbcdecc2ae4..623591b541a4 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -34,6 +34,8 @@
> > #include <asm/smp_plat.h>
> > #include <asm/suspend.h>
> >
> > +#include "psci.h"
> > +
> > /*
> > * While a 64-bit OS can make calls with SMC32 calling conventions, for some
> > * calls it is necessary to use SMC64 to pass or return 64-bit values.
> > @@ -90,23 +92,35 @@ static u32 psci_function_id[PSCI_FN_MAX];
> > static DEFINE_PER_CPU(u32, domain_state);
> > static u32 psci_cpu_suspend_feature;
> >
> > -static inline u32 psci_get_domain_state(void)
> > +u32 psci_get_domain_state(void)
> > {
> > return __this_cpu_read(domain_state);
> > }
> >
> > -static inline void psci_set_domain_state(u32 state)
> > +void psci_set_domain_state(u32 state)
> > {
> > __this_cpu_write(domain_state, state);
> > }
> >
> > +bool psci_set_osi_mode(void)
> > +{
> > + int ret;
> > +
> > + ret = invoke_psci_fn(PSCI_1_0_FN_SET_SUSPEND_MODE,
> > + PSCI_1_0_SUSPEND_MODE_OSI, 0, 0);
> > + if (ret)
> > + pr_warn("failed to enable OSI mode: %d\n", ret);
> > +
> > + return !ret;
> > +}
>
> Please keep the convention with the error code (0 => success)
>
> In the next patch it can be called:
>
> if (psci_has_osi_support())
> osi_mode_enabled = psci_set_osi_mode() ? false : true;
>

Sure!

> > +
> > static inline bool psci_has_ext_power_state(void)
> > {
> > return psci_cpu_suspend_feature &
> > PSCI_1_0_FEATURES_CPU_SUSPEND_PF_MASK;
> > }
> >
> > -static inline bool psci_has_osi_support(void)
> > +bool psci_has_osi_support(void)
> > {
> > return psci_cpu_suspend_feature & PSCI_1_0_OS_INITIATED;
> > }
> > @@ -285,10 +299,7 @@ static int __init psci_features(u32 psci_func_id)
> > psci_func_id, 0, 0);
> > }
> >
> > -#ifdef CONFIG_CPU_IDLE
> > -static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
> > -
> > -static int psci_dt_parse_state_node(struct device_node *np, u32 *state)
> > +int psci_dt_parse_state_node(struct device_node *np, u32 *state)
> > {
> > int err = of_property_read_u32(np, "arm,psci-suspend-param", state);
> >
> > @@ -305,6 +316,9 @@ static int psci_dt_parse_state_node(struct device_node *np, u32 *state)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_CPU_IDLE
>
> It would be nicer if you can remove the CONFIG_CPU_IDLE by replacing it
> with a specific one (eg. CONFIG_PSCI_IDLE) and make it depend on
> CONFIG_CPU_IDLE, so the config options stay contained in their
> respective subsystems directory.

I am all for simplifying the Kconfig options in here, as indeed it's
rather messy. However, I would rather avoid folding in additional
cleanup changes to this series, is already extensive enough.

Would you be okay if we deal with that on top?

[...]

Kind regards
Uffe

\
 
 \ /
  Last update: 2018-12-20 16:50    [W:0.118 / U:14.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site