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. - Paul -- 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
