On Mon, 7 Oct 2013, Mike Turquette wrote: > Well it used to be that calling clk_set_rate(dpll, bypass_rate) would > put it in bypass, I don't know if that is still the case. But you are > right that having the implicit assumption that 'bypass rate' == 'DPLL in > bypass' is not safe since a bootloader could lock this PLL to the same > rate as it's bypass rate. > > I hope that the bypass rate stuff does not get swept away in the changes > since it is an interesting way to save a little power. Yeah, I don't think anyone's proposing to remove it, as far as I know. Am more concerned about any similar lurking problems in low-level clock code that use the current state of the clock hardware to determine a possible future rate. Am hoping that this particular issue is simply due to the state dependency between the CLKOUTX2 node and the PLL node. Considering this issue, in retrospect, it probably would have been better to merge the CLKOUTX2 node with the PLL. - 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
