* [Patch 0/2] Tegra194 cpufreq driver misc changes
@ 2020-09-16 17:11 Sumit Gupta
2020-09-16 17:11 ` [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq Sumit Gupta
2020-09-16 17:11 ` [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning Sumit Gupta
0 siblings, 2 replies; 18+ messages in thread
From: Sumit Gupta @ 2020-09-16 17:11 UTC (permalink / raw)
To: viresh.kumar, rjw, thierry.reding, jonathanh, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel
Cc: ksitaraman, sumitg, bbasu
This patch set has below two changes:
1) get consistent cpuinfo_cur_freq value from freq_table.
2) Fix unlisted boot freq warning by setting closest ndiv value
from freq_table if the boot frequency gets filtered while
creating freq_table in kernel.
Sumit Gupta (2):
cpufreq: tegra194: get consistent cpuinfo_cur_freq
cpufreq: tegra194: Fix unlisted boot freq warning
drivers/cpufreq/tegra194-cpufreq.c | 182 ++++++++++++++++++++++++++++++++++---
1 file changed, 167 insertions(+), 15 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-16 17:11 [Patch 0/2] Tegra194 cpufreq driver misc changes Sumit Gupta
@ 2020-09-16 17:11 ` Sumit Gupta
2020-09-17 8:36 ` Jon Hunter
` (2 more replies)
2020-09-16 17:11 ` [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning Sumit Gupta
1 sibling, 3 replies; 18+ messages in thread
From: Sumit Gupta @ 2020-09-16 17:11 UTC (permalink / raw)
To: viresh.kumar, rjw, thierry.reding, jonathanh, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel
Cc: ksitaraman, sumitg, bbasu
Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
and keeps changing slightly. This change returns a consistent value
from freq_table. If the reconstructed frequency has acceptable delta
from the last written value, then return the frequency corresponding
to the last written ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
---
drivers/cpufreq/tegra194-cpufreq.c | 66 ++++++++++++++++++++++++++++++++------
1 file changed, 57 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c
index e1d931c..d5b608d 100644
--- a/drivers/cpufreq/tegra194-cpufreq.c
+++ b/drivers/cpufreq/tegra194-cpufreq.c
@@ -180,9 +180,65 @@ static unsigned int tegra194_get_speed_common(u32 cpu, u32 delay)
return (rate_mhz * KHZ); /* in KHz */
}
+static void get_cpu_ndiv(void *ndiv)
+{
+ u64 ndiv_val;
+
+ asm volatile("mrs %0, s3_0_c15_c0_4" : "=r" (ndiv_val) : );
+
+ *(u64 *)ndiv = ndiv_val;
+}
+
+static void set_cpu_ndiv(void *data)
+{
+ struct cpufreq_frequency_table *tbl = data;
+ u64 ndiv_val = (u64)tbl->driver_data;
+
+ asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
+}
+
static unsigned int tegra194_get_speed(u32 cpu)
{
- return tegra194_get_speed_common(cpu, US_DELAY);
+ struct cpufreq_frequency_table *table, *pos;
+ struct cpufreq_policy policy;
+ unsigned int rate;
+ u64 ndiv;
+ int err;
+
+ cpufreq_get_policy(&policy, cpu);
+ table = policy.freq_table;
+
+ /* reconstruct actual cpu freq using counters*/
+ rate = tegra194_get_speed_common(cpu, US_DELAY);
+
+ /* get last written ndiv value*/
+ err = smp_call_function_single(cpu, get_cpu_ndiv, &ndiv, true);
+ if (err) {
+ pr_err("cpufreq: Failed to get ndiv for CPU%d, ret:%d\n",
+ cpu, err);
+ return rate;
+ }
+
+ /* if the reconstructed frequency has acceptable delta from
+ * the last written value, then return freq corresponding
+ * to the last written ndiv value from freq_table. This is
+ * done to return consistent value.
+ */
+ cpufreq_for_each_valid_entry(pos, table) {
+ if (pos->driver_data != ndiv)
+ continue;
+
+ if (abs(pos->frequency - rate) > 115200) {
+ pr_warn("cpufreq: high delta (%d) on CPU%d\n",
+ abs(pos->frequency - rate), cpu);
+ pr_warn("cpufreq: cur:%u, set:%u, set ndiv:%llu\n",
+ rate, pos->frequency, ndiv);
+ } else {
+ rate = pos->frequency;
+ }
+ break;
+ }
+ return rate;
}
static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
@@ -209,14 +265,6 @@ static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
return 0;
}
-static void set_cpu_ndiv(void *data)
-{
- struct cpufreq_frequency_table *tbl = data;
- u64 ndiv_val = (u64)tbl->driver_data;
-
- asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
-}
-
static int tegra194_cpufreq_set_target(struct cpufreq_policy *policy,
unsigned int index)
{
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-09-16 17:11 [Patch 0/2] Tegra194 cpufreq driver misc changes Sumit Gupta
2020-09-16 17:11 ` [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq Sumit Gupta
@ 2020-09-16 17:11 ` Sumit Gupta
2020-09-17 8:38 ` Jon Hunter
` (2 more replies)
1 sibling, 3 replies; 18+ messages in thread
From: Sumit Gupta @ 2020-09-16 17:11 UTC (permalink / raw)
To: viresh.kumar, rjw, thierry.reding, jonathanh, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel
Cc: ksitaraman, sumitg, bbasu
Warning coming during boot because the boot freq set by bootloader
gets filtered out due to big freq steps while creating freq_table.
Fixing this by setting closest ndiv value from freq_table.
Warning:
cpufreq: cpufreq_online: CPU0: Running at unlisted freq
cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
Also, added change in init to wait till current frequency becomes
equal or near to the previously requested frequency. This is done
because it takes some time to restore the previous frequency while
turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
---
drivers/cpufreq/tegra194-cpufreq.c | 118 ++++++++++++++++++++++++++++++++++---
1 file changed, 111 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c
index d5b608d..c3c058a3 100644
--- a/drivers/cpufreq/tegra194-cpufreq.c
+++ b/drivers/cpufreq/tegra194-cpufreq.c
@@ -7,6 +7,7 @@
#include <linux/cpufreq.h>
#include <linux/delay.h>
#include <linux/dma-mapping.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
@@ -21,7 +22,6 @@
#define KHZ 1000
#define REF_CLK_MHZ 408 /* 408 MHz */
#define US_DELAY 500
-#define US_DELAY_MIN 2
#define CPUFREQ_TBL_STEP_HZ (50 * KHZ * KHZ)
#define MAX_CNT ~0U
@@ -241,26 +241,130 @@ static unsigned int tegra194_get_speed(u32 cpu)
return rate;
}
+static int
+freqtable_find_index_closest_ndiv(struct cpufreq_frequency_table *table,
+ unsigned int target_ndiv)
+{
+ struct cpufreq_frequency_table *pos;
+ unsigned int ndiv;
+ int idx, best = -1;
+
+ cpufreq_for_each_valid_entry_idx(pos, table, idx) {
+ ndiv = pos->driver_data;
+
+ if (ndiv == target_ndiv)
+ return idx;
+
+ if (ndiv < target_ndiv) {
+ best = idx;
+ continue;
+ }
+
+ /* No ndiv found below target_ndiv */
+ if (best == -1)
+ return idx;
+
+ /* Choose the closest ndiv */
+ if (target_ndiv - table[best].driver_data > ndiv - target_ndiv)
+ return idx;
+
+ return best;
+ }
+
+ return best;
+}
+
+static int
+freqtable_set_closest_ndiv(struct cpufreq_frequency_table *freq_table,
+ int cpu)
+{
+ u64 ndiv;
+ int idx, ret;
+
+ if (!cpu_online(cpu))
+ return -EINVAL;
+
+ /* get ndiv for the last frequency request from software */
+ ret = smp_call_function_single(cpu, get_cpu_ndiv, &ndiv, true);
+ if (ret) {
+ pr_err("cpufreq: Failed to get ndiv for CPU%d\n", cpu);
+ return ret;
+ }
+
+ /* while creating freq_table during boot, if the ndiv value got
+ * filtered out due to large freq steps, then find closest ndiv
+ * from freq_table and set that.
+ */
+ idx = freqtable_find_index_closest_ndiv(freq_table, ndiv);
+
+ if (ndiv != freq_table[idx].driver_data) {
+ pr_debug("cpufreq: new freq:%d ndiv:%d, old ndiv:%llu\n",
+ freq_table[idx].frequency,
+ freq_table[idx].driver_data, ndiv);
+
+ ret = smp_call_function_single(cpu, set_cpu_ndiv,
+ freq_table + idx, true);
+ if (ret) {
+ pr_err("cpufreq: setting ndiv for CPU%d failed\n",
+ cpu);
+ return ret;
+ }
+ }
+
+ return freq_table[idx].frequency;
+}
+
static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
{
struct tegra194_cpufreq_data *data = cpufreq_get_driver_data();
- u32 cpu;
+ u32 cpu = policy->cpu;
+ int new_freq, ret;
u32 cl;
- smp_call_function_single(policy->cpu, get_cpu_cluster, &cl, true);
+ if (!cpu_online(cpu))
+ return -EINVAL;
+
+ ret = smp_call_function_single(cpu, get_cpu_cluster, &cl, true);
+ if (ret) {
+ pr_err("cpufreq: Failed to get cluster for CPU%d\n", cpu);
+ return ret;
+ }
if (cl >= data->num_clusters)
return -EINVAL;
- /* boot freq */
- policy->cur = tegra194_get_speed_common(policy->cpu, US_DELAY_MIN);
-
/* set same policy for all cpus in a cluster */
for (cpu = (cl * 2); cpu < ((cl + 1) * 2); cpu++)
cpumask_set_cpu(cpu, policy->cpus);
policy->freq_table = data->tables[cl];
- policy->cpuinfo.transition_latency = TEGRA_CPUFREQ_TRANSITION_LATENCY;
+ policy->cpuinfo.transition_latency =
+ TEGRA_CPUFREQ_TRANSITION_LATENCY;
+
+ /* Find and set the closest ndiv from freq_table if the boot freq
+ * already set is filtered out from freq_table or not present.
+ */
+ new_freq = freqtable_set_closest_ndiv(policy->freq_table, policy->cpu);
+ if (new_freq < 0) {
+ pr_err("cpufreq: set closest ndiv for CPU%d failed(%d)\n",
+ policy->cpu, new_freq);
+ return new_freq;
+ }
+
+ /* It takes some time to restore the previous frequency while
+ * turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
+ * So, wait till it reaches the previous value and timeout if the
+ * time taken to reach requested freq is >100ms
+ */
+ ret = read_poll_timeout(tegra194_get_speed_common, policy->cur,
+ abs(policy->cur - new_freq) <= 115200, 0,
+ 100 * USEC_PER_MSEC, false, policy->cpu,
+ US_DELAY);
+ if (ret)
+ pr_warn("cpufreq: time taken to restore freq >100ms\n");
+
+ pr_debug("cpufreq: cpu%d, curfreq:%d, setfreq:%d\n", policy->cpu,
+ policy->cur, new_freq);
return 0;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-16 17:11 ` [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq Sumit Gupta
@ 2020-09-17 8:36 ` Jon Hunter
2020-09-17 8:44 ` Jon Hunter
2020-10-05 4:34 ` Viresh Kumar
2020-09-24 8:56 ` Thierry Reding
2020-10-05 4:46 ` Viresh Kumar
2 siblings, 2 replies; 18+ messages in thread
From: Jon Hunter @ 2020-09-17 8:36 UTC (permalink / raw)
To: Sumit Gupta, viresh.kumar, rjw, thierry.reding, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel
Cc: ksitaraman, bbasu
On 16/09/2020 18:11, Sumit Gupta wrote:
> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
> and keeps changing slightly. This change returns a consistent value
> from freq_table. If the reconstructed frequency has acceptable delta
> from the last written value, then return the frequency corresponding
> to the last written ndiv value from freq_table. Otherwise, print a
> warning and return the reconstructed freq.
We should include the Fixes tag here ...
Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
>
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Otherwise ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
to resend with the Fixes tag or are you happy to add?
Thanks
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-09-16 17:11 ` [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning Sumit Gupta
@ 2020-09-17 8:38 ` Jon Hunter
2020-09-17 8:45 ` Jon Hunter
2020-09-24 8:56 ` Thierry Reding
2020-10-05 4:54 ` Viresh Kumar
2 siblings, 1 reply; 18+ messages in thread
From: Jon Hunter @ 2020-09-17 8:38 UTC (permalink / raw)
To: Sumit Gupta, viresh.kumar, rjw, thierry.reding, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel
Cc: ksitaraman, bbasu
On 16/09/2020 18:11, Sumit Gupta wrote:
> Warning coming during boot because the boot freq set by bootloader
> gets filtered out due to big freq steps while creating freq_table.
> Fixing this by setting closest ndiv value from freq_table.
> Warning:
> cpufreq: cpufreq_online: CPU0: Running at unlisted freq
> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>
> Also, added change in init to wait till current frequency becomes
> equal or near to the previously requested frequency. This is done
> because it takes some time to restore the previous frequency while
> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
Same here ...
Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
>
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Viresh, this is also needed for v5.9.
Thanks
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-17 8:36 ` Jon Hunter
@ 2020-09-17 8:44 ` Jon Hunter
2020-09-23 8:34 ` Jon Hunter
2020-10-05 4:34 ` Viresh Kumar
1 sibling, 1 reply; 18+ messages in thread
From: Jon Hunter @ 2020-09-17 8:44 UTC (permalink / raw)
To: Sumit Gupta, viresh.kumar, rjw, thierry.reding, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel, sudeep.holla
Cc: ksitaraman, bbasu
Adding Sudeep ...
On 17/09/2020 09:36, Jon Hunter wrote:
>
>
> On 16/09/2020 18:11, Sumit Gupta wrote:
>> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
>> and keeps changing slightly. This change returns a consistent value
>> from freq_table. If the reconstructed frequency has acceptable delta
>> from the last written value, then return the frequency corresponding
>> to the last written ndiv value from freq_table. Otherwise, print a
>> warning and return the reconstructed freq.
>
> We should include the Fixes tag here ...
>
> Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
>
>>
>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>
> Otherwise ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>
> Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
> to resend with the Fixes tag or are you happy to add?
Sudeep, Rafael, looks like Viresh is out of office until next month.
Please let me know if we can pick up both this patch and following patch
for v5.9.
Thanks!
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-09-17 8:38 ` Jon Hunter
@ 2020-09-17 8:45 ` Jon Hunter
0 siblings, 0 replies; 18+ messages in thread
From: Jon Hunter @ 2020-09-17 8:45 UTC (permalink / raw)
To: Sumit Gupta, viresh.kumar, rjw, thierry.reding, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel, sudeep.holla
Cc: ksitaraman, bbasu
On 17/09/2020 09:38, Jon Hunter wrote:
>
> On 16/09/2020 18:11, Sumit Gupta wrote:
>> Warning coming during boot because the boot freq set by bootloader
>> gets filtered out due to big freq steps while creating freq_table.
>> Fixing this by setting closest ndiv value from freq_table.
>> Warning:
>> cpufreq: cpufreq_online: CPU0: Running at unlisted freq
>> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>>
>> Also, added change in init to wait till current frequency becomes
>> equal or near to the previously requested frequency. This is done
>> because it takes some time to restore the previous frequency while
>> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
>
> Same here ...
>
> Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
>
>>
>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>
> Viresh, this is also needed for v5.9.
Adding Sudeep.
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-17 8:44 ` Jon Hunter
@ 2020-09-23 8:34 ` Jon Hunter
0 siblings, 0 replies; 18+ messages in thread
From: Jon Hunter @ 2020-09-23 8:34 UTC (permalink / raw)
To: Sumit Gupta, viresh.kumar, rjw, thierry.reding, linux-pm,
linux-tegra, linux-arm-kernel, linux-kernel, sudeep.holla
Cc: ksitaraman, bbasu
Hi Rafael, Sudeep,
On 17/09/2020 09:44, Jon Hunter wrote:
> Adding Sudeep ...
>
> On 17/09/2020 09:36, Jon Hunter wrote:
>>
>>
>> On 16/09/2020 18:11, Sumit Gupta wrote:
>>> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
>>> and keeps changing slightly. This change returns a consistent value
>>> from freq_table. If the reconstructed frequency has acceptable delta
>>> from the last written value, then return the frequency corresponding
>>> to the last written ndiv value from freq_table. Otherwise, print a
>>> warning and return the reconstructed freq.
>>
>> We should include the Fixes tag here ...
>>
>> Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
>>
>>>
>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>
>> Otherwise ...
>>
>> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
>> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>>
>> Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
>> to resend with the Fixes tag or are you happy to add?
>
>
> Sudeep, Rafael, looks like Viresh is out of office until next month.
> Please let me know if we can pick up both this patch and following patch
> for v5.9.
Any chance we can get these patches into v5.9?
Thanks!
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-16 17:11 ` [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq Sumit Gupta
2020-09-17 8:36 ` Jon Hunter
@ 2020-09-24 8:56 ` Thierry Reding
2020-10-05 4:46 ` Viresh Kumar
2 siblings, 0 replies; 18+ messages in thread
From: Thierry Reding @ 2020-09-24 8:56 UTC (permalink / raw)
To: Sumit Gupta
Cc: linux-pm, viresh.kumar, rjw, linux-kernel, jonathanh, ksitaraman,
bbasu, linux-tegra, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 711 bytes --]
On Wed, Sep 16, 2020 at 10:41:16PM +0530, Sumit Gupta wrote:
> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
> and keeps changing slightly. This change returns a consistent value
> from freq_table. If the reconstructed frequency has acceptable delta
> from the last written value, then return the frequency corresponding
> to the last written ndiv value from freq_table. Otherwise, print a
> warning and return the reconstructed freq.
>
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> ---
> drivers/cpufreq/tegra194-cpufreq.c | 66 ++++++++++++++++++++++++++++++++------
> 1 file changed, 57 insertions(+), 9 deletions(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-09-16 17:11 ` [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning Sumit Gupta
2020-09-17 8:38 ` Jon Hunter
@ 2020-09-24 8:56 ` Thierry Reding
2020-10-05 4:54 ` Viresh Kumar
2 siblings, 0 replies; 18+ messages in thread
From: Thierry Reding @ 2020-09-24 8:56 UTC (permalink / raw)
To: Sumit Gupta
Cc: linux-pm, viresh.kumar, rjw, linux-kernel, jonathanh, ksitaraman,
bbasu, linux-tegra, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 934 bytes --]
On Wed, Sep 16, 2020 at 10:41:17PM +0530, Sumit Gupta wrote:
> Warning coming during boot because the boot freq set by bootloader
> gets filtered out due to big freq steps while creating freq_table.
> Fixing this by setting closest ndiv value from freq_table.
> Warning:
> cpufreq: cpufreq_online: CPU0: Running at unlisted freq
> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>
> Also, added change in init to wait till current frequency becomes
> equal or near to the previously requested frequency. This is done
> because it takes some time to restore the previous frequency while
> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
>
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> ---
> drivers/cpufreq/tegra194-cpufreq.c | 118 ++++++++++++++++++++++++++++++++++---
> 1 file changed, 111 insertions(+), 7 deletions(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-17 8:36 ` Jon Hunter
2020-09-17 8:44 ` Jon Hunter
@ 2020-10-05 4:34 ` Viresh Kumar
2020-10-05 9:12 ` Jon Hunter
1 sibling, 1 reply; 18+ messages in thread
From: Viresh Kumar @ 2020-10-05 4:34 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-pm, rjw, linux-kernel, bbasu, ksitaraman, thierry.reding,
linux-tegra, Sumit Gupta, linux-arm-kernel
On 17-09-20, 09:36, Jon Hunter wrote:
> Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
> to resend with the Fixes tag or are you happy to add?
I understand that this fixes a patch which got merged recently, but I am not
sure if anything is broken badly right now, i.e. will make the hardware work
incorrectly.
Do we really need to get these in 5.9 ? As these are significant changes and may
cause more bugs. Won't getting them in 5.9-stable and 5.10-rc1 be enough ?
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-09-16 17:11 ` [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq Sumit Gupta
2020-09-17 8:36 ` Jon Hunter
2020-09-24 8:56 ` Thierry Reding
@ 2020-10-05 4:46 ` Viresh Kumar
2020-10-05 18:40 ` Sumit Gupta
2 siblings, 1 reply; 18+ messages in thread
From: Viresh Kumar @ 2020-10-05 4:46 UTC (permalink / raw)
To: Sumit Gupta
Cc: bbasu, linux-pm, rjw, linux-kernel, jonathanh, ksitaraman,
thierry.reding, linux-tegra, linux-arm-kernel
On 16-09-20, 22:41, Sumit Gupta wrote:
> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
> and keeps changing slightly. This change returns a consistent value
> from freq_table. If the reconstructed frequency has acceptable delta
> from the last written value, then return the frequency corresponding
> to the last written ndiv value from freq_table. Otherwise, print a
> warning and return the reconstructed freq.
>
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> ---
> drivers/cpufreq/tegra194-cpufreq.c | 66 ++++++++++++++++++++++++++++++++------
> 1 file changed, 57 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c
> index e1d931c..d5b608d 100644
> --- a/drivers/cpufreq/tegra194-cpufreq.c
> +++ b/drivers/cpufreq/tegra194-cpufreq.c
> @@ -180,9 +180,65 @@ static unsigned int tegra194_get_speed_common(u32 cpu, u32 delay)
> return (rate_mhz * KHZ); /* in KHz */
> }
>
> +static void get_cpu_ndiv(void *ndiv)
> +{
> + u64 ndiv_val;
> +
> + asm volatile("mrs %0, s3_0_c15_c0_4" : "=r" (ndiv_val) : );
> +
> + *(u64 *)ndiv = ndiv_val;
> +}
> +
> +static void set_cpu_ndiv(void *data)
> +{
> + struct cpufreq_frequency_table *tbl = data;
> + u64 ndiv_val = (u64)tbl->driver_data;
> +
> + asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
> +}
> +
> static unsigned int tegra194_get_speed(u32 cpu)
> {
> - return tegra194_get_speed_common(cpu, US_DELAY);
> + struct cpufreq_frequency_table *table, *pos;
> + struct cpufreq_policy policy;
> + unsigned int rate;
> + u64 ndiv;
> + int err;
> +
> + cpufreq_get_policy(&policy, cpu);
> + table = policy.freq_table;
Maybe getting freq-table from cluster specific data would be better/faster.
> +
> + /* reconstruct actual cpu freq using counters*/
> + rate = tegra194_get_speed_common(cpu, US_DELAY);
> +
> + /* get last written ndiv value*/
> + err = smp_call_function_single(cpu, get_cpu_ndiv, &ndiv, true);
> + if (err) {
> + pr_err("cpufreq: Failed to get ndiv for CPU%d, ret:%d\n",
> + cpu, err);
> + return rate;
> + }
> +
> + /* if the reconstructed frequency has acceptable delta from
Both have got the multi-line comments wrong. Format is wrong and every sentence
needs to start with a capital letter.
> + * the last written value, then return freq corresponding
> + * to the last written ndiv value from freq_table. This is
> + * done to return consistent value.
> + */
> + cpufreq_for_each_valid_entry(pos, table) {
> + if (pos->driver_data != ndiv)
> + continue;
> +
> + if (abs(pos->frequency - rate) > 115200) {
> + pr_warn("cpufreq: high delta (%d) on CPU%d\n",
> + abs(pos->frequency - rate), cpu);
> + pr_warn("cpufreq: cur:%u, set:%u, set ndiv:%llu\n",
> + rate, pos->frequency, ndiv);
Both of these can be merged in a single line I think. There is no need to print
delta as you already print both the frequencies.
> + } else {
> + rate = pos->frequency;
> + }
> + break;
> + }
> + return rate;
> }
>
> static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
> @@ -209,14 +265,6 @@ static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
> return 0;
> }
>
> -static void set_cpu_ndiv(void *data)
> -{
> - struct cpufreq_frequency_table *tbl = data;
> - u64 ndiv_val = (u64)tbl->driver_data;
> -
> - asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
> -}
> -
> static int tegra194_cpufreq_set_target(struct cpufreq_policy *policy,
> unsigned int index)
> {
> --
> 2.7.4
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-09-16 17:11 ` [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning Sumit Gupta
2020-09-17 8:38 ` Jon Hunter
2020-09-24 8:56 ` Thierry Reding
@ 2020-10-05 4:54 ` Viresh Kumar
2020-10-05 18:54 ` Sumit Gupta
2 siblings, 1 reply; 18+ messages in thread
From: Viresh Kumar @ 2020-10-05 4:54 UTC (permalink / raw)
To: Sumit Gupta
Cc: bbasu, linux-pm, rjw, linux-kernel, jonathanh, ksitaraman,
thierry.reding, linux-tegra, linux-arm-kernel
On 16-09-20, 22:41, Sumit Gupta wrote:
> Warning coming during boot because the boot freq set by bootloader
> gets filtered out due to big freq steps while creating freq_table.
> Fixing this by setting closest ndiv value from freq_table.
> Warning:
> cpufreq: cpufreq_online: CPU0: Running at unlisted freq
> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>
> Also, added change in init to wait till current frequency becomes
> equal or near to the previously requested frequency. This is done
> because it takes some time to restore the previous frequency while
> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
So you are trying to figure if the frequency is listed in freq-table or not,
otherwise setting the frequency to a value you think is appropriate. Right ?
This is what the cpufreq core already does when it printed these boot time
messages. Do we really need to add this much code in here ?
If you really don't want to see the warning, how about fixing it the way cpufreq
core does ? i.e. with this call:
ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-10-05 4:34 ` Viresh Kumar
@ 2020-10-05 9:12 ` Jon Hunter
0 siblings, 0 replies; 18+ messages in thread
From: Jon Hunter @ 2020-10-05 9:12 UTC (permalink / raw)
To: Viresh Kumar
Cc: linux-pm, rjw, linux-kernel, bbasu, ksitaraman, thierry.reding,
linux-tegra, Sumit Gupta, linux-arm-kernel
On 05/10/2020 05:34, Viresh Kumar wrote:
> On 17-09-20, 09:36, Jon Hunter wrote:
>> Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
>> to resend with the Fixes tag or are you happy to add?
>
> I understand that this fixes a patch which got merged recently, but I am not
> sure if anything is broken badly right now, i.e. will make the hardware work
> incorrectly.
>
> Do we really need to get these in 5.9 ? As these are significant changes and may
> cause more bugs. Won't getting them in 5.9-stable and 5.10-rc1 be enough ?
Yes we want these in v5.9 ideally but yes we could merge to 5.9-stable
once accepted into the mainline.
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq
2020-10-05 4:46 ` Viresh Kumar
@ 2020-10-05 18:40 ` Sumit Gupta
0 siblings, 0 replies; 18+ messages in thread
From: Sumit Gupta @ 2020-10-05 18:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: bbasu, linux-pm, rjw, linux-kernel, jonathanh, ksitaraman,
thierry.reding, linux-tegra, Sumit Gupta, linux-arm-kernel
>> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
>> and keeps changing slightly. This change returns a consistent value
>> from freq_table. If the reconstructed frequency has acceptable delta
>> from the last written value, then return the frequency corresponding
>> to the last written ndiv value from freq_table. Otherwise, print a
>> warning and return the reconstructed freq.
>>
>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>> ---
>> drivers/cpufreq/tegra194-cpufreq.c | 66 ++++++++++++++++++++++++++++++++------
>> 1 file changed, 57 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c
>> index e1d931c..d5b608d 100644
>> --- a/drivers/cpufreq/tegra194-cpufreq.c
>> +++ b/drivers/cpufreq/tegra194-cpufreq.c
>> @@ -180,9 +180,65 @@ static unsigned int tegra194_get_speed_common(u32 cpu, u32 delay)
>> return (rate_mhz * KHZ); /* in KHz */
>> }
>>
>> +static void get_cpu_ndiv(void *ndiv)
>> +{
>> + u64 ndiv_val;
>> +
>> + asm volatile("mrs %0, s3_0_c15_c0_4" : "=r" (ndiv_val) : );
>> +
>> + *(u64 *)ndiv = ndiv_val;
>> +}
>> +
>> +static void set_cpu_ndiv(void *data)
>> +{
>> + struct cpufreq_frequency_table *tbl = data;
>> + u64 ndiv_val = (u64)tbl->driver_data;
>> +
>> + asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
>> +}
>> +
>> static unsigned int tegra194_get_speed(u32 cpu)
>> {
>> - return tegra194_get_speed_common(cpu, US_DELAY);
>> + struct cpufreq_frequency_table *table, *pos;
>> + struct cpufreq_policy policy;
>> + unsigned int rate;
>> + u64 ndiv;
>> + int err;
>> +
>> + cpufreq_get_policy(&policy, cpu);
>> + table = policy.freq_table;
>
> Maybe getting freq-table from cluster specific data would be better/faster.
>
will do the change in next patch version.
>> +
>> + /* reconstruct actual cpu freq using counters*/
>> + rate = tegra194_get_speed_common(cpu, US_DELAY);
>> +
>> + /* get last written ndiv value*/
>> + err = smp_call_function_single(cpu, get_cpu_ndiv, &ndiv, true);
>> + if (err) {
>> + pr_err("cpufreq: Failed to get ndiv for CPU%d, ret:%d\n",
>> + cpu, err);
>> + return rate;
>> + }
>> +
>> + /* if the reconstructed frequency has acceptable delta from
>
> Both have got the multi-line comments wrong. Format is wrong and every sentence
> needs to start with a capital letter.
>
will correct.
>> + * the last written value, then return freq corresponding
>> + * to the last written ndiv value from freq_table. This is
>> + * done to return consistent value.
>> + */
>> + cpufreq_for_each_valid_entry(pos, table) {
>> + if (pos->driver_data != ndiv)
>> + continue;
>> +
>> + if (abs(pos->frequency - rate) > 115200) {
>> + pr_warn("cpufreq: high delta (%d) on CPU%d\n",
>> + abs(pos->frequency - rate), cpu);
>> + pr_warn("cpufreq: cur:%u, set:%u, set ndiv:%llu\n",
>> + rate, pos->frequency, ndiv);
>
> Both of these can be merged in a single line I think. There is no need to print
> delta as you already print both the frequencies.
>
Will do this also in next patch version.
>> + } else {
>> + rate = pos->frequency;
>> + }
>> + break;
>> + }
>> + return rate;
>> }
>>
>> static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
>> @@ -209,14 +265,6 @@ static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
>> return 0;
>> }
>>
>> -static void set_cpu_ndiv(void *data)
>> -{
>> - struct cpufreq_frequency_table *tbl = data;
>> - u64 ndiv_val = (u64)tbl->driver_data;
>> -
>> - asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
>> -}
>> -
>> static int tegra194_cpufreq_set_target(struct cpufreq_policy *policy,
>> unsigned int index)
>> {
>> --
>> 2.7.4
>
> --
> viresh
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-10-05 4:54 ` Viresh Kumar
@ 2020-10-05 18:54 ` Sumit Gupta
2020-10-06 5:38 ` Viresh Kumar
0 siblings, 1 reply; 18+ messages in thread
From: Sumit Gupta @ 2020-10-05 18:54 UTC (permalink / raw)
To: Viresh Kumar
Cc: bbasu, linux-pm, rjw, linux-kernel, jonathanh, ksitaraman,
thierry.reding, linux-tegra, Sumit Gupta, linux-arm-kernel
>> Warning coming during boot because the boot freq set by bootloader
>> gets filtered out due to big freq steps while creating freq_table.
>> Fixing this by setting closest ndiv value from freq_table.
>> Warning:
>> cpufreq: cpufreq_online: CPU0: Running at unlisted freq
>> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>>
>> Also, added change in init to wait till current frequency becomes
>> equal or near to the previously requested frequency. This is done
>> because it takes some time to restore the previous frequency while
>> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
>
> So you are trying to figure if the frequency is listed in freq-table or not,
> otherwise setting the frequency to a value you think is appropriate. Right ?
During boot, want to set the frequency from freq_table which is closest
to the one set by bootloader.
During resume from suspend-to-idle, want to restore the frequency which
was set on non-boot cores before they were hotplug powered off.
>
> This is what the cpufreq core already does when it printed these boot time
> messages. Do we really need to add this much code in here ?
We want to avoid the warning messages.
>
> If you really don't want to see the warning, how about fixing it the way cpufreq
> core does ? i.e. with this call:
>
> ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
>
The cpufreq core change will help in bootup case but not during the case
of resume.
In this change, reading the previously stored value and restoring it
will also fix the warning message during resume.
> --
> viresh
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-10-05 18:54 ` Sumit Gupta
@ 2020-10-06 5:38 ` Viresh Kumar
2020-10-08 11:11 ` Sumit Gupta
0 siblings, 1 reply; 18+ messages in thread
From: Viresh Kumar @ 2020-10-06 5:38 UTC (permalink / raw)
To: Sumit Gupta
Cc: bbasu, linux-pm, rjw, linux-kernel, jonathanh, ksitaraman,
thierry.reding, linux-tegra, linux-arm-kernel
On 06-10-20, 00:24, Sumit Gupta wrote:
>
> > > Warning coming during boot because the boot freq set by bootloader
> > > gets filtered out due to big freq steps while creating freq_table.
> > > Fixing this by setting closest ndiv value from freq_table.
> > > Warning:
> > > cpufreq: cpufreq_online: CPU0: Running at unlisted freq
> > > cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
> > >
> > > Also, added change in init to wait till current frequency becomes
> > > equal or near to the previously requested frequency. This is done
> > > because it takes some time to restore the previous frequency while
> > > turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
> >
> > So you are trying to figure if the frequency is listed in freq-table or not,
> > otherwise setting the frequency to a value you think is appropriate. Right ?
> During boot, want to set the frequency from freq_table which is closest to
> the one set by bootloader.
Right.
> During resume from suspend-to-idle, want to restore the frequency which was
> set on non-boot cores before they were hotplug powered off.
Why exactly do you want to do that ? Rather you should provide
online/offline hooks for the cpufreq driver and do light-weight
suspend/resume as is done by cpufreq-dt.c as well.
> >
> > This is what the cpufreq core already does when it printed these boot time
> > messages. Do we really need to add this much code in here ?
> We want to avoid the warning messages.
Hmm, okay.
> >
> > If you really don't want to see the warning, how about fixing it the way cpufreq
> > core does ? i.e. with this call:
> >
> > ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
> >
> The cpufreq core change will help in bootup case but not during the case of
> resume.
> In this change, reading the previously stored value and restoring it will
> also fix the warning message during resume.
You were getting the message during resume as well ? Why ? The
firmware is updating the frequency to a previous value ? If that is
so, you should just set the frequency again to some other value during
resume to fix it.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
2020-10-06 5:38 ` Viresh Kumar
@ 2020-10-08 11:11 ` Sumit Gupta
0 siblings, 0 replies; 18+ messages in thread
From: Sumit Gupta @ 2020-10-08 11:11 UTC (permalink / raw)
To: Viresh Kumar
Cc: bbasu, linux-pm, rjw, linux-kernel, jonathanh, ksitaraman,
thierry.reding, linux-tegra, Sumit Gupta, linux-arm-kernel
>>
>>>> Warning coming during boot because the boot freq set by bootloader
>>>> gets filtered out due to big freq steps while creating freq_table.
>>>> Fixing this by setting closest ndiv value from freq_table.
>>>> Warning:
>>>> cpufreq: cpufreq_online: CPU0: Running at unlisted freq
>>>> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>>>>
>>>> Also, added change in init to wait till current frequency becomes
>>>> equal or near to the previously requested frequency. This is done
>>>> because it takes some time to restore the previous frequency while
>>>> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
>>>
>>> So you are trying to figure if the frequency is listed in freq-table or not,
>>> otherwise setting the frequency to a value you think is appropriate. Right ?
>> During boot, want to set the frequency from freq_table which is closest to
>> the one set by bootloader.
>
> Right.
>
>> During resume from suspend-to-idle, want to restore the frequency which was
>> set on non-boot cores before they were hotplug powered off.
>
> Why exactly do you want to do that ? Rather you should provide
> online/offline hooks for the cpufreq driver and do light-weight
> suspend/resume as is done by cpufreq-dt.c as well.
>
Thank you for pointer. Added online hook to avoid warning during
hot-plug-on for the non-boot CPU's while exiting from Suspend-to-RAM. Will
send new version with the changes.
>>>
>>> This is what the cpufreq core already does when it printed these boot time
>>> messages. Do we really need to add this much code in here ?
>> We want to avoid the warning messages.
>
> Hmm, okay.
>
>>>
>>> If you really don't want to see the warning, how about fixing it the way cpufreq
>>> core does ? i.e. with this call:
>>>
>>> ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
>>>
>> The cpufreq core change will help in bootup case but not during the case of
>> resume.
>> In this change, reading the previously stored value and restoring it will
>> also fix the warning message during resume.
>
> You were getting the message during resume as well ? Why ? The
> firmware is updating the frequency to a previous value ? If that is
> so, you should just set the frequency again to some other value during
> resume to fix it.
Yes, it boots at a predefined frequency and then some time is taken to
restore the last frequency which software requested before entering
Suspend-to-RAM. We don't need to re-write the register again.
>
> --
> viresh
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-10-08 11:12 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-16 17:11 [Patch 0/2] Tegra194 cpufreq driver misc changes Sumit Gupta
2020-09-16 17:11 ` [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq Sumit Gupta
2020-09-17 8:36 ` Jon Hunter
2020-09-17 8:44 ` Jon Hunter
2020-09-23 8:34 ` Jon Hunter
2020-10-05 4:34 ` Viresh Kumar
2020-10-05 9:12 ` Jon Hunter
2020-09-24 8:56 ` Thierry Reding
2020-10-05 4:46 ` Viresh Kumar
2020-10-05 18:40 ` Sumit Gupta
2020-09-16 17:11 ` [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning Sumit Gupta
2020-09-17 8:38 ` Jon Hunter
2020-09-17 8:45 ` Jon Hunter
2020-09-24 8:56 ` Thierry Reding
2020-10-05 4:54 ` Viresh Kumar
2020-10-05 18:54 ` Sumit Gupta
2020-10-06 5:38 ` Viresh Kumar
2020-10-08 11:11 ` Sumit Gupta
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).