[PATCH V3 4/7] cpufreq: add generic cpufreq driver
richard.zhao at freescale.com
Tue Dec 20 21:24:53 EST 2011
On Wed, Dec 21, 2011 at 01:32:21AM +0000, Mark Brown wrote:
> On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote:
> > On Tue, Dec 20, 2011 at 11:48:45PM +0000, Mark Brown wrote:
> > > Note also that not all hardware specifies things in terms of a fixed set
> > > of operating points, sometimes only the minimum voltage specification is
> > > varied with frequency or sometimes you see maximum and minimum stepping
> > > independently.
> > cpus that don't use freq table is out of scope of this driver.
> That's not the point - the point is that you may do something like
> specify a defined set of frequencies and just drop the minimum supported
> voltage without altering the maximum supported voltage as the frequency
> gets lower.
What do you mean by "drop"?
cpu-volts = <
/* min max */
1100000 1200000 /* 1G HZ */
1000000 1200000 /* 800M HZ */
900000 1200000 /* 600M HZ */
The above sample dts could meet your point?
> > > Further note that if all hardware really does have as tight a set of
> > > requirements as you suggest then the regulator support in the driver
> > > needs to be non-optional otherwise a board without software regulator
> > > control might drop the frequency without also dropping the voltage.
> > It's ok to only adjuct freq without changes voltage. You can find many
> > arm soc cpufreq drivers don't change voltage.
> > If dts specify voltage but don't have such regulator. I'll assume it
> > always runs on the initial volatage (highest for most cases).
> My point exactly; such devices are examples of the policy outlined above
> where only the minimum voltage changes with frequency and the maximum
> voltage is constant. The cpufreq driver would lower the supported
> voltage when possible but wouldn't actually care if the voltage changes.
accepted seting voltage range. I guess the above sample dts code meet your
> > > > > - Frequencies that can't be supported due to limitations of the
> > > > > available supplies shouldn't be exposed to users.
> > > > As I said, only proved operation points are allowed.
> > > This statement appears to be unrelated to the comment you're replying
> > > to.
> > I meant the exact voltage can always successfull set. Anyway, I'll add
> This is just not the case. Regulators don't offer a continuous range of
> voltages, they offer steps of varying sizes which may miss setting some
> voltages, and board designers may choose not to support some of the
> voltage range.
> > regulator_set_voltage return value checking.
> While this is important the driver should also be enumerating the
> supported voltages at probe time and eliminating unsupportable settings
> so that governors aren't constantly trying to set things that can never
> be supported. The s3c64xx cpufreq driver provides an implementation of
I'll use regulator_is_supported_voltage pre-check the cpu-volts.
For clock, conditions ((clk_round_rate(cpu-freq)/1000) * 1000 == cpu-freq)
seems too strict. Because cpu clock is SoC dependent, I'll not add the check.
> > Maybe I can remove it. But I'd probably add freq table dump. It's more important.
> > Agree?
> That seems like something the core should be doing if
hmm, cpu table dumps it with pr_debug.
More information about the linux-arm-kernel