[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd856233-06bb-4a5a-ba12-2996c89cb492@sifive.com>
Date: Fri, 12 Jan 2024 13:35:36 -0600
From: Samuel Holland <samuel.holland@...ive.com>
To: Conor Dooley <conor@...nel.org>, Chen Wang <unicorn_wang@...look.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Chen Wang <unicornxw@...il.com>, aou@...s.berkeley.edu, chao.wei@...hgo.com,
krzysztof.kozlowski+dt@...aro.org, mturquette@...libre.com,
palmer@...belt.com, paul.walmsley@...ive.com, richardcochran@...il.com,
robh+dt@...nel.org, sboyd@...nel.org, devicetree@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, haijiao.liu@...hgo.com,
xiaoguang.xing@...hgo.com, guoren@...nel.org, jszhang@...nel.org,
inochiama@...look.com, Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH v7 2/4] dt-bindings: clock: sophgo: support SG2042
Hi Conor, Chen,
On 2024-01-11 10:58 AM, Conor Dooley wrote:
> On Thu, Jan 11, 2024 at 04:00:04PM +0800, Chen Wang wrote:
>> With this change, we describe the plls defined in system control as pllclk,
>> as a child node of system controller. clkgen will use pllclk as "input"
>> because pll clocks are parent of div clocks .
>>
>> But there is another remaining question about the gate clock. For those gate
>> clocks controlled by CLOCK, no problem we will provide then in clkgen, butÂ
>> for those gate clocks controlled by registers in SYS_CTRL, they are child
>> gate of the "clk_gate_rp_cpu_normal", which is a gate clock provided by
>> clkgen. If I extracted those SYS_CTRL gate clocks and define them in system
>> controller dts node, I may have to use "clk_gate_rp_cpu_normal" as their
>> input, it looks a bit wierd becasue there are cases where each other serves
>> as input. I try to draft below DTS to explan what I meant. I'm not sure if
>> it can work and I'd love to hear your guidance.
>
> I'm not sure how this sort of circular relationship works for probing
> works either. Stephen etc would know more than me here.
It generally works fine. The common clock framework can handle the child clock
being registered before its parent, even when using a DT (fw_name) reference.
See for example clk_core_fill_parent_index() and
clk_core_reparent_orphans_nolock() in drivers/clk/clk.c
Regards,
Samuel
Powered by blists - more mailing lists