Re: SCMI & Devfreq

Re: SCMI & Devfreq

[Sudeep Holla]

On Thu, Sep 12, 2019 at 06:55:36PM +0000, Sujeet Kumar Baranwal wrote:
> Hi,
>
> I am a recent adopter of SCMI protocol on marvell processors and has been
> able to use cpufreq governor using scmi-cpufreq frame work to change CPU
> frequency.
>

Good, but just a quick question to check if this is ACPI or DT based
platform ? That matter a lot to answer you query.

> While SCMI_PERFORMANCE_PROTOCL allows multiple "domains" to be created, each
> domain representing one clock with several OPPs, it works well.

OK

> For sysfs command like "cat > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor".

I don't understand the context of above statement.

> I am trying to find how SCMI could help in similar facilities when it comes
> to devfreq for device specific OPP variation.

Yes it needs some work and I do have some prototype, but with no users
in the upstream, I haven't added it yet.

> If someone did similar work done or doing, please enlighten me too.
>

What kind of devices are these ? There was some work around generic
devfreq driver that I had seen on the list and my plan was to do something
similar, I need to dig up details as it was while ago.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: SCMI & Devfreq

[Sujeet Kumar Baranwal]

Thanks Sudeep.

>> Good, but just a quick question to check if this is ACPI or DT based platform ?
DT based.


>> Yes it needs some work and I do have some prototype, but with no users in the upstream, I haven't added it yet.
>>What kind of devices are these ? There was some work around generic devfreq driver that I had seen >>on the list and my plan was to do something similar, I need to dig up details as it was while ago.


These are devices needing dedicated clocks like dsp engines. There is a need for a userspace dev governor controlling the frequency in different situation. 
Could you please share your patches and any instructions if needed.

Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com> 
Sent: Friday, September 13, 2019 3:23 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org; Sudeep Holla <sudeep.holla@arm.com>
Subject: [EXT] Re: SCMI & Devfreq

External Email

----------------------------------------------------------------------
On Thu, Sep 12, 2019 at 06:55:36PM +0000, Sujeet Kumar Baranwal wrote:
> Hi,
>
> I am a recent adopter of SCMI protocol on marvell processors and has 
> been able to use cpufreq governor using scmi-cpufreq frame work to 
> change CPU frequency.
>

Good, but just a quick question to check if this is ACPI or DT based platform ? That matter a lot to answer you query.

> While SCMI_PERFORMANCE_PROTOCL allows multiple "domains" to be 
> created, each domain representing one clock with several OPPs, it works well.

OK

> For sysfs command like "cat > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor".

I don't understand the context of above statement.

> I am trying to find how SCMI could help in similar facilities when it 
> comes to devfreq for device specific OPP variation.

Yes it needs some work and I do have some prototype, but with no users in the upstream, I haven't added it yet.

> If someone did similar work done or doing, please enlighten me too.
>

What kind of devices are these ? There was some work around generic devfreq driver that I had seen on the list and my plan was to do something similar, I need to dig up details as it was while ago.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: SCMI & Devfreq

[Sudeep Holla]

On Mon, Sep 16, 2019 at 05:22:02AM +0000, Sujeet Kumar Baranwal wrote:
> Thanks Sudeep.
>
>>> Good, but just a quick question to check if this is ACPI or DT based
>>> platform ?
>
> DT based.
>

Good.

>>> Yes it needs some work and I do have some prototype, but with no users in
>>> the upstream, I haven't added it yet.
>>> What kind of devices are these ? There was some work around generic
>>> devfreq driver that I had seen >>on the list and my plan was to do
>>> something similar, I need to dig up details as it was while ago.
>
> These are devices needing dedicated clocks like dsp engines. There is a need
> for a userspace dev governor controlling the frequency in different
> situation.

Okay, thanks for the info.

> Could you please share your patches and any instructions if needed.
>

It needs some polishing before I post them externally, they are still
hackish. I will do soonish.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: SCMI & Devfreq

[Sujeet Kumar Baranwal]

Ok, Sudeep. I would wait for your mail.

Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com> 
Sent: Monday, September 16, 2019 3:15 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [EXT] Re: SCMI & Devfreq

On Mon, Sep 16, 2019 at 05:22:02AM +0000, Sujeet Kumar Baranwal wrote:
> Thanks Sudeep.
>
>>> Good, but just a quick question to check if this is ACPI or DT based 
>>> platform ?
>
> DT based.
>

