On 05/13/2014 10:49 PM, Mike Turquette wrote: > Quoting Sebastian Hesselbarth (2014-05-13 08:11:55) >> On 05/13/2014 02:20 PM, Mark Rutland wrote: >>> You've also failed to document the property. >>> >>> What are you trying to achieve here, and why do you think this is the >>> best way of achieving that? >> >> I cannot tell from the commit msgs, but consider clk-si5351 which is a >> driver for an external programmable clock with N PLLs and M outputs. Now >> connect a video clock consumer and an audio clock consumer to two >> different outputs and those to one PLL (as you want audio clock derived >> from video clock, typical HDMI scenario). >> >> Now, there should be a way to tell the generic driver which outputs are >> allowed to change the PLLs rate and which don't. Otherwise, the clock >> chip would be pretty useless as e.g. your audio clock consumer will >> overwrite the rate the video clock consumer has chosen. > > This is really a job for the "coordinated clock rate changes" that are > currently in development. These specify clock sub-tree snapshots of > parent and rate configurations that are predefined. These combinations > can be specified in DT. That helps a lot with clock configurations that > change per board, or for cases where many combinations of parents and > dividers can yield the same output rate, but only a subset of those were > validated by the silicon validation team or had proper timing closure so > we don't want to rely on the "walk up the tree" algorithm. Ah! Great to hear there is work on that already. Thanks for the heads up! Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
