Re: [PATCH] AM35xx: Add clock support for new modules on AM35xx

[Ranjith Lohithakshan <ranjithl@ti.com>]

Hi Paul,

On Sat, 09-Jan-10 4:37 AM +0530, Paul Walmsley wrote:
> Hello Ranjith,
> 
> On Fri, 8 Jan 2010, Ranjith Lohithakshan wrote:
> 
>> These ACK bits are for the target IdleAck status. I will add a custom
>> find_companion code for AM35xx.
> 
> ...
> 
>> OK. I will extend the existing find_idlest to pass back what value needs
>> to be checked as you suggested. I will make this change as a separate patch.
> 
> Both of the above sound good.
> 
>> All the VBUSP (interface) clocks are derived from core_l3_clk and I am
>> making them as part of core_l3_clk domain. The rmii_ck/emac_fck and
>> vpfe_fck are sourced from external clock sources. (AM35XX TRM section
>> 4.7.7.12)
> 
> ...
> 
>> rmii_ck and vpfe_fck are from off-chip sources. These are fixed rate
>> clocks being fed to the chip. Do we need to associate a dummy or virtual
>> clock domain for these clocks or is it OK if we treat it similar to the
>> way we currently treat 32K timer clock (RATE_FIXED, clockops_null, no
>> clock domain and having no parent)?
> 
> I guess it will be fine to add these with no clockdomain until we add an 
> external clockdomain.  One last question - do you know if these external 
> clocks require the CORE powerdomain to be powered for them to be routed?  
> I believe this is the case for some of the external clocks that are routed 
> through the CM on OMAP3.

These external clocks are routed directly from IO to the respective
modules. They are not controlled by CM.

 - Ranjith