On 08/07/2013 12:06 PM, Viresh Kumar wrote: > On 7 August 2013 23:12, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >> On 08/07/2013 08:46 AM, Viresh Kumar wrote: >>> cpufreq-cpu0 driver needs OPPs to be present in DT which can be probed by it to >>> get frequency table. This patch adds OPPs and clock-latency to tegra cpu0 node >>> for multiple SoCs. >>> >>> Voltage levels aren't used until now for tegra and so a flat value which would >>> eventually be ignored is used to represent voltage. >> >> This patch is problematic w.r.t. DT being an ABI. > > :( > >> We can certainly add new optional properties to a DT binding that enable >> new features. However, a new version of a binding can't require new >> properties to exist that didn't before, since that means that old DTs >> won't work with new kernels that require the new properties. > > To be honest I didn't get it completely. You meant operating-points > wasn't present before? Its here: > > Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt > Documentation/devicetree/bindings/power/opp.txt > > Or you meant, Tegra never required voltage levels and we are getting > them in here. The current Tegra *.dts files do not contain this property. The current Tegra *.dts files must continue to work without modification in future kernels. >> As such, I believe we do need some Tegra-specific piece of code that >> defines these OPP tables in the kernel, so that the operating-points >> property is not needed. > > Generic cpufreq driver depends on OPP library and so somebody has > to provide them. Now you can do it by calling opp_add() for each OPP > you have or otherwise. Sure. That's what the Tegra-specific cpufreq driver should do. It should be the top-level cpufreq driver. If parts of the code can be implemented by library functions or a core parameterizable driver, then presumably the Tegra driver would simply exist to provide those parameters and/or callback functions to the generic driver. > Btw, you must have some specific voltage level for each freq, we can > get them here.. Yes, I'm sure we do, but I have no idea what they are:-( It may even be board-specific or SoC-SKU-specific. I think we should defer this aspect for now. -- 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
