On 19 November 2013 19:46, Nishanth Menon <nm@xxxxxx> wrote:
> Consider something like userspace governor selection -> the device at
> boot will probably remain in an unknown/"invalid" configuration till
> the very first transition attempt. I am less worried about the stats
> than not following what the hardware description is (as stated by
> device tree/other forms).
>
> I staunchly disagree that at a point of mismatch detection, we just
> refuse to load up cpufreq governor -even though we know from device
> tree/other alternative entries what the hardware behavior is supposed
> to be. To refuse to loadup to a known configuration is considering the
> "valid configuration" data provided to the driver is wrong - an
> equivalent(considering the i2c example) is that if i2c driver sees bus
> configured for 3.4MHz and was asked to use 100KHz, it just refuses to
> load up!
CPU looks to be a bit different in that aspect as compared to I2C. We
aren't really sure if I2C will work at the existing freq but we are 100%
sure that current freq of CPU is valid enough, otherwise we wouldn't
have reached to this point.. :)
> The above two are fair comments -> but that implies that policy->cur
> population should no longer be the responsibility of cpufreq drivers
> and be the responsibility of cpufreq core. are we stating we want to
> move that to cpufreq core?
I am sure you want to have a look at this:
commit da60ce9f2faca87013fd3cab1c3bed5183608c3d
Author: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
Date: Thu Oct 3 20:28:30 2013 +0530
cpufreq: call cpufreq_driver->get() after calling ->init()
Almost all drivers set policy->cur with current CPU frequency in
their ->init()
part. This can be done for all of them at core level and so they
wouldn't need
to do it.
This patch adds supporting code in cpufreq core for calling get()
after we have
called init() for a policy.
Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
---
drivers/cpufreq/cpufreq.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--
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
