[PATCH v6 0/3] riscv: canaan: Add support for K230-Canmv clock

Xukai Wang posted 3 patches 8 months ago
.../devicetree/bindings/clock/canaan,k230-clk.yaml |   43 +
arch/riscv/boot/dts/canaan/k230.dtsi               |   25 +-
drivers/clk/Kconfig                                |    6 +
drivers/clk/Makefile                               |    1 +
drivers/clk/clk-k230.c                             | 1710 ++++++++++++++++++++
include/dt-bindings/clock/canaan,k230-clk.h        |   69 +
6 files changed, 1846 insertions(+), 8 deletions(-)
[PATCH v6 0/3] riscv: canaan: Add support for K230-Canmv clock
Posted by Xukai Wang 8 months ago
This patch series adds clock controller support for the Canaan Kendryte
K230 SoC. The K230 SoC includes an external 24MHz OSC and 4 internal
PLLs, with the controller managing these sources and their derived clocks.

The clock tree and hardware-specific definition can be found in the
vendor's DTS [1],
and this series is based on the K230 initial series [2].

Link: https://github.com/ruyisdk/linux-xuantie-kernel/blob/linux-6.6.36/arch/riscv/boot/dts/canaan/k230_clock_provider.dtsi [1]
Link: https://lore.kernel.org/linux-clk/tencent_F76EB8D731C521C18D5D7C4F8229DAA58E08@qq.com/ [2]

Co-developed-by: Troy Mitchell <TroyMitchell988@gmail.com>
Signed-off-by: Troy Mitchell <TroyMitchell988@gmail.com>
Signed-off-by: Xukai Wang <kingxukai@zohomail.com>

---
Changes in v6:
- Remove some redundant comments in struct declaration.
- Replace the Vendor's code source link with a new one.
- Link to v5: https://lore.kernel.org/r/20250320-b4-k230-clk-v5-0-0e9d089c5488@zohomail.com

Changes in v5:
- Fix incorrect base-commit and add prerequisite-patch-id.
- Replace dummy apb_clk with real ones for UARTs.
- Add IDs of UARTs clock and DMA clocks in the binding header.
- Replace k230_clk_cfgs[] array with corresponding named variables.
- Remove some redundant checks in clk_ops.
- Drop the unnecessary parenthesis and type casts.
- Modify return value handling in probe path to avoid redundant print.
- Link to v4: https://lore.kernel.org/r/20250217-b4-k230-clk-v4-0-5a95a3458691@zohomail.com

Changes in v4:
- Remove redundant onecell_get callback and add_provider function
for pll_divs.
- Modify the base-commit in cover letter.
- Link to v3: https://lore.kernel.org/r/20250203-b4-k230-clk-v3-0-362c79124572@zohomail.com

Changes in v3:
- Reorder the defination and declaration in drivers code.
- Reorder the properties in dts node.
- Replace global variable `k230_sysclk` with dynamic memory allocation.
- Rename the macro K230_NUM_CLKS to K230_CLK_NUM.
- Use dev_err_probe for error handling.
- Remove unused includes.
- Link to v2: https://lore.kernel.org/r/20250108-b4-k230-clk-v2-0-27b30a2ca52d@zohomail.com

Changes in v2:
- Add items and description.
- Rename k230-clk.h to canaan,k230-clk.h
- Link to v1: https://lore.kernel.org/r/20241229-b4-k230-clk-v1-0-221a917e80ed@zohomail.com

---
Xukai Wang (3):
      dt-bindings: clock: Add bindings for Canaan K230 clock controller
      clk: canaan: Add clock driver for Canaan K230
      riscv: dts: canaan: Add clock definition for K230

 .../devicetree/bindings/clock/canaan,k230-clk.yaml |   43 +
 arch/riscv/boot/dts/canaan/k230.dtsi               |   25 +-
 drivers/clk/Kconfig                                |    6 +
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-k230.c                             | 1710 ++++++++++++++++++++
 include/dt-bindings/clock/canaan,k230-clk.h        |   69 +
 6 files changed, 1846 insertions(+), 8 deletions(-)
---
base-commit: 0eea987088a22d73d81e968de7347cdc7e594f72
change-id: 20241206-b4-k230-clk-925f33fed6c2
prerequisite-patch-id: deda3c472f0000ffd40cddd7cf6d3b5e2d7da7dc

Best regards,
-- 
Xukai Wang <kingxukai@zohomail.com>
Re: [PATCH v6 0/3] riscv: canaan: Add support for K230-Canmv clock
Posted by Xukai Wang 5 months ago
On 2025/4/15 22:25, Xukai Wang wrote:
> This patch series adds clock controller support for the Canaan Kendryte
> K230 SoC. The K230 SoC includes an external 24MHz OSC and 4 internal
> PLLs, with the controller managing these sources and their derived clocks.
>
> The clock tree and hardware-specific definition can be found in the
> vendor's DTS [1],
> and this series is based on the K230 initial series [2].
>
> Link: https://github.com/ruyisdk/linux-xuantie-kernel/blob/linux-6.6.36/arch/riscv/boot/dts/canaan/k230_clock_provider.dtsi [1]
> Link: https://lore.kernel.org/linux-clk/tencent_F76EB8D731C521C18D5D7C4F8229DAA58E08@qq.com/ [2]
>
> Co-developed-by: Troy Mitchell <TroyMitchell988@gmail.com>
> Signed-off-by: Troy Mitchell <TroyMitchell988@gmail.com>
> Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
>
> ---
> Changes in v6:
> - Remove some redundant comments in struct declaration.
> - Replace the Vendor's code source link with a new one.
> - Link to v5: https://lore.kernel.org/r/20250320-b4-k230-clk-v5-0-0e9d089c5488@zohomail.com
>
> Changes in v5:
> - Fix incorrect base-commit and add prerequisite-patch-id.
> - Replace dummy apb_clk with real ones for UARTs.
> - Add IDs of UARTs clock and DMA clocks in the binding header.
> - Replace k230_clk_cfgs[] array with corresponding named variables.
> - Remove some redundant checks in clk_ops.
> - Drop the unnecessary parenthesis and type casts.
> - Modify return value handling in probe path to avoid redundant print.
> - Link to v4: https://lore.kernel.org/r/20250217-b4-k230-clk-v4-0-5a95a3458691@zohomail.com
>
> Changes in v4:
> - Remove redundant onecell_get callback and add_provider function
> for pll_divs.
> - Modify the base-commit in cover letter.
> - Link to v3: https://lore.kernel.org/r/20250203-b4-k230-clk-v3-0-362c79124572@zohomail.com
>
> Changes in v3:
> - Reorder the defination and declaration in drivers code.
> - Reorder the properties in dts node.
> - Replace global variable `k230_sysclk` with dynamic memory allocation.
> - Rename the macro K230_NUM_CLKS to K230_CLK_NUM.
> - Use dev_err_probe for error handling.
> - Remove unused includes.
> - Link to v2: https://lore.kernel.org/r/20250108-b4-k230-clk-v2-0-27b30a2ca52d@zohomail.com
>
> Changes in v2:
> - Add items and description.
> - Rename k230-clk.h to canaan,k230-clk.h
> - Link to v1: https://lore.kernel.org/r/20241229-b4-k230-clk-v1-0-221a917e80ed@zohomail.com
>
> ---
> Xukai Wang (3):
>       dt-bindings: clock: Add bindings for Canaan K230 clock controller
>       clk: canaan: Add clock driver for Canaan K230
>       riscv: dts: canaan: Add clock definition for K230
>
>  .../devicetree/bindings/clock/canaan,k230-clk.yaml |   43 +
>  arch/riscv/boot/dts/canaan/k230.dtsi               |   25 +-
>  drivers/clk/Kconfig                                |    6 +
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/clk-k230.c                             | 1710 ++++++++++++++++++++
>  include/dt-bindings/clock/canaan,k230-clk.h        |   69 +
>  6 files changed, 1846 insertions(+), 8 deletions(-)
> ---
> base-commit: 0eea987088a22d73d81e968de7347cdc7e594f72
> change-id: 20241206-b4-k230-clk-925f33fed6c2
> prerequisite-patch-id: deda3c472f0000ffd40cddd7cf6d3b5e2d7da7dc
>
> Best regards,
Dear all,

I'm working on a Linux clock driver and have encountered a question
regarding how to properly represent a particular type of clock source.

In K230 SoC, there's a mux clock whose parent can optionally be an
external pulse signal, which is counted via a pin (the input is not
generated internally but comes from an external source). I’m wondering:

Should this external pulse signal be modeled as a clock within the
Common Clock Framework (CCF)?

If so, what would be the correct way to register or describe such a
clock in the driver?

Any guidance or examples would be greatly appreciated.

Re: [PATCH v6 0/3] riscv: canaan: Add support for K230-Canmv clock
Posted by Stephen Boyd 4 months, 3 weeks ago
Quoting Xukai Wang (2025-07-13 09:48:44)
> 
> I'm working on a Linux clock driver and have encountered a question
> regarding how to properly represent a particular type of clock source.
> 
> In K230 SoC, there's a mux clock whose parent can optionally be an
> external pulse signal, which is counted via a pin (the input is not
> generated internally but comes from an external source). I’m wondering:
> 
> Should this external pulse signal be modeled as a clock within the
> Common Clock Framework (CCF)?

Likely, yes.

> 
> If so, what would be the correct way to register or describe such a
> clock in the driver?

If it is a fixed rate pulse signal I would use a fixed rate clk node at
the root of the DT tree:

	clock-50000 {
		compatible = "fixed-clock";
		#clock-cells = <0>;
		clock-frequency = <50000>;
	}

If you need pinctrl settings to make that clk work you can assign them
in that node, although I don't know if I've ever seen such a case
before. If the external parent clk needs to be gated you'll need to
write a more featured driver, unless it can be controlled with a gpio or
something like that.
Re: [PATCH v6 0/3] riscv: canaan: Add support for K230-Canmv clock
Posted by Xukai Wang 4 months, 3 weeks ago
On 2025/7/25 06:13, Stephen Boyd wrote:
> Quoting Xukai Wang (2025-07-13 09:48:44)
>> I'm working on a Linux clock driver and have encountered a question
>> regarding how to properly represent a particular type of clock source.
>>
>> In K230 SoC, there's a mux clock whose parent can optionally be an
>> external pulse signal, which is counted via a pin (the input is not
>> generated internally but comes from an external source). I’m wondering:
>>
>> Should this external pulse signal be modeled as a clock within the
>> Common Clock Framework (CCF)?
> Likely, yes.
>
>> If so, what would be the correct way to register or describe such a
>> clock in the driver?
> If it is a fixed rate pulse signal I would use a fixed rate clk node at
> the root of the DT tree:
>
> 	clock-50000 {
> 		compatible = "fixed-clock";
> 		#clock-cells = <0>;
> 		clock-frequency = <50000>;
> 	}
>
> If you need pinctrl settings to make that clk work you can assign them
> in that node, although I don't know if I've ever seen such a case
> before. 
Thanks for your reply and helpful explanation!

Regarding the timer-pulse-in, the documentation describes it as:

"can be used to count external input signal with frequency less than
1MHz and duty cycle from 0~100%"

So the input frequency is not fixed in practice.

Given that, modeling it as a fixed-rate clock might not be accurate.

And I'm considering whether a more feature-rich driver is needed to
handle the dynamically changing external clock, or if there's a better
way to describe such a clock in the CCF.

> If the external parent clk needs to be gated you'll need to
> write a more featured driver, unless it can be controlled with a gpio or
> something like that.
and I think it doesn't need to be gated.