diff mbox series

[v3,3/4] riscv: dts: sophgo: add clock generator for Sophgo CV1800 series SoC

Message ID IA1PR20MB495373158F3B690EF3BF2901BB8BA@IA1PR20MB4953.namprd20.prod.outlook.com
State New
Headers
Series riscv: sophgo: add clock support for Sophgo CV1800 SoCs |

Commit Message

Inochi Amaoto Dec. 7, 2023, 8:37 a.m. UTC 
  Add clock generator node for CV1800B and CV1812H.

Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Link: https://github.com/milkv-duo/duo-files/blob/main/hardware/CV1800B/CV1800B-CV1801B-Preliminary-Datasheet-full-en.pdf
---
 arch/riscv/boot/dts/sophgo/cv1800b.dtsi | 4 ++++
 arch/riscv/boot/dts/sophgo/cv1812h.dtsi | 4 ++++
 arch/riscv/boot/dts/sophgo/cv18xx.dtsi  | 6 ++++++
 3 files changed, 14 insertions(+)

--
2.43.0

Comments

Krzysztof Kozlowski Dec. 7, 2023, 9:19 a.m. UTC | #1 
On 07/12/2023 09:37, Inochi Amaoto wrote:
> Add clock generator node for CV1800B and CV1812H.
> 
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> Link: https://github.com/milkv-duo/duo-files/blob/main/hardware/CV1800B/CV1800B-CV1801B-Preliminary-Datasheet-full-en.pdf
> ---
>  arch/riscv/boot/dts/sophgo/cv1800b.dtsi | 4 ++++
>  arch/riscv/boot/dts/sophgo/cv1812h.dtsi | 4 ++++
>  arch/riscv/boot/dts/sophgo/cv18xx.dtsi  | 6 ++++++
>  3 files changed, 14 insertions(+)
> 
> diff --git a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
> index 165e9e320a8c..baf641829e72 100644
> --- a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
> @@ -16,3 +16,7 @@ &plic {
>  &clint {
>  	compatible = "sophgo,cv1800b-clint", "thead,c900-clint";
>  };
> +
> +&clk {
> +	compatible = "sophgo,cv1800-clk";
> +};
> diff --git a/arch/riscv/boot/dts/sophgo/cv1812h.dtsi b/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
> index 9a375935b00c..83243c918204 100644
> --- a/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
> @@ -21,3 +21,7 @@ &plic {
>  &clint {
>  	compatible = "sophgo,cv1812h-clint", "thead,c900-clint";
>  };
> +
> +&clk {
> +	compatible = "sophgo,cv1810-clk";
> +};
> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> index 2d6f4a4b1e58..6ea1b2784db9 100644
> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> @@ -53,6 +53,12 @@ soc {
>  		dma-noncoherent;
>  		ranges;
> 
> +		clk: clock-controller@3002000 {
> +			reg = <0x03002000 0x1000>;
> +			clocks = <&osc>;
> +			#clock-cells = <1>;

I don't find such layout readable and maintainable. I did some parts
like this long, long time ago for one of my SoCs (Exynos54xx), but I
find it over time unmaintainable approach. I strongly suggest to have
compatible and other properties in one place, so cv1800 and cv1812, even
if it duplicates the code.

Best regards,
Krzysztof
Inochi Amaoto Dec. 7, 2023, 9:42 a.m. UTC | #2 
>
>On 07/12/2023 09:37, Inochi Amaoto wrote:
>> Add clock generator node for CV1800B and CV1812H.
>>
>> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
>> Link: https://github.com/milkv-duo/duo-files/blob/main/hardware/CV1800B/CV1800B-CV1801B-Preliminary-Datasheet-full-en.pdf
>> ---
>>  arch/riscv/boot/dts/sophgo/cv1800b.dtsi | 4 ++++
>>  arch/riscv/boot/dts/sophgo/cv1812h.dtsi | 4 ++++
>>  arch/riscv/boot/dts/sophgo/cv18xx.dtsi  | 6 ++++++
>>  3 files changed, 14 insertions(+)
>>
>> diff --git a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
>> index 165e9e320a8c..baf641829e72 100644
>> --- a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
>> +++ b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
>> @@ -16,3 +16,7 @@ &plic {
>>  &clint {
>>  	compatible = "sophgo,cv1800b-clint", "thead,c900-clint";
>>  };
>> +
>> +&clk {
>> +	compatible = "sophgo,cv1800-clk";
>> +};
>> diff --git a/arch/riscv/boot/dts/sophgo/cv1812h.dtsi b/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
>> index 9a375935b00c..83243c918204 100644
>> --- a/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
>> +++ b/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
>> @@ -21,3 +21,7 @@ &plic {
>>  &clint {
>>  	compatible = "sophgo,cv1812h-clint", "thead,c900-clint";
>>  };
>> +
>> +&clk {
>> +	compatible = "sophgo,cv1810-clk";
>> +};
>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>> index 2d6f4a4b1e58..6ea1b2784db9 100644
>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>> @@ -53,6 +53,12 @@ soc {
>>  		dma-noncoherent;
>>  		ranges;
>>
>> +		clk: clock-controller@3002000 {
>> +			reg = <0x03002000 0x1000>;
>> +			clocks = <&osc>;
>> +			#clock-cells = <1>;
>
>I don't find such layout readable and maintainable. I did some parts
>like this long, long time ago for one of my SoCs (Exynos54xx), but I
>find it over time unmaintainable approach. I strongly suggest to have
>compatible and other properties in one place, so cv1800 and cv1812, even
>if it duplicates the code.
>

Hi Krzysztof:

Thanks for your advice, but I have a question about this: when I should
use the DT override? The memory mapping of the CV1800 and CV1810 are
almost the same (the CV1810 have more peripheral and the future SG200X
have the same layout). IIRC, this is why conor suggested using DT override
to make modification easier. But duplicating node seems to break thiS, so
I's pretty confused.

Thanks,
Inochi

>Best regards,
>Krzysztof
>
>
Krzysztof Kozlowski Dec. 7, 2023, 12:52 p.m. UTC | #3 
On 07/12/2023 10:42, Inochi Amaoto wrote:
>>> +&clk {
>>> +	compatible = "sophgo,cv1810-clk";
>>> +};
>>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>> index 2d6f4a4b1e58..6ea1b2784db9 100644
>>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>> @@ -53,6 +53,12 @@ soc {
>>>  		dma-noncoherent;
>>>  		ranges;
>>>
>>> +		clk: clock-controller@3002000 {
>>> +			reg = <0x03002000 0x1000>;
>>> +			clocks = <&osc>;
>>> +			#clock-cells = <1>;
>>
>> I don't find such layout readable and maintainable. I did some parts
>> like this long, long time ago for one of my SoCs (Exynos54xx), but I
>> find it over time unmaintainable approach. I strongly suggest to have
>> compatible and other properties in one place, so cv1800 and cv1812, even
>> if it duplicates the code.
>>
> 
> Hi Krzysztof:
> 
> Thanks for your advice, but I have a question about this: when I should
> use the DT override? The memory mapping of the CV1800 and CV1810 are
> almost the same (the CV1810 have more peripheral and the future SG200X
> have the same layout). IIRC, this is why conor suggested using DT override
> to make modification easier. But duplicating node seems to break thiS, so
> I's pretty confused.

Go with whatever your subarchitecture and architecture maintainers
prefer, I just shared my opinion that I find such code difficult to read
and maintain.

Extending node with supplies, pinctrl or even clocks would be readable.
But the compatible: no. The same applies when you need to delete
property or subnode: not readable/maintainable IMHO.

Best regards,
Krzysztof
Conor Dooley Dec. 7, 2023, 5:31 p.m. UTC | #4 
On Thu, Dec 07, 2023 at 01:52:16PM +0100, Krzysztof Kozlowski wrote:
> On 07/12/2023 10:42, Inochi Amaoto wrote:
> >>> +&clk {
> >>> +	compatible = "sophgo,cv1810-clk";
> >>> +};
> >>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> >>> index 2d6f4a4b1e58..6ea1b2784db9 100644
> >>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> >>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> >>> @@ -53,6 +53,12 @@ soc {
> >>>  		dma-noncoherent;
> >>>  		ranges;
> >>>
> >>> +		clk: clock-controller@3002000 {
> >>> +			reg = <0x03002000 0x1000>;
> >>> +			clocks = <&osc>;
> >>> +			#clock-cells = <1>;
> >>
> >> I don't find such layout readable and maintainable. I did some parts
> >> like this long, long time ago for one of my SoCs (Exynos54xx), but I
> >> find it over time unmaintainable approach. I strongly suggest to have
> >> compatible and other properties in one place, so cv1800 and cv1812, even
> >> if it duplicates the code.
> >>
> > 
> > Hi Krzysztof:
> > 
> > Thanks for your advice, but I have a question about this: when I should
> > use the DT override? The memory mapping of the CV1800 and CV1810 are
> > almost the same (the CV1810 have more peripheral and the future SG200X
> > have the same layout). IIRC, this is why conor suggested using DT override
> > to make modification easier. But duplicating node seems to break thiS, so
> > I's pretty confused.
> 
> Go with whatever your subarchitecture and architecture maintainers
> prefer, I just shared my opinion that I find such code difficult to read
> and maintain.
> 
> Extending node with supplies, pinctrl or even clocks would be readable.
> But the compatible: no. The same applies when you need to delete
> property or subnode: not readable/maintainable IMHO.

There are apparently 3 or 4 of these SoCs that are basically identical,
which is why the approach was taken. I do agree that it looks somewhat
messy because I was looking for device-specific compatibles for these
SoCs.
Inochi Amaoto Dec. 8, 2023, 1:13 a.m. UTC | #5 
>On Thu, Dec 07, 2023 at 01:52:16PM +0100, Krzysztof Kozlowski wrote:
>> On 07/12/2023 10:42, Inochi Amaoto wrote:
>>>>> +&clk {
>>>>> +	compatible = "sophgo,cv1810-clk";
>>>>> +};
>>>>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>> index 2d6f4a4b1e58..6ea1b2784db9 100644
>>>>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>> @@ -53,6 +53,12 @@ soc {
>>>>>  		dma-noncoherent;
>>>>>  		ranges;
>>>>>
>>>>> +		clk: clock-controller@3002000 {
>>>>> +			reg = <0x03002000 0x1000>;
>>>>> +			clocks = <&osc>;
>>>>> +			#clock-cells = <1>;
>>>>
>>>> I don't find such layout readable and maintainable. I did some parts
>>>> like this long, long time ago for one of my SoCs (Exynos54xx), but I
>>>> find it over time unmaintainable approach. I strongly suggest to have
>>>> compatible and other properties in one place, so cv1800 and cv1812, even
>>>> if it duplicates the code.
>>>>
>>>
>>> Hi Krzysztof:
>>>
>>> Thanks for your advice, but I have a question about this: when I should
>>> use the DT override? The memory mapping of the CV1800 and CV1810 are
>>> almost the same (the CV1810 have more peripheral and the future SG200X
>>> have the same layout). IIRC, this is why conor suggested using DT override
>>> to make modification easier. But duplicating node seems to break thiS, so
>>> I's pretty confused.
>>
>> Go with whatever your subarchitecture and architecture maintainers
>> prefer, I just shared my opinion that I find such code difficult to read
>> and maintain.
>>
>> Extending node with supplies, pinctrl or even clocks would be readable.
>> But the compatible: no. The same applies when you need to delete
>> property or subnode: not readable/maintainable IMHO.
>
>There are apparently 3 or 4 of these SoCs that are basically identical,
>which is why the approach was taken. I do agree that it looks somewhat
>messy because I was looking for device-specific compatibles for these
>SoCs.
>

I agree that this may be messy. But it might still be acceptable if we
limit the number of devices in this format.

IIRC, only clint, plic, clk, maybe pinmux only needs different compatible.
For more complex device, such as tpu and codec, I agree with duplicating
nodes and make them SoC specific.

As for this patch, I have already adjusted the order of clock to ensure
the compatible among different SoCs. This will make the clock assignment
easier.
Conor Dooley Dec. 8, 2023, 3:02 p.m. UTC | #6 
On Fri, Dec 08, 2023 at 09:13:34AM +0800, Inochi Amaoto wrote:
> >On Thu, Dec 07, 2023 at 01:52:16PM +0100, Krzysztof Kozlowski wrote:
> >> On 07/12/2023 10:42, Inochi Amaoto wrote:
> >>>>> +&clk {
> >>>>> +	compatible = "sophgo,cv1810-clk";
> >>>>> +};
> >>>>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> >>>>> index 2d6f4a4b1e58..6ea1b2784db9 100644
> >>>>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> >>>>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
> >>>>> @@ -53,6 +53,12 @@ soc {
> >>>>>  		dma-noncoherent;
> >>>>>  		ranges;
> >>>>>
> >>>>> +		clk: clock-controller@3002000 {
> >>>>> +			reg = <0x03002000 0x1000>;
> >>>>> +			clocks = <&osc>;
> >>>>> +			#clock-cells = <1>;
> >>>>
> >>>> I don't find such layout readable and maintainable. I did some parts
> >>>> like this long, long time ago for one of my SoCs (Exynos54xx), but I
> >>>> find it over time unmaintainable approach. I strongly suggest to have
> >>>> compatible and other properties in one place, so cv1800 and cv1812, even
> >>>> if it duplicates the code.
> >>>>
> >>>
> >>> Hi Krzysztof:
> >>>
> >>> Thanks for your advice, but I have a question about this: when I should
> >>> use the DT override? The memory mapping of the CV1800 and CV1810 are
> >>> almost the same (the CV1810 have more peripheral and the future SG200X
> >>> have the same layout). IIRC, this is why conor suggested using DT override
> >>> to make modification easier. But duplicating node seems to break thiS, so
> >>> I's pretty confused.
> >>
> >> Go with whatever your subarchitecture and architecture maintainers
> >> prefer, I just shared my opinion that I find such code difficult to read
> >> and maintain.
> >>
> >> Extending node with supplies, pinctrl or even clocks would be readable.
> >> But the compatible: no. The same applies when you need to delete
> >> property or subnode: not readable/maintainable IMHO.
> >
> >There are apparently 3 or 4 of these SoCs that are basically identical,
> >which is why the approach was taken. I do agree that it looks somewhat
> >messy because I was looking for device-specific compatibles for these
> >SoCs.
> >
> 
> I agree that this may be messy. But it might still be acceptable if we
> limit the number of devices in this format.
> 
> IIRC, only clint, plic, clk, maybe pinmux only needs different compatible.
> For more complex device, such as tpu and codec, I agree with duplicating
> nodes and make them SoC specific.

Okay. We will see how it goes. We are not stuck doing it one way, we can
revisit the decision later if things start to be confusing.

> 
> As for this patch, I have already adjusted the order of clock to ensure
> the compatible among different SoCs. This will make the clock assignment
> easier.
Inochi Amaoto Dec. 9, 2023, 2:40 a.m. UTC | #7 
>
>On Fri, Dec 08, 2023 at 09:13:34AM +0800, Inochi Amaoto wrote:
>>> On Thu, Dec 07, 2023 at 01:52:16PM +0100, Krzysztof Kozlowski wrote:
>>>> On 07/12/2023 10:42, Inochi Amaoto wrote:
>>>>>>> +&clk {
>>>>>>> +	compatible = "sophgo,cv1810-clk";
>>>>>>> +};
>>>>>>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>>>> index 2d6f4a4b1e58..6ea1b2784db9 100644
>>>>>>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>>>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>>>> @@ -53,6 +53,12 @@ soc {
>>>>>>>  		dma-noncoherent;
>>>>>>>  		ranges;
>>>>>>>
>>>>>>> +		clk: clock-controller@3002000 {
>>>>>>> +			reg = <0x03002000 0x1000>;
>>>>>>> +			clocks = <&osc>;
>>>>>>> +			#clock-cells = <1>;
>>>>>>
>>>>>> I don't find such layout readable and maintainable. I did some parts
>>>>>> like this long, long time ago for one of my SoCs (Exynos54xx), but I
>>>>>> find it over time unmaintainable approach. I strongly suggest to have
>>>>>> compatible and other properties in one place, so cv1800 and cv1812, even
>>>>>> if it duplicates the code.
>>>>>>
>>>>>
>>>>> Hi Krzysztof:
>>>>>
>>>>> Thanks for your advice, but I have a question about this: when I should
>>>>> use the DT override? The memory mapping of the CV1800 and CV1810 are
>>>>> almost the same (the CV1810 have more peripheral and the future SG200X
>>>>> have the same layout). IIRC, this is why conor suggested using DT override
>>>>> to make modification easier. But duplicating node seems to break thiS, so
>>>>> I's pretty confused.
>>>>
>>>> Go with whatever your subarchitecture and architecture maintainers
>>>> prefer, I just shared my opinion that I find such code difficult to read
>>>> and maintain.
>>>>
>>>> Extending node with supplies, pinctrl or even clocks would be readable.
>>>> But the compatible: no. The same applies when you need to delete
>>>> property or subnode: not readable/maintainable IMHO.
>>>
>>> There are apparently 3 or 4 of these SoCs that are basically identical,
>>> which is why the approach was taken. I do agree that it looks somewhat
>>> messy because I was looking for device-specific compatibles for these
>>> SoCs.
>>>
>>
>> I agree that this may be messy. But it might still be acceptable if we
>> limit the number of devices in this format.
>>
>> IIRC, only clint, plic, clk, maybe pinmux only needs different compatible.
>> For more complex device, such as tpu and codec, I agree with duplicating
>> nodes and make them SoC specific.
>
>Okay. We will see how it goes. We are not stuck doing it one way, we can
>revisit the decision later if things start to be confusing.
>
>>
>> As for this patch, I have already adjusted the order of clock to ensure
>> the compatible among different SoCs. This will make the clock assignment
>> easier.
>
>
>On Fri, Dec 08, 2023 at 09:13:34AM +0800, Inochi Amaoto wrote:
>>> On Thu, Dec 07, 2023 at 01:52:16PM +0100, Krzysztof Kozlowski wrote:
>>>> On 07/12/2023 10:42, Inochi Amaoto wrote:
>>>>>>> +&clk {
>>>>>>> +	compatible = "sophgo,cv1810-clk";
>>>>>>> +};
>>>>>>> diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>>>> index 2d6f4a4b1e58..6ea1b2784db9 100644
>>>>>>> --- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>>>> +++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
>>>>>>> @@ -53,6 +53,12 @@ soc {
>>>>>>>  		dma-noncoherent;
>>>>>>>  		ranges;
>>>>>>>
>>>>>>> +		clk: clock-controller@3002000 {
>>>>>>> +			reg = <0x03002000 0x1000>;
>>>>>>> +			clocks = <&osc>;
>>>>>>> +			#clock-cells = <1>;
>>>>>>
>>>>>> I don't find such layout readable and maintainable. I did some parts
>>>>>> like this long, long time ago for one of my SoCs (Exynos54xx), but I
>>>>>> find it over time unmaintainable approach. I strongly suggest to have
>>>>>> compatible and other properties in one place, so cv1800 and cv1812, even
>>>>>> if it duplicates the code.
>>>>>>
>>>>>
>>>>> Hi Krzysztof:
>>>>>
>>>>> Thanks for your advice, but I have a question about this: when I should
>>>>> use the DT override? The memory mapping of the CV1800 and CV1810 are
>>>>> almost the same (the CV1810 have more peripheral and the future SG200X
>>>>> have the same layout). IIRC, this is why conor suggested using DT override
>>>>> to make modification easier. But duplicating node seems to break thiS, so
>>>>> I's pretty confused.
>>>>
>>>> Go with whatever your subarchitecture and architecture maintainers
>>>> prefer, I just shared my opinion that I find such code difficult to read
>>>> and maintain.
>>>>
>>>> Extending node with supplies, pinctrl or even clocks would be readable.
>>>> But the compatible: no. The same applies when you need to delete
>>>> property or subnode: not readable/maintainable IMHO.
>>>
>>> There are apparently 3 or 4 of these SoCs that are basically identical,
>>> which is why the approach was taken. I do agree that it looks somewhat
>>> messy because I was looking for device-specific compatibles for these
>>> SoCs.
>>>
>>
>> I agree that this may be messy. But it might still be acceptable if we
>> limit the number of devices in this format.
>>
>> IIRC, only clint, plic, clk, maybe pinmux only needs different compatible.
>> For more complex device, such as tpu and codec, I agree with duplicating
>> nodes and make them SoC specific.
>
>Okay. We will see how it goes. We are not stuck doing it one way, we can
>revisit the decision later if things start to be confusing.
>

Yes, now let's see what will happen and then improve it.

>>
>> As for this patch, I have already adjusted the order of clock to ensure
>> the compatible among different SoCs. This will make the clock assignment
>> easier.
>
diff mbox series

Patch

diff --git a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
index 165e9e320a8c..baf641829e72 100644
--- a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
+++ b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
@@ -16,3 +16,7 @@  &plic {
 &clint {
 	compatible = "sophgo,cv1800b-clint", "thead,c900-clint";
 };
+
+&clk {
+	compatible = "sophgo,cv1800-clk";
+};
diff --git a/arch/riscv/boot/dts/sophgo/cv1812h.dtsi b/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
index 9a375935b00c..83243c918204 100644
--- a/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
+++ b/arch/riscv/boot/dts/sophgo/cv1812h.dtsi
@@ -21,3 +21,7 @@  &plic {
 &clint {
 	compatible = "sophgo,cv1812h-clint", "thead,c900-clint";
 };
+
+&clk {
+	compatible = "sophgo,cv1810-clk";
+};
diff --git a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
index 2d6f4a4b1e58..6ea1b2784db9 100644
--- a/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
+++ b/arch/riscv/boot/dts/sophgo/cv18xx.dtsi
@@ -53,6 +53,12 @@  soc {
 		dma-noncoherent;
 		ranges;

+		clk: clock-controller@3002000 {
+			reg = <0x03002000 0x1000>;
+			clocks = <&osc>;
+			#clock-cells = <1>;
+		};
+
 		gpio0: gpio@3020000 {
 			compatible = "snps,dw-apb-gpio";
 			reg = <0x3020000 0x1000>;