[PATCH v7 10/24] drm/rockchip: dw_hdmi: Add support for hclk

[elaine.zhang]

hi,


在 2022/3/9 下午4:18, Sascha Hauer 写道:
> Hi Elaine,
>
> On Wed, Mar 09, 2022 at 09:41:39AM +0800, zhangqing at rock-chips.com 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.
>
> Sascha
>