On Thu, Jan 10, 2013 at 18:50:55, Shawn Guo wrote: > 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. > I still think putting the OPP data in a single place is better. > > 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. > I don't know what the OMAP plans are but with DT + generic driver adoption I would expect most of it to go away. And adding the platform hook with the right DT data is just preparing things for the future with 2 potential users right now. If OPP data across Si rev starts looking very different all entries can be placed in a single place and the platform code enables what are relevant. Unless there's a Si rev specific blob a bunch of opp_add() calls ignoring what was passed defeats the purpose of moving the information out of the kernel. Regards, Vaibhav -- 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
