Re: [PATCH V2] cpufreq: tegra186: Fix initial frequency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Viresh,

On 25/08/2020 06:50, Viresh Kumar wrote:
> On 24-08-20, 15:59, Jon Hunter wrote:
>> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
>> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for
>> Tegra186 but as a consequence the following warnings are now seen on
>> boot ...
>>
>>  cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 0 KHz
>>  cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 2035200 KHz
>>  cpufreq: cpufreq_online: CPU1: Running at unlisted freq: 0 KHz
>>  cpufreq: cpufreq_online: CPU1: Unlisted initial frequency changed to: 2035200 KHz
>>  cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 0 KHz
>>  cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to: 2035200 KHz
>>  cpufreq: cpufreq_online: CPU3: Running at unlisted freq: 0 KHz
>>  cpufreq: cpufreq_online: CPU3: Unlisted initial frequency changed to: 2035200 KHz
>>  cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 0 KHz
>>  cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to: 2035200 KHz
>>  cpufreq: cpufreq_online: CPU5: Running at unlisted freq: 0 KHz
>>  cpufreq: cpufreq_online: CPU5: Unlisted initial frequency changed to: 2035200 KHz
>>
>> Fix this by adding a 'get' callback for the Tegra186 CPUFREQ driver to
>> retrieve the current operating frequency for a given CPU. The 'get'
>> callback uses the current 'ndiv' value that is programmed to determine
>> that current operating frequency.
>>
>> Signed-off-by: Jon Hunter <jonathanh@xxxxxxxxxx>
>> ---
>> Changes since V1:
>> - Moved code into a 'get' callback
>>
>>  drivers/cpufreq/tegra186-cpufreq.c | 30 ++++++++++++++++++++++++++++++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c
>> index 01e1f58ba422..0d0fcff60765 100644
>> --- a/drivers/cpufreq/tegra186-cpufreq.c
>> +++ b/drivers/cpufreq/tegra186-cpufreq.c
>> @@ -14,6 +14,7 @@
>>  
>>  #define EDVD_CORE_VOLT_FREQ(core)		(0x20 + (core) * 0x4)
>>  #define EDVD_CORE_VOLT_FREQ_F_SHIFT		0
>> +#define EDVD_CORE_VOLT_FREQ_F_MASK		0xffff
>>  #define EDVD_CORE_VOLT_FREQ_V_SHIFT		16
>>  
>>  struct tegra186_cpufreq_cluster_info {
>> @@ -91,10 +92,39 @@ static int tegra186_cpufreq_set_target(struct cpufreq_policy *policy,
>>  	return 0;
>>  }
>>  
>> +static unsigned int tegra186_cpufreq_get(unsigned int cpu)
>> +{
>> +	struct cpufreq_frequency_table *tbl;
>> +	struct cpufreq_policy *policy;
>> +	void __iomem *edvd_reg;
>> +	unsigned int i, freq = 0;
>> +	u32 ndiv;
>> +
>> +	policy = cpufreq_cpu_get(cpu);
>> +	if (!policy)
>> +		return -EINVAL;
> 
> This should be return 0;
> 
> Applied with that change. Thanks.


If not too late, would you mind dropping this patch for v5.10?

The patch was working for me locally, but when testing on more boards, I
actually found this broke CPUFREQ support on some Tegra186 boards. The
reason is that the boot frequency may not be in the frequency table on
all boards. The boot frequency is constant across all boards, but the
frequency table can vary slightly with device. Therefore, for some
boards, such as mine, the boot frequency is found the in frequency table
but this is not always the case.

Now that you have made the warning an info print, this change is not
really needed and the simplest thing to do is dropped this completely.
Sorry about that.

Jon

-- 
nvpublic



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux