On 2022-03-09 08:37, elaine.zhang wrote:
hi,
在 2022/3/9 下午4:18, Sascha Hauer 写道:
Hi Elaine,
On Wed, Mar 09, 2022 at 09:41:39AM +0800, zhangqing@xxxxxxxxxxxxxx wrote:
hi，all：
Let me explain the clock dependency：
From the clock tree, pclk_vo0 and hclk_vo0 are completely
independent
clocks with different parent clocks and different clock
frequencies。
But the niu path is :
pclk_vo is dependent on hclk_vo, and the pclk_vo niu goes
through hclk_vo
niu.
Thanks, this is the information we are looking for. What is "NIU" btw?
I think this is even documented in the Reference Manual. With the right
pointer I just found:
The NIU (native interface unit)
You can see 2.8.6(NIU Clock gating reliance) in TRM.
A part of niu clocks have a dependence on another niu clock in order to
sharing the internal bus. When these clocks are in use, another niu
clock must be opened, and cannot be gated. These clocks and the special
clock on which they are relied are as following:
Clocks which have dependency The clock which can not be gated
-----------------------------------------------------------------
...
pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu
...
Yeah, the dependency is this.
It may be not very detailed, I don't have permission to publish detailed
NIU designs.
The clock tree and NIU bus paths are designed independently
So there are three solutions to this problem:
1. DTS adds a reference to Hclk while referencing Pclk.
2, The dependent clock is always on, such as HCLK_VO0, but this
is not
friendly for the system power.
3. Create a non-clock-tree reference. Clk-link, for example, we
have an
implementation in our internal branch, but Upstream is not sure
how to
push it.
I thought about something similar. That would help us here and on i.MX
we have a similar situation: We have one bit that switches multiple
clocks. That as well cannot be designed properly in the clock framework
currently, but could be modelled with a concept of linked clocks.
Doing this sounds like quite a bit of work and discussion though, I
don't really like having this as a dependency to mainline the VOP2
driver. I vote for 1. in that case, we could still ignore the hclk in
dts later when we have linked clocks.
OK so just to clarify, the issue is not just that the upstream clock
driver doesn't currently model the NIU clocks, but that even if it did,
it would still need to implement some new multi-parent clock type to
manage the internal dependency? That's fair enough - I do think that
improving the clock driver would be the best long-term goal, but for the
scope of this series, having an interim workaround does seem more
reasonable now that we understand *why* we need it.
Thanks,
Robin.
