[PATCH V3 4/7] cpufreq: add generic cpufreq driver

[Richard Zhao]

On Wed, Dec 21, 2011 at 02:33:36AM +0000, Mark Brown wrote:
> On Wed, Dec 21, 2011 at 10:24:53AM +0800, Richard Zhao wrote:
> > On Wed, Dec 21, 2011 at 01:32:21AM +0000, Mark Brown wrote:
> 
> > > 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"?
> 
> Drop is a synonym for lower in this context.
> 
> > cpu-volts = <
> > 	/* min  max */
> > 	1100000 1200000 /* 1G HZ */
> > 	1000000 1200000 /* 800M HZ */
> > 	900000  1200000 /* 600M HZ */
> > 	>;
> > The above sample dts could meet your point?
> 
> Yes.
> 
> > > 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
> > > this.
> 
> > 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.
> 
> The issue that was there for is that there are multiple runtime
> detectable variant clocking configurations which couldn't be switched
> between so the driver needs to select only the rates that can be reached
> from the current configuration.  I'd imagine that might be an issue
> elsewhere.
one case is that, cpu freq is 800M, clock may only reach 799M. I'd rather let
clock code to decide how to handle 800M request. That's why I said
the condition check is too strict.

Thanks
Richard
>