On 11/25/2013 09:01 AM, Viresh Kumar wrote:
On 25 November 2013 22:08, Dirk Brandewie <dirk.brandewie@xxxxxxxxx> wrote:
IMHO this issue should be fixed in the scaling driver for the platform.
The scaling driver sets policy->cur and fills in the frequency table and has
Not anymore, policy->cur is set in the core for most of the drivers now.
Drivers just provide ->get() callbacks.
the ability to adjust the frequency of the CPU.
I believe this kind of decisions should stay with the core, drivers should
just provide the backend instead of intelligence..
This is a platform specific bug fix AFAICT and belongs in a platform
specific piece of code
Letting this leak up into the core
is wrong IMHO and just widens the window where the CPU will be running at
the wrong frequency set by the bootloader.
It doesn't stay there for long enough.. we get to this point in
cpufreq core just
after calling ->init(), and if the CPU is working without issues until
now, it will
stay stable for few more milliseconds.
And this is where the scaling driver should detect and fix the issue in ->init()
on platforms we know about today, What happens if platforms in the future are
more sensitive to the issue?
Shouldn't there be a check to see if the problem exists at all? Otherwise
the core is setting a policy for ALL platform even those where the issue
does
not exist.
That is taken care of by __cpufreq_driver_target(). It checks if we are
already running at requested frequency or not (after getting the next
higher frequency)... If current freq is present in table,
cpufreq_frequency_table_target() will return current frequency only for
policy->cur -1. And so we will not end up configuring hardware
unnecessarily.
The core should not be working around bootloader bugs IMHO. Silently
fixing it is evil IMHO at a minimum the core should complain LOUDLY
about this happening otherwise the bootloaders will have no incentive to
get their act together.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
