[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c0daaa5-4aec-925d-c1e3-0f15fb93cc20@nvidia.com>
Date: Tue, 6 Oct 2020 00:24:01 +0530
From: Sumit Gupta <sumitg@...dia.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
CC: <rjw@...ysocki.net>, <thierry.reding@...il.com>,
<jonathanh@...dia.com>, <linux-pm@...r.kernel.org>,
<linux-tegra@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <ksitaraman@...dia.com>,
<bbasu@...dia.com>, Sumit Gupta <sumitg@...dia.com>
Subject: Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
>> 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
>
Powered by blists - more mailing lists