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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
