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

[Robin Murphy]

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 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.

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.