A question about OMAP1 mcbsp clocks. From what I understand from the OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two clocks: 1. interface clock switchable between DSPPER_CK and DSPXOR_CK. 2. a function clock which could be DSPXOR_CK (mcbsp3), and CK_DPLL1OUT or MCBS1_CLKS (mcbsp1). However, the code in mach-omap1/mcbsp.c associates both mcbsp1 and 3 unconditionally with all of: DSP_CK, API_CK and DSPXOR_CK. As far as I can see, DSP_CK (for the DSP processor) and API_CK (for system dma) have nothing to do with mcbsp1,3. So, the question is why is it this way, and what would be the effect of correcting this so that both of these mcbsp units are associated with their proper interface and function clocks? On a related note, mcbsp2 has its own interface and function clocks, both tied to ARMPER_CK, which it doesn't even claim. Again - why not? And on that note, can someone explain to me the weird way idle stuff is handled? It seems that idle modes are only controlled in one situation: 1. a clock has CLOCK_NO_IDLE_PARENT set 2. the parent has CLOCK_IDLE_CONTROL set In other words, to invoke the idle state of a clock, it's _child_ needs to be manipulated - manipulating the clock itself, even if it has CLOCK_IDLE_CONTROL, has no effect on the idle states. Why is this? (There's also a bunch of clocks which have CLOCK_IDLE_CONTROL set but which don't have any children, making the idle state for those clocks effectively unreachable - bug?) -- 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
