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? > > 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? > > 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. Regards, Vaibhav -- 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