Good.

>>> Yes it needs some work and I do have some prototype, but with no 
>>> users in the upstream, I haven't added it yet.
>>> What kind of devices are these ? There was some work around generic 
>>> devfreq driver that I had seen >>on the list and my plan was to do 
>>> something similar, I need to dig up details as it was while ago.
>
> These are devices needing dedicated clocks like dsp engines. There is 
> a need for a userspace dev governor controlling the frequency in 
> different situation.

Okay, thanks for the info.

> Could you please share your patches and any instructions if needed.
>

It needs some polishing before I post them externally, they are still hackish. I will do soonish.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: SCMI & Devfreq

[Sujeet Kumar Baranwal]

Sudeep, One trivial question wrt SCMI-CPUFREQ framework.

The SCMI perf protocol would tell what are different frequencies the platform support in the beginning.
For example, the command :
cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
shows:
280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 2800000

/* Attempt to change the frequency */
~ # echo 2240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
It works.

But in a scenario, where user tries a number which is not listed, SCP applies its own logic to get a nearby value frequency for CPU and returns.

My question is that could we add some print message in kernel that user wish is not exactly fulfilled, an approximation has been done so the user explicitly knows his command has been partially met.  If this to happen, a patch might be needed in kernel. What is your opinion?

Regards
Sujeet
-----Original Message-----
From: Sujeet Kumar Baranwal 
Sent: Monday, September 16, 2019 10:37 AM
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: RE: [EXT] Re: SCMI & Devfreq

Ok, Sudeep. I would wait for your mail.

Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com>
Sent: Monday, September 16, 2019 3:15 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [EXT] Re: SCMI & Devfreq

On Mon, Sep 16, 2019 at 05:22:02AM +0000, Sujeet Kumar Baranwal wrote:
> Thanks Sudeep.
>
>>> Good, but just a quick question to check if this is ACPI or DT based 
>>> platform ?
>
> DT based.
>

Good.

>>> Yes it needs some work and I do have some prototype, but with no 
>>> users in the upstream, I haven't added it yet.
>>> What kind of devices are these ? There was some work around generic 
>>> devfreq driver that I had seen >>on the list and my plan was to do 
>>> something similar, I need to dig up details as it was while ago.
>
> These are devices needing dedicated clocks like dsp engines. There is 
> a need for a userspace dev governor controlling the frequency in 
> different situation.

Okay, thanks for the info.

> Could you please share your patches and any instructions if needed.
>

It needs some polishing before I post them externally, they are still hackish. I will do soonish.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: SCMI & Devfreq

[Sudeep Holla]

(Adding linux-pm list)

On Wed, Sep 18, 2019 at 10:53:07PM +0000, Sujeet Kumar Baranwal wrote:
> Sudeep, One trivial question wrt SCMI-CPUFREQ framework.
> 
> The SCMI perf protocol would tell what are different frequencies the
> platform support in the beginning.
>
> For example, the command :
> cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> shows:
> 280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 2800000
>
> /* Attempt to change the frequency */
> ~ # echo 2240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> It works.
>
> But in a scenario, where user tries a number which is not listed, SCP
> applies its own logic to get a nearby value frequency for CPU and returns.
>
> My question is that could we add some print message in kernel that user wish
> is not exactly fulfilled, an approximation has been done so the user
> explicitly knows his command has been partially met.  If this to happen, a
> patch might be needed in kernel. What is your opinion?
>

May be, you need to check with the maintainers ? :)

The path of execution is:
cpufreq_set(policy, freq) [cpufreq_userspace.c]
__cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L) [cpufreq_userspace.c]
index = cpufreq_frequency_table_target(policy, target_freq, relation) [cpufreq.c]
__target_index(policy, index) [cpufreq.c]

So if you need logs, it needs to be in core file rather than individual
drivers.

--
Regards,
Sudeep

Re: [EXT] Re: SCMI & Devfreq

[Sudeep Holla]

(Adding linux-pm list)

On Wed, Sep 18, 2019 at 10:53:07PM +0000, Sujeet Kumar Baranwal wrote:
> Sudeep, One trivial question wrt SCMI-CPUFREQ framework.
> 
> The SCMI perf protocol would tell what are different frequencies the
> platform support in the beginning.
>
> For example, the command :
> cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> shows:
> 280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 2800000
>
> /* Attempt to change the frequency */
> ~ # echo 2240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> It works.
>
> But in a scenario, where user tries a number which is not listed, SCP
> applies its own logic to get a nearby value frequency for CPU and returns.
>
> My question is that could we add some print message in kernel that user wish
> is not exactly fulfilled, an approximation has been done so the user
> explicitly knows his command has been partially met.  If this to happen, a
> patch might be needed in kernel. What is your opinion?
>

