研究Common Clock Framework并怀疑与muxed时钟有关。
如果我们想设置muxed时钟的特定速率，并且时钟的当前父节点无法设置所需的速率（父节点具有较低的速率）。
然后，是否有任何功能或机制自动切换时钟的父节点（从其父列表）并设置所需的速率？
一种可能的解决方案，我们可以手动调用set_parent()然后调用set_rate()，这可以设置愿望率。但是如果我们只是调用set_rate()并且它会自动切换时钟的父节点并设置所需的速率会怎么样。
答案 0 :(得分：2)
某些时钟可能会使用PLL 向上扩展计时器。因此，拥有较低时钟的父母并不意味着自动尝试增加父时钟是最好的解决方案。 Common clock framework （ CCF ）旨在允许多个驱动程序/子系统访问共享资源。 CCF 并不试图变得聪明，因为不同时钟树的行为方式很难一般地知道。
一种可能的解决方案，我们可以手动调用
set_parent()然后调用set_rate()，这可以设置愿望率。
我认为您的意思是致电get_parent()，然后使用set_rate？有些时候，调用set_parent()并不容易，因为它可能已修复。您需要阅读SOC文档。在某些情况下，有多个输入时钟可用。即，真正的时钟层次结构不是树而是DAG，尽管活动层次结构是树状的。
但是，如果我们只是调用
set_rate()并自动切换时钟的父节点并设置所需的速率，该怎么办。
这可能对您正在查看但不是一般的SOC时钟有意义。可能有几十个时钟依赖于父级，并且可能重新评估 grand-parents 等等。由于音频驱动程序需要重新评估系统时钟，因此可能不是最佳选择。时钟是几个HZ出来的？
可以编写时钟驱动程序，以便在对不起作用的子项发出请求时对其进行重新评级。但是，这是时钟驱动程序的一部分，而不是 CCF 。
例如，SOC可能具有带三个输入源的音频时钟，
选项1是具有最高功耗的最佳音质。选项2是通用的，但可能与声速不匹配，导致次优的DAC /波/声音产生。选项三可能适用于某种USB声音从属设备，但如果您不使用USB，则功耗可能会很高。
在上面的情况中，set_parent()可能是一种获得所需速率的方法，如果SOC时钟驱动程序支持它。
CCF 中没有情报;如果有一些灵活性，它在时钟驱动程序中，但这取决于时钟硬件。程序员需要阅读SOC文档并确定配置时钟树的最佳方法。您可能还应该检查SOC和Linux版本的时钟驱动程序，以查看它支持的内容。您不能一般地更改驱动程序中父项的时钟速率，因为其他设备可能依赖于它们。如果您需要为SOC系列中的特定SOC提供此功能，则需要通过检查设备树来查看驱动程序正在运行的SOC的特殊情况。在这种情况下，您可以将get_parent()和set_rate()用于特定的SOC。