On Thu, Jan 10, 2013 at 01:02:30PM +0000, Bedia, Vaibhav wrote: > In the current approach the OPP data is split across DT and kernel code. If you take the > other approach all OPP entries can reside in DT and for someone just looking at that file > there's no confusion about what the kernel could potentially support. Whether a particular > an OPP should be supported is best decided at runtime. > Listing the OPP that some Si rev can not support in DT is also a confusion to people who is just looking at DTS. To me, the approach is not really doing anything better on this aspect. > Also, IMHO letting platforms invoke opp_add() is open to abuse and platforms should be > restricted to invoking opp_enable/disable to indicate what's possible on a particular Si rev. > I do not see anything wrong with platform adding the OPP it can support. Isn't omap_init_opp_table() being called by platform code? I do not see omap-cpufreq driver is calling a platform hook to do that. Sorry, I'm not really a fan of platform hook, and I have spent past couple years to minimize the use of it when converting IMX family to device tree. Shawn -- 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
