| Message ID | 20250214074353.1169864-3-chun-jen.tseng@mediatek.com |
|---|---|
| State | New |
| Headers | show |
| Series | fixed mediatek-cpufreq has multi policy concurrency issue | expand |
Hi viresh, For CCI and ARMPLL in different driver, I need to change ARMPLL first then use cpufreq notify CCI driver. it can avoid CCI driver get wrong ARMPLL frequency and choose WRONG frequency. BRs, Mark Tseng On Wed, 2025-02-19 at 11:15 +0530, Viresh Kumar wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > On 14-02-25, 15:43, Mark Tseng wrote: > > Add CPUFREQ_ASYNC_NOTIFICATION flages for cpufreq policy because > > some of > > process will get CPU frequency by cpufreq sysfs node. It may get > > wrong > > frequency then call cpufreq_out_of_sync() to fixed frequency. > > That's not why CPUFREQ_ASYNC_NOTIFICATION is used. It is used only > for the cases > where the target()/target_index() callback defers the work to some > other entity > (like a workqueue) and it is not guaranteed that the frequency will > be changed > before these helpers return. > > I don't think your patch is required. > > -- > viresh
On 20-03-25, 08:34, Chun-Jen Tseng (曾俊仁) wrote: > For CCI and ARMPLL in different driver, I need to change ARMPLL first > then use cpufreq notify CCI driver. it can avoid CCI driver get wrong > ARMPLL frequency and choose WRONG frequency. That flag is only required if mtk_cpufreq_set_target() isn't able to complete the freq transition. Which isn't the case here. I don't think your patch is correct.
diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index 07d5958e106a..68fcb6fcbe48 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -209,12 +209,12 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, struct dev_pm_opp *opp; long freq_hz, pre_freq_hz; int vproc, pre_vproc, inter_vproc, target_vproc, ret; + struct cpufreq_freqs freqs; mutex_lock(&mtk_policy_lock); inter_vproc = info->intermediate_voltage; - - pre_freq_hz = clk_get_rate(cpu_clk); + pre_freq_hz = policy->cur * 1000; if (unlikely(info->pre_vproc <= 0)) pre_vproc = regulator_get_voltage(info->proc_reg); @@ -307,6 +307,10 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy, } info->current_freq = freq_hz; + freqs.old = policy->cur; + freqs.new = freq_table[index].frequency; + cpufreq_freq_transition_begin(policy, &freqs); + cpufreq_freq_transition_end(policy, &freqs, false); out: mutex_unlock(&mtk_policy_lock); @@ -629,6 +633,7 @@ static unsigned int mtk_cpufreq_get(unsigned int cpu) static struct cpufreq_driver mtk_cpufreq_driver = { .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_HAVE_GOVERNOR_PER_POLICY | + CPUFREQ_ASYNC_NOTIFICATION | CPUFREQ_IS_COOLING_DEV, .verify = cpufreq_generic_frequency_table_verify, .target_index = mtk_cpufreq_set_target,
Add CPUFREQ_ASYNC_NOTIFICATION flages for cpufreq policy because some of process will get CPU frequency by cpufreq sysfs node. It may get wrong frequency then call cpufreq_out_of_sync() to fixed frequency. Signed-off-by: Mark Tseng <chun-jen.tseng@mediatek.com> --- drivers/cpufreq/mediatek-cpufreq.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)