diff mbox series

[v10,16/27] drivers: firmware: psci: Prepare to use OS initiated suspend mode

Message ID 20181129174700.16585-17-ulf.hansson@linaro.org
State New
Headers show
Series PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) | expand

Commit Message

Ulf Hansson Nov. 29, 2018, 5:46 p.m. UTC 
To enable the OS initiated mode, the CPU topology needs to be described
using the hierarchical model in DT. When used, the idle state bits for the
CPU are created by ORing the bits for PM domain's idle state.

Let's prepare the PSCI driver to deal with this, via introducing a per CPU
variable called domain_state and by adding internal helpers to read/write
the value of the variable.

Cc: Lina Iyer <ilina@codeaurora.org>
Co-developed-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

---

Changes in v10:
	- Use __this_cpu_read|write() rather than this_cpu_read|write().

---
 drivers/firmware/psci/psci.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

-- 
2.17.1

Comments

Daniel Lezcano Dec. 20, 2018, 2:08 p.m. UTC | #1 
On 29/11/2018 18:46, Ulf Hansson wrote:
> To enable the OS initiated mode, the CPU topology needs to be described

> using the hierarchical model in DT. When used, the idle state bits for the

> CPU are created by ORing the bits for PM domain's idle state.

> 

> Let's prepare the PSCI driver to deal with this, via introducing a per CPU

> variable called domain_state and by adding internal helpers to read/write

> the value of the variable.


What are the domain states ? What values can they have ?

> Cc: Lina Iyer <ilina@codeaurora.org>

> Co-developed-by: Lina Iyer <lina.iyer@linaro.org>

> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---

> 

> Changes in v10:

> 	- Use __this_cpu_read|write() rather than this_cpu_read|write().

> 

> ---

>  drivers/firmware/psci/psci.c | 26 ++++++++++++++++++++++----

>  1 file changed, 22 insertions(+), 4 deletions(-)

> 

> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c

> index 4f0cbc95e41b..8dbcdecc2ae4 100644

> --- a/drivers/firmware/psci/psci.c

> +++ b/drivers/firmware/psci/psci.c

> @@ -87,8 +87,19 @@ static u32 psci_function_id[PSCI_FN_MAX];

>  				(PSCI_1_0_EXT_POWER_STATE_ID_MASK | \

>  				PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)

>  

> +static DEFINE_PER_CPU(u32, domain_state);

>  static u32 psci_cpu_suspend_feature;

>  

> +static inline u32 psci_get_domain_state(void)

> +{

> +	return __this_cpu_read(domain_state);

> +}

> +

> +static inline void psci_set_domain_state(u32 state)

> +{

> +	__this_cpu_write(domain_state, state);

> +}

> +

>  static inline bool psci_has_ext_power_state(void)

>  {

>  	return psci_cpu_suspend_feature &

> @@ -187,6 +198,8 @@ static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)

>  

>  	fn = psci_function_id[PSCI_FN_CPU_ON];

>  	err = invoke_psci_fn(fn, cpuid, entry_point, 0);

> +	/* Clear the domain state to start fresh. */

> +	psci_set_domain_state(0);

>  	return psci_to_linux_errno(err);


I think this change is ambiguous:

 - if it is a change of the state because of the cpu_on, then I was
expecting a similar change in cpu_off and the change only if
invoke_psci_fn() succeeds.

 - if it is a change to take opportunity of the code path to initialize
the domain state, I suggest to remove it from there and make it very
explicit with static DEFINE_PER_CPU(u32, domain_state) = { 0 };


>  }

>  

> @@ -409,15 +422,17 @@ int psci_cpu_init_idle(struct cpuidle_driver *drv, unsigned int cpu)

>  static int psci_suspend_finisher(unsigned long index)

>  {

>  	u32 *state = __this_cpu_read(psci_power_state);

> +	u32 composite_state = state[index - 1] | psci_get_domain_state();

>  

> -	return psci_ops.cpu_suspend(state[index - 1],

> -				    __pa_symbol(cpu_resume));

> +	return psci_ops.cpu_suspend(composite_state, __pa_symbol(cpu_resume));

>  }

>  

>  int psci_cpu_suspend_enter(unsigned long index)

>  {

>  	int ret;

>  	u32 *state = __this_cpu_read(psci_power_state);

> +	u32 composite_state = state[index - 1] | psci_get_domain_state();

> +

>  	/*

>  	 * idle state index 0 corresponds to wfi, should never be called

>  	 * from the cpu_suspend operations

> @@ -425,11 +440,14 @@ int psci_cpu_suspend_enter(unsigned long index)

>  	if (WARN_ON_ONCE(!index))

>  		return -EINVAL;

>  

> -	if (!psci_power_state_loses_context(state[index - 1]))

> -		ret = psci_ops.cpu_suspend(state[index - 1], 0);

> +	if (!psci_power_state_loses_context(composite_state))

> +		ret = psci_ops.cpu_suspend(composite_state, 0);

>  	else

>  		ret = cpu_suspend(index, psci_suspend_finisher);

>  

> +	/* Clear the domain state to start fresh when back from idle. */

> +	psci_set_domain_state(0);

> +

>  	return ret;

>  }

>  

> 



-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Ulf Hansson Dec. 20, 2018, 3:41 p.m. UTC | #2 
On Thu, 20 Dec 2018 at 15:09, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>

> On 29/11/2018 18:46, Ulf Hansson wrote:

> > To enable the OS initiated mode, the CPU topology needs to be described

> > using the hierarchical model in DT. When used, the idle state bits for the

> > CPU are created by ORing the bits for PM domain's idle state.

> >

> > Let's prepare the PSCI driver to deal with this, via introducing a per CPU

> > variable called domain_state and by adding internal helpers to read/write

> > the value of the variable.

>

> What are the domain states ? What values can they have ?


The existing psci_power_state, also defined as a per cpu variable,
contains fixed values reflecting the corresponding
arm,psci-suspend-param for the idle state in question.

This isn't sufficient, when using the hierarchical CPU topology in DT
and when OSI mode is supported, because of the way we vote with the
PSCI CPU suspend parameter. Parts of this parameter shall inform about
what state to allow for the cluster, while other parts tells the state
for the CPU.

The new "domain states" per CPU variable, gets dynamically changed
when actively used by following patches that implements the PSCI PM
domain support. Depending on what state the PM domain picks, the genpd
->power_off() callback sets a new "domain states" value, reflecting
the state for the cluster.

Does it makes sense? If you like, I can try to update the changelog to
clarify this?

>

> > Cc: Lina Iyer <ilina@codeaurora.org>

> > Co-developed-by: Lina Iyer <lina.iyer@linaro.org>

> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> > ---

> >

> > Changes in v10:

> >       - Use __this_cpu_read|write() rather than this_cpu_read|write().

> >

> > ---

> >  drivers/firmware/psci/psci.c | 26 ++++++++++++++++++++++----

> >  1 file changed, 22 insertions(+), 4 deletions(-)

> >

> > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c

> > index 4f0cbc95e41b..8dbcdecc2ae4 100644

> > --- a/drivers/firmware/psci/psci.c

> > +++ b/drivers/firmware/psci/psci.c

> > @@ -87,8 +87,19 @@ static u32 psci_function_id[PSCI_FN_MAX];

> >                               (PSCI_1_0_EXT_POWER_STATE_ID_MASK | \

> >                               PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)

> >

> > +static DEFINE_PER_CPU(u32, domain_state);

> >  static u32 psci_cpu_suspend_feature;

> >

> > +static inline u32 psci_get_domain_state(void)

> > +{

> > +     return __this_cpu_read(domain_state);

> > +}

> > +

> > +static inline void psci_set_domain_state(u32 state)

> > +{

> > +     __this_cpu_write(domain_state, state);

> > +}

> > +

> >  static inline bool psci_has_ext_power_state(void)

> >  {

> >       return psci_cpu_suspend_feature &

> > @@ -187,6 +198,8 @@ static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)

> >

> >       fn = psci_function_id[PSCI_FN_CPU_ON];

> >       err = invoke_psci_fn(fn, cpuid, entry_point, 0);

> > +     /* Clear the domain state to start fresh. */

> > +     psci_set_domain_state(0);

> >       return psci_to_linux_errno(err);

>

> I think this change is ambiguous:

>

>  - if it is a change of the state because of the cpu_on, then I was

> expecting a similar change in cpu_off and the change only if

> invoke_psci_fn() succeeds.


You are right. This rather belongs to patch 24, as its intent is to
deal with CPU hotplug.

>

>  - if it is a change to take opportunity of the code path to initialize

> the domain state, I suggest to remove it from there and make it very

> explicit with static DEFINE_PER_CPU(u32, domain_state) = { 0 };


We shouldn't need to explicitly set static variables to zero, as that
should be managed by the compiler.

Let me simply remove the call to  psci_set_domain_state(0) and instead
consider it for patch 24.

[...]

Thanks for reviewing!

Kind regards
Uffe
Daniel Lezcano Dec. 20, 2018, 5:16 p.m. UTC | #3 
On 20/12/2018 16:41, Ulf Hansson wrote:
> On Thu, 20 Dec 2018 at 15:09, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:

>>

>> On 29/11/2018 18:46, Ulf Hansson wrote:

>>> To enable the OS initiated mode, the CPU topology needs to be described

>>> using the hierarchical model in DT. When used, the idle state bits for the

>>> CPU are created by ORing the bits for PM domain's idle state.

>>>

>>> Let's prepare the PSCI driver to deal with this, via introducing a per CPU

>>> variable called domain_state and by adding internal helpers to read/write

>>> the value of the variable.

>>

>> What are the domain states ? What values can they have ?

> 

> The existing psci_power_state, also defined as a per cpu variable,

> contains fixed values reflecting the corresponding

> arm,psci-suspend-param for the idle state in question.

> 

> This isn't sufficient, when using the hierarchical CPU topology in DT

> and when OSI mode is supported, because of the way we vote with the

> PSCI CPU suspend parameter. Parts of this parameter shall inform about

> what state to allow for the cluster, while other parts tells the state

> for the CPU.

> 

> The new "domain states" per CPU variable, gets dynamically changed

> when actively used by following patches that implements the PSCI PM

> domain support. Depending on what state the PM domain picks, the genpd

> ->power_off() callback sets a new "domain states" value, reflecting

> the state for the cluster.

> 

> Does it makes sense? If you like, I can try to update the changelog to

> clarify this?


Yes, it makes sense. May be give a pointer or an information about the
parameter encoding in addition to the description above can help.


>>> Cc: Lina Iyer <ilina@codeaurora.org>

>>> Co-developed-by: Lina Iyer <lina.iyer@linaro.org>

>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

>>> ---

>>>

>>> Changes in v10:

>>>       - Use __this_cpu_read|write() rather than this_cpu_read|write().

>>>

>>> ---

>>>  drivers/firmware/psci/psci.c | 26 ++++++++++++++++++++++----

>>>  1 file changed, 22 insertions(+), 4 deletions(-)

>>>

>>> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c

>>> index 4f0cbc95e41b..8dbcdecc2ae4 100644

>>> --- a/drivers/firmware/psci/psci.c

>>> +++ b/drivers/firmware/psci/psci.c

>>> @@ -87,8 +87,19 @@ static u32 psci_function_id[PSCI_FN_MAX];

>>>                               (PSCI_1_0_EXT_POWER_STATE_ID_MASK | \

>>>                               PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)

>>>

>>> +static DEFINE_PER_CPU(u32, domain_state);

>>>  static u32 psci_cpu_suspend_feature;

>>>

>>> +static inline u32 psci_get_domain_state(void)

>>> +{

>>> +     return __this_cpu_read(domain_state);

>>> +}

>>> +

>>> +static inline void psci_set_domain_state(u32 state)

>>> +{

>>> +     __this_cpu_write(domain_state, state);

>>> +}

>>> +

>>>  static inline bool psci_has_ext_power_state(void)

>>>  {

>>>       return psci_cpu_suspend_feature &

>>> @@ -187,6 +198,8 @@ static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)

>>>

>>>       fn = psci_function_id[PSCI_FN_CPU_ON];

>>>       err = invoke_psci_fn(fn, cpuid, entry_point, 0);

>>> +     /* Clear the domain state to start fresh. */

>>> +     psci_set_domain_state(0);

>>>       return psci_to_linux_errno(err);

>>

>> I think this change is ambiguous:

>>

>>  - if it is a change of the state because of the cpu_on, then I was

>> expecting a similar change in cpu_off and the change only if

>> invoke_psci_fn() succeeds.

> 

> You are right. This rather belongs to patch 24, as its intent is to

> deal with CPU hotplug.

> 

>>

>>  - if it is a change to take opportunity of the code path to initialize

>> the domain state, I suggest to remove it from there and make it very

>> explicit with static DEFINE_PER_CPU(u32, domain_state) = { 0 };

> 

> We shouldn't need to explicitly set static variables to zero, as that

> should be managed by the compiler.


Yeah, that was the purpose of the *very explicit* words, that is tell
the reader, the initialization relies on the static variables being set
to zero.

> Let me simply remove the call to  psci_set_domain_state(0) and instead

> consider it for patch 24.


Yes, sure.



-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
diff mbox series

Patch

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 4f0cbc95e41b..8dbcdecc2ae4 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -87,8 +87,19 @@  static u32 psci_function_id[PSCI_FN_MAX];
 				(PSCI_1_0_EXT_POWER_STATE_ID_MASK | \
 				PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
 
+static DEFINE_PER_CPU(u32, domain_state);
 static u32 psci_cpu_suspend_feature;
 
+static inline u32 psci_get_domain_state(void)
+{
+	return __this_cpu_read(domain_state);
+}
+
+static inline void psci_set_domain_state(u32 state)
+{
+	__this_cpu_write(domain_state, state);
+}
+
 static inline bool psci_has_ext_power_state(void)
 {
 	return psci_cpu_suspend_feature &
@@ -187,6 +198,8 @@  static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)
 
 	fn = psci_function_id[PSCI_FN_CPU_ON];
 	err = invoke_psci_fn(fn, cpuid, entry_point, 0);
+	/* Clear the domain state to start fresh. */
+	psci_set_domain_state(0);
 	return psci_to_linux_errno(err);
 }
 
@@ -409,15 +422,17 @@  int psci_cpu_init_idle(struct cpuidle_driver *drv, unsigned int cpu)
 static int psci_suspend_finisher(unsigned long index)
 {
 	u32 *state = __this_cpu_read(psci_power_state);
+	u32 composite_state = state[index - 1] | psci_get_domain_state();
 
-	return psci_ops.cpu_suspend(state[index - 1],
-				    __pa_symbol(cpu_resume));
+	return psci_ops.cpu_suspend(composite_state, __pa_symbol(cpu_resume));
 }
 
 int psci_cpu_suspend_enter(unsigned long index)
 {
 	int ret;
 	u32 *state = __this_cpu_read(psci_power_state);
+	u32 composite_state = state[index - 1] | psci_get_domain_state();
+
 	/*
 	 * idle state index 0 corresponds to wfi, should never be called
 	 * from the cpu_suspend operations
@@ -425,11 +440,14 @@  int psci_cpu_suspend_enter(unsigned long index)
 	if (WARN_ON_ONCE(!index))
 		return -EINVAL;
 
-	if (!psci_power_state_loses_context(state[index - 1]))
-		ret = psci_ops.cpu_suspend(state[index - 1], 0);
+	if (!psci_power_state_loses_context(composite_state))
+		ret = psci_ops.cpu_suspend(composite_state, 0);
 	else
 		ret = cpu_suspend(index, psci_suspend_finisher);
 
+	/* Clear the domain state to start fresh when back from idle. */
+	psci_set_domain_state(0);
+
 	return ret;
 }