[PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Paul Walmsley]

On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote:

> On Thu, Apr 26, 2012 at 11:54:51, Paul Walmsley wrote:
> > 
> > while working on clock33xx_data.c, it became clear that we would not be 
> > able to remove the MODULEMODE leaf clocks for several IP blocks that share 
> > driver code with other DaVinci chips.  This is because:
> > 
> > 1. the drivers for these IP blocks only use the clock framework, rather 
> > than runtime PM;
> > 
> > and 
> > 
> > 2. the clk_get() calls in those drivers do not specify a con_id 
> > parameter, which could cause problems with the clkdev clk_find()'s fuzzy 
> > matching algorithm.
> > 
> > So perhaps your group can work on converting the drivers to use runtime 
> > PM?  Discussing this with Kevin, it sounds like DaVinci doesn't have 
> > runtime PM hooks implemented, but you can probably use OMAP1 as an example 
> > of how to do it.
> > 
> > And then if clk_get() is still needed in the drivers, a specific con_id 
> > should be supplied, such as "fck", which can also be supplied by the OMAP 
> > codebase.
> 
> Honestly, I don't want to block AM33xx stuff getting into mainline due to 
> missing feature in Davinci.
> 
> Also, since AM33xx is not fully supported in the mainline (from peripheral 
> perspective), it really should not break anything as of now.
> 
> I am expecting, AM33xx core patches will get in by v3.5 and then while 
> adding peripheral support we will take Davinci migration activity, and can
> make sure that nothing breaks (for all Davinci, OMAP and AM33xx).

To be clear, I am not suggesting that the AM33xx stuff should be blocked 
by these changes.  I am however suggesting that it be added to the to-do 
list, so we can remove most or all of the remaining MODULEMODE clocks from 
the AM33xx clock tree.  Sounds like you are planning to work on that at 
some point, which is good.


- Paul