May be, you need to check with the maintainers ? :)

The path of execution is:
cpufreq_set(policy, freq) [cpufreq_userspace.c]
__cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L) [cpufreq_userspace.c]
index = cpufreq_frequency_table_target(policy, target_freq, relation) [cpufreq.c]
__target_index(policy, index) [cpufreq.c]

So if you need logs, it needs to be in core file rather than individual
drivers.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: SCMI & Devfreq

[Sujeet Kumar Baranwal]

Hi Sudeep,

Per SCMI perf protocol, the MAX_OPPS macro which is 16, means that at max there could be only 16 OPPs.
In my platform implementation, I tried with 16 OPPs but  when OPPs info came linux perf.c file from SCP, it only showed 12 OPPs only.

Suspecting the rx buffer size, I increased the size to 256 and now the message for all 16 OPPs were reliably received. 

*****************
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 449f713..737d675 100644 (file)
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -612,7 +612,7 @@ int scmi_handle_put(const struct scmi_handle *handle)
 static const struct scmi_desc scmi_generic_desc = {
        .max_rx_timeout_ms = 30,        /* We may increase this if required */
        .max_msg = 20,          /* Limited by MBOX_TX_QUEUE_LEN */
-       .max_msg_size = 128,
+       .max_msg_size = 256,
 };
 
 /* Each compatible listed below must have descriptor associated with it */
*****************
Since this is a legit case of having 16 or more OPPs, we need to have a bugger buffer for rx. Let me know what you think.

Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com> 
Sent: Thursday, September 19, 2019 8:23 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org; Sudeep Holla <sudeep.holla@arm.com>; linux-pm@vger.kernel.org
Subject: Re: [EXT] Re: SCMI & Devfreq

(Adding linux-pm list)

On Wed, Sep 18, 2019 at 10:53:07PM +0000, Sujeet Kumar Baranwal wrote:
> Sudeep, One trivial question wrt SCMI-CPUFREQ framework.
> 
> The SCMI perf protocol would tell what are different frequencies the 
> platform support in the beginning.
>
> For example, the command :
> cat  
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> shows:
> 280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 
> 2800000
>
> /* Attempt to change the frequency */
> ~ # echo 2240000 > 
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> It works.
>
> But in a scenario, where user tries a number which is not listed, SCP 
> applies its own logic to get a nearby value frequency for CPU and returns.
>
> My question is that could we add some print message in kernel that 
> user wish is not exactly fulfilled, an approximation has been done so 
> the user explicitly knows his command has been partially met.  If this 
> to happen, a patch might be needed in kernel. What is your opinion?
>

May be, you need to check with the maintainers ? :)

The path of execution is:
cpufreq_set(policy, freq) [cpufreq_userspace.c] __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L) [cpufreq_userspace.c] index = cpufreq_frequency_table_target(policy, target_freq, relation) [cpufreq.c] __target_index(policy, index) [cpufreq.c]

So if you need logs, it needs to be in core file rather than individual drivers.

--
Regards,
Sudeep

RE: [EXT] Re: SCMI & Devfreq

[Sujeet Kumar Baranwal]

Hi Sudeep,

Per SCMI perf protocol, the MAX_OPPS macro which is 16, means that at max there could be only 16 OPPs.
In my platform implementation, I tried with 16 OPPs but  when OPPs info came linux perf.c file from SCP, it only showed 12 OPPs only.

Suspecting the rx buffer size, I increased the size to 256 and now the message for all 16 OPPs were reliably received. 

*****************
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 449f713..737d675 100644 (file)
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -612,7 +612,7 @@ int scmi_handle_put(const struct scmi_handle *handle)
 static const struct scmi_desc scmi_generic_desc = {
        .max_rx_timeout_ms = 30,        /* We may increase this if required */
        .max_msg = 20,          /* Limited by MBOX_TX_QUEUE_LEN */
-       .max_msg_size = 128,
+       .max_msg_size = 256,
 };
 
 /* Each compatible listed below must have descriptor associated with it */
*****************
Since this is a legit case of having 16 or more OPPs, we need to have a bugger buffer for rx. Let me know what you think.

Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com> 
Sent: Thursday, September 19, 2019 8:23 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org; Sudeep Holla <sudeep.holla@arm.com>; linux-pm@vger.kernel.org
Subject: Re: [EXT] Re: SCMI & Devfreq

(Adding linux-pm list)

On Wed, Sep 18, 2019 at 10:53:07PM +0000, Sujeet Kumar Baranwal wrote:
> Sudeep, One trivial question wrt SCMI-CPUFREQ framework.
> 
> The SCMI perf protocol would tell what are different frequencies the 
> platform support in the beginning.
>
> For example, the command :
> cat  
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> shows:
> 280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 
> 2800000
>
> /* Attempt to change the frequency */
> ~ # echo 2240000 > 
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> It works.
>
> But in a scenario, where user tries a number which is not listed, SCP 
> applies its own logic to get a nearby value frequency for CPU and returns.
>
> My question is that could we add some print message in kernel that 
> user wish is not exactly fulfilled, an approximation has been done so 
> the user explicitly knows his command has been partially met.  If this 
> to happen, a patch might be needed in kernel. What is your opinion?
>

May be, you need to check with the maintainers ? :)

The path of execution is:
cpufreq_set(policy, freq) [cpufreq_userspace.c] __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L) [cpufreq_userspace.c] index = cpufreq_frequency_table_target(policy, target_freq, relation) [cpufreq.c] __target_index(policy, index) [cpufreq.c]

So if you need logs, it needs to be in core file rather than individual drivers.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: SCMI & Devfreq

[Sudeep Holla]

On Mon, Oct 07, 2019 at 06:20:40PM +0000, Sujeet Kumar Baranwal wrote:
> Hi Sudeep,
>
> Per SCMI perf protocol, the MAX_OPPS macro which is 16, means that at max
> there could be only 16 OPPs. In my platform implementation, I tried with 16
> OPPs but  when OPPs info came linux perf.c file from SCP, it only showed 12
> OPPs only.
>
> Suspecting the rx buffer size, I increased the size to 256 and now the
> message for all 16 OPPs were reliably received.
>

OK, but is there any reason why firmware can't use num_levels[31:16]
i.e Number of remaining performance levels and [11:00] i.e.Number of
performance levels that are returned by this call to break and send in
2 calls ? The interface was designed to work with minimum shmem size.


> *****************
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 449f713..737d675 100644 (file)
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -612,7 +612,7 @@ int scmi_handle_put(const struct scmi_handle *handle)
>  static const struct scmi_desc scmi_generic_desc = {
>         .max_rx_timeout_ms = 30,        /* We may increase this if required */
>         .max_msg = 20,          /* Limited by MBOX_TX_QUEUE_LEN */
> -       .max_msg_size = 128,
> +       .max_msg_size = 256,

If you need this, I prefer to introduce new compatible for the platform
scmi and add it as platform specific scmi_desc to start with.

--
Regards,
Sudeep

Re: [EXT] Re: SCMI & Devfreq

[Sudeep Holla]

On Mon, Oct 07, 2019 at 06:20:40PM +0000, Sujeet Kumar Baranwal wrote:
> Hi Sudeep,
>
> Per SCMI perf protocol, the MAX_OPPS macro which is 16, means that at max
> there could be only 16 OPPs. In my platform implementation, I tried with 16
> OPPs but  when OPPs info came linux perf.c file from SCP, it only showed 12
> OPPs only.
>
> Suspecting the rx buffer size, I increased the size to 256 and now the
> message for all 16 OPPs were reliably received.
>

OK, but is there any reason why firmware can't use num_levels[31:16]
i.e Number of remaining performance levels and [11:00] i.e.Number of
performance levels that are returned by this call to break and send in
2 calls ? The interface was designed to work with minimum shmem size.


> *****************
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 449f713..737d675 100644 (file)
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -612,7 +612,7 @@ int scmi_handle_put(const struct scmi_handle *handle)
>  static const struct scmi_desc scmi_generic_desc = {
>         .max_rx_timeout_ms = 30,        /* We may increase this if required */
>         .max_msg = 20,          /* Limited by MBOX_TX_QUEUE_LEN */
> -       .max_msg_size = 128,
> +       .max_msg_size = 256,

If you need this, I prefer to introduce new compatible for the platform
scmi and add it as platform specific scmi_desc to start with.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel