[PATCH v2 2/2] ARM: imx: enable imx6q-cpufreq support

[Bedia, Vaibhav]

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