On 28-04-22, 19:16, Rex-BC Chen wrote: > Yes, the call stack will eventually go to __cpufreq_driver_target. > However, we can observe the mismatch between target_freq and policy-cur > with a tiny difference. > e.g. > [ 553.065356] cpufreq: target for CPU 0: 500000 kHz, relation 0, > requested 500000 kHz > [ 553.066366] cpufreq: target_freq/policy->cur: 500000/499999 kHz So you are trying to set the frequency to 500 MHz now, but policy->cur says it is 499 MHz. > We check the assignment of policy->cur could be either from > cpufreq_driver->get_intermediate or from cpufreq_driver->get. policy->cur is set only at two places, in your case: - CPUFREQ_POSTCHANGE - cpufreq_online() >From what I understand, it is possible that cpufreq_online() is setting your frequency to 499999 (once at boot), but as soon as a frequency change has happened after that, policy->cur should be set to 500 MHz and you should see this problem only once. >From CPUFREQ_POSTCHANGE notifier, we always set policy->cur from the table itself, which should be 500000 MHz. I wonder how you see policy->cur to be 499999 here. Does this happen only once ? Or repeatedly ? > But it is strange to have the frequency value like 499999 kHz. > Is the result of tiny frequency difference expected from your point of > view? Clock driver can give this value, that is fine. > > What do you mean by "voltage pulse" here? What actually happens which > > you want to avoid. > > > > When cpufreq is fixed to lowest opp, "voltage pulse" is a quick voltage > rising and falling phenomenon which can be observed if 'cpufreq_get' is > invoked. Do check if the call is reaching your driver's ->target_index(), it should be which it should not, ideally. > Thank you for sharing the correct information. > Is it possible to get frequency (API) a simple way, like get current > opp frequency? Lets dig/debug a bit further and fix this if a real problem exists. -- viresh
