The current implementation of the scmi_cpufreq_init() function returns
-EPROBE_DEFER when the OPP table is not populated. In practice the
cpufreq core cannot handle this error code.
Therefore, fix the return value and clarify the error message.
Signed-off-by: Nicola Mazzucato
---
drivers
From: Sudeep Holla
Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: Sudeep Holla
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
information of CPUs under the
same performance domain from operating-points-v2 in DT, and pass it on to
EM.
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 74 +-
1 file changed, 54 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/scmi
rrors when running make dt_binding_check
* Improve commit message description for the dt-binding
* Add RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (2):
scmi-cpufreq: Remove deferred probe
scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM
Sude
Hi Viresh,
On 2/18/21 11:00 AM, Viresh Kumar wrote:
> On 15-02-21, 07:51, Nicola Mazzucato wrote:
>> +/*
>> + * Add OPPs only on those CPUs for which we haven't already done so.
>> + */
>> nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
>
> Please
Hi Viresh,
On 2/18/21 10:35 AM, Viresh Kumar wrote:
> On 15-02-21, 07:51, Nicola Mazzucato wrote:
>> The current implementation of the scmi_cpufreq_init() function returns
>> -EPROBE_DEFER when the OPP table is not populated. In practice the
>> cpufreq core cannot h
information of CPUs under the
same performance domain from operating-points-v2 in DT, and pass it on to
EM.
Reviewed-by: Ionela Voinescu
Tested-by: Ionela Voinescu
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 72 --
1 file changed, 52
From: Sudeep Holla
Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: Sudeep Holla
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
The current implementation of the scmi_cpufreq_init() function returns
-EPROBE_DEFER when the OPP table is not populated. In practice the
cpufreq core cannot handle this error code.
Therefore, fix the return value and clarify the error message.
Reviewed-by: Ionela Voinescu
Signed-off-by: Nicola
ommit message description for the dt-binding
* Add RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (2):
scmi-cpufreq: Remove deferred probe
scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM
Sudeep Holla (1):
cpufreq: blacklist Arm Vexpress platforms
PM, Cristian Marussi wrote:
> Hi Nicola,
>
> a few remarks down below.
>
> On Mon, Jan 11, 2021 at 03:45:22PM +, Nicola Mazzucato wrote:
>> Some of the cpu related initialisation can be done at probe stage.
>> This patch moves those initialisations from the ->
Hi Viresh,
many thanks for your suggestions. I will prepare a new version based on those.
Many thanks,
Nicola
On 1/14/21 5:07 AM, Viresh Kumar wrote:
> On 13-01-21, 11:55, Nicola Mazzucato wrote:
>> On 1/12/21 11:17 AM, Viresh Kumar wrote:
>>> This could have been done with
Hi Viresh, thanks for looking into this.
Please see below.
On 1/12/21 11:20 AM, Viresh Kumar wrote:
> On 11-01-21, 15:45, Nicola Mazzucato wrote:
>> By design, SCMI performance domains define the granularity of
>> performance controls, they do not describe any underlying hardware
Hi Viresh, thanks for looking into this.
Please see below.
On 1/12/21 11:17 AM, Viresh Kumar wrote:
> On 11-01-21, 15:45, Nicola Mazzucato wrote:
>> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
>> +static int scmi_init_cpudata(void)
>&g
From: Sudeep Holla
Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: Sudeep Holla
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Some of the cpu related initialisation can be done at probe stage.
This patch moves those initialisations from the ->init callback to the
probe stage.
This is done in preparation for adding support to retrieve additional
information from DT (CPUs sharing v/f lines).
Signed-off-by: Nic
information of CPUs under the
same performance domain from operating-points-v2 in DT, and pass it on to
EM.
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b
The current implementation still carries a case for a deferred probe, but
in practise this should not happen anymore.
Since the energy model expects to pass the number of OPPs, let us just
move the call dev_pm_opp_get_opp_count closer to EM registration instead.
Signed-off-by: Nicola Mazzucato
ort empty opp table
* Rework the RFC by adding a second proposal
[v2]
* Fix errors when running make dt_binding_check
* Improve commit message description for the dt-binding
* Add RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (3):
scmi-cpufreq: Rem
Hi both,
thanks for looking into this.
On 12/9/20 5:45 AM, Viresh Kumar wrote:
> On 08-12-20, 11:20, Sudeep Holla wrote:
>> It is because of per-CPU vs per domain drama here. Imagine a system with
>> 4 CPUs which the firmware puts in individual domains while they all are
>> in the same perf
The opp binding now allows to have an empty opp table and shared-opp to
still describe that devices share v/f lines.
When initialising an empty opp table, allow such case by:
- treating such conditions with warnings in place of errors
- don't fail on empty table
Signed-off-by: Nicola Mazzucato
From: Sudeep Holla
Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: Sudeep Holla
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
information of CPUs under the
same performance domain from operating-points-v2 in DT, and pass it on to
EM.
As part of the rework, the deferred probe is also removed as this
condition should never occur.
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 69
ion for the dt-binding
* Add RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (3):
dt-bindings: opp: Allow empty OPP tables
opp/of: Allow empty opp-table with opp-shared
scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM
Sudeep Holla (1):
cpufreq: blackl
other means (hardware. firmware, etc).
Update the documentation to remark this additional case and provide an
example.
Signed-off-by: Nicola Mazzucato
---
Documentation/devicetree/bindings/opp/opp.txt | 54 ++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git
wrote:
>>>> On 08-12-20, 07:22, Nicola Mazzucato wrote:
>>>>> On 12/8/20 5:50 AM, Viresh Kumar wrote:
>>>>>> On 02-12-20, 17:23, Nicola Mazzucato wrote:
>>>>>>> nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
>>>&g
On 12/8/20 7:26 AM, Viresh Kumar wrote:
> On 08-12-20, 07:22, Nicola Mazzucato wrote:
>> On 12/8/20 5:50 AM, Viresh Kumar wrote:
>>> On 02-12-20, 17:23, Nicola Mazzucato wrote:
>>>>nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
>>>>if (nr_opp <
Hi Viresh,
thanks for looking into this. Please find below
On 12/8/20 5:50 AM, Viresh Kumar wrote:
> On 02-12-20, 17:23, Nicola Mazzucato wrote:
>> By design, SCMI performance domains define the granularity of
>> performance controls, they do not describe any underlying hardware
Hi Viresh,
thanks for your comments. I will update subject and content as you suggested.
Regards,
Nicola
On 12/8/20 4:29 AM, Viresh Kumar wrote:
> Subject should rather be:
>
> dt-bindings: opp: Allow empty OPP tables
>
> On 02-12-20, 17:23, Nicola Mazzucato wrote:
>> C
From: Sudeep Holla
Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: Sudeep Holla
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
information of CPUs under the
same v/f domain from operating-points-v2 in DT, and pass it on to EM.
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 51 +++---
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/cpufreq/scmi
RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (3):
dt-bindings/opp: Update documentation for opp-shared
opp/of: Allow empty opp-table with opp-shared
scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM
Sudeep Holla (1):
cpufreq: blacklist Arm Vexpress platfo
The opp binding now allows to have an empty opp table and shared-opp to
still describe that devices share v/f lines.
When initialising an empty opp table, allow such case by:
- treating such conditions with warnings in place of errors
- don't fail on empty table
Signed-off-by: Nicola Mazzucato
other means (hardware. firmware, etc).
Update the documentation to remark this additional case and provide an
example.
Signed-off-by: Nicola Mazzucato
---
Documentation/devicetree/bindings/opp/opp.txt | 53 +++
1 file changed, 53 insertions(+)
diff --git a/Documentation
Hi Viresh,
On 11/17/20 10:11 AM, Viresh Kumar wrote:
> On 16-11-20, 11:33, Lukasz Luba wrote:
>> On 11/9/20 6:57 AM, Viresh Kumar wrote:
>>> On 06-11-20, 11:14, Lukasz Luba wrote:
I also had similar doubts, because if we make frequency requests
independently for each CPU, why not
Hi Viresh,
sorry for being late in replying.
On 11/5/20 4:41 AM, Viresh Kumar wrote:
> On 04-11-20, 17:54, Nicola Mazzucato wrote:
>> Initially I thought to place a comment right there but I ended up with an
>> explanation of this case at the top of this function (
Hi Viresh, thanks for looking into this.
On 11/3/20 10:18 AM, Viresh Kumar wrote:
> On 02-11-20, 12:01, Nicola Mazzucato wrote:
>> Hi All,
>>
>> In this V3 posting I have replaced the new dt-binding with minor changes/
>> improvements for opp (since we are n
Hi Viresh, thanks for looking into this.
On 11/3/20 5:01 AM, Viresh Kumar wrote:
> On 02-11-20, 12:01, Nicola Mazzucato wrote:
>> The opp binding now allows to have an empty opp table and shared-opp to
>> merely describe a hw connection among devices (f/v lines).
>>
>&g
-by: Nicola Mazzucato
---
drivers/opp/of.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 874b58756220..b0230490bb31 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -157,6 +157,11 @@ static void
other means (hardware. firmware, etc).
Update the documentation to remark this additional case and provide an
example.
Signed-off-by: Nicola Mazzucato
---
Documentation/devicetree/bindings/opp/opp.txt | 53 +++
1 file changed, 53 insertions(+)
diff --git a/Documentation
Hi All,
This is a continuation of the previous v2, where we focused mostly on the
dt binding.
I am seeking some feedback/comments on the following two approaches.
Intro:
We have seen that in a system where performance control and hardware
description do not match (i.e. per-cpu), we still need
by adding a second proposal
[v2]
* Fix errors when running make dt_binding_check
* Improve commit message description for the dt-binding
* Add RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (3):
dt-bindings/opp: Update documentation for opp-shared
opp
Hi Viresh,
On 10/19/20 10:46 AM, Viresh Kumar wrote:
> On 19-10-20, 09:50, Nicola Mazzucato wrote:
>> Hi Viresh,
>>
>> thank you for your suggestion on using 'opp-shared'.
>> I think it could work for most of the cases we explained earlier.
>>
>> Summaris
Hi Viresh,
thank you for your suggestion on using 'opp-shared'.
I think it could work for most of the cases we explained earlier.
Summarising, there are two parts of this entire proposal:
1) where/how to get the information: now we are focusing on taking advantage of
'opp-shared' within an empty
Hi Viresh and Rob,
first of all, thanks once again for looking into this!
On 10/9/20 3:01 PM, Rob Herring wrote:
> On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
>> Hi Viresh, I'm glad it helped.
>>
>> Please find below my reply.
>>
>> On 10
Hi Viresh, I'm glad it helped.
Please find below my reply.
On 10/9/20 6:39 AM, Viresh Kumar wrote:
> On 08-10-20, 17:00, Nicola Mazzucato wrote:
>> On 10/8/20 4:03 PM, Ionela Voinescu wrote:
>>> Hi Viresh,
>>>
>>> On Thursday 08 Oct 2020 at 16:32:41 (+0530),
07-10-20, 13:58, Nicola Mazzucato wrote:
>>> Hi Viresh,
>>>
>>> performance controls is what is exposed by the firmware through a protocol
>>> that
>>> is not capable of describing hardware (say SCMI). For example, the firmware
>>> can
>>
nality we can use the optional node
'cpu-performance-dependencies' in dt which will provide such dependency
information and we can add a new cpumask 'dependency_cpus' in policy.
Hope it gives some clarity.
Nicola
On 10/6/20 8:19 AM, Viresh Kumar wrote:
> On 24-09-20, 10:53, Nicola Mazz
I am seeking some feedback/comments on the following approach.
Intro:
Info of performance depency for cpus will be beneficial for systems
where f/w description of the CPU performance control domain is different
from the clock domain, e.g. per-CPU control with multiple CPUs sharing
clock, and
.3 - 8.3 Power, Performance, and Throttling
State Dependencies
Signed-off-by: Nicola Mazzucato
---
.../bindings/arm/cpu-perf-dependencies.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
diff --git a
* Improve commit message description for the dt-binding
* Add RFC for implementation in cpufreq-core and one of its
drivers.
Nicola Mazzucato (2):
dt-bindings: arm: Add devicetree binding for
cpu-performance-dependencies
[RFC] CPUFreq: Add support for cpu-perf-dependencies
On 9/8/20 8:26 PM, Rob Herring wrote:
> On Tue, Sep 8, 2020 at 8:53 AM Nicola Mazzucato
> wrote:
Hi Rob, thanks for your prompt reply. Please find my comments below.
> So while this resend fixes the problem of not getting into DT
> patchwork, you've dropped everyone else. The c
r, Performance, and Throttling
State Dependencies
Signed-off-by: Nicola Mazzucato
---
.../bindings/arm/cpu-perf-dependencies.yaml | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
diff --git a
an
operation that is not supported by the platform.
Fix this by correctly retrieve the fast_switch capability
from the driver which knows if the platform can support
this feature.
Suggested-by: Lukasz Luba
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 3 ++-
1 file changed, 2
-by: Nicola Mazzucato
---
drivers/firmware/arm_scmi/perf.c | 12
include/linux/scmi_protocol.h| 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index eadc171e254b..ef747a9bb948 100644
--- a/drivers/firmware
55 matches
Mail list logo
