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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.
--
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


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux