"Bedia, Vaibhav" <vaibhav.bedia@xxxxxx> writes: > On Tue, Dec 06, 2011 at 00:37:38, Hilman, Kevin wrote: > [...] >> > >> > We want to use the existing OMAP implementation of cpufreq (and DVFS) on >> > the devices which do not have VC/VP. >> > >> > The current OMAP cpufreq code under drivers/ invokes clk_set_rate(). >> > >> > We had a look at the future DVFS implementation for OMAP[1] and merged in >> > the relevant patches (hope this is close to what's planned). >> >> Unfortunately, that implementation is not what's planned, and in fact >> was rejected some time ago. > > That's really unfortunate :( > >> >> > After this change, cpufreq invokes omap_device_scale(). The DVFS code >> > makes use of the OPP layer and adds a request for voltage and frequency >> > change. However, the voltage change request expects the scaling to be done >> > in scaling functions defined in the voltage layer (vc->scale or vp->scale) >> > >> > On devices which do not have VC/VP, instead of just hacking the current >> > implementation to get the voltage scaling done, we thought of adding >> > a separate path. >> >> A much better path for SoCs without VC/VP is to simply modify the >> CPUfreq driver to use the regulator API to scale voltage before calling >> clk_set_rate() (if scaling up) and after scaling the frequency (if >> scaling down.) > > I assume this needs to be done using the OPP library? Yes, the mainline cpufreq driver (queued and merging for v3.3, see my for_3.3/omap-cpufreq branch) already uses the OPP library to determine frequencies. From there, it's a small step to get the voltage associated with the OPP and use the regulator framework to scale the voltage. >> >> In fact, that is the direction we're going for DVFS, even for VC/VP >> platforms. There will be a regulator driver which will call the >> voltagedomain/VC/VP calls to scale the voltage when needed, so from a >> DVFS perspective, you use the clock API to change frequency, and the >> regulator API to change voltages. > > Wouldn't this end up adding OMAP specific code into the various regulator > drivers? If TPS65910 gets used on a variant that has VC/VP, won't this > require making changes in the regulator drivers to being with? Yes. Tero is working on this now for the TWL PMICs, and the additional code is rather small. >> >> This should be a much simpler approach for you, and much easier to >> understand. > > Yes, making calls to the regulator and clock frameworks is much simpler > and desirable. Great, I'm glad you agree. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
