Hi Guenter,
Yes, of course, it works in real hardware.
The modification was made since the reset and clock share the same
register memory region.
To enable the clock change needs to be done in the device tree as
follows (we are planning to send these change patches soon):
diff -Naur a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
2025-02-26 16:20:39.000000000 +0200
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
2025-03-17 12:29:17.876551537 +0200
@@ -47,19 +47,16 @@
interrupt-parent = <&gic>;
ranges;
- rstc: reset-controller@f0801000 {
+ clk: rstc: reset-controller@f0801000 {
compatible = "nuvoton,npcm845-reset";
- reg = <0x0 0xf0801000 0x0 0x78>;
- #reset-cells = <2>;
+ reg = <0x0 0xf0801000 0x0 0xC4>;
nuvoton,sysgcr = <&gcr>;
- };
-
- clk: clock-controller@f0801000 {
- compatible = "nuvoton,npcm845-clk";
+ #reset-cells = <2>;
+ clocks = <&refclk>;
#clock-cells = <1>;
- reg = <0x0 0xf0801000 0x0 0x1000>;
};
+
apb {
#address-cells = <1>;
#size-cells = <1>;
diff -Naur a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
2025-02-26 16:20:39.000000000 +0200
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
2025-03-17 12:24:52.293171764 +0200
@@ -19,6 +19,13 @@
memory@0 {
reg = <0x0 0x0 0x0 0x40000000>;
};
+
+ refclk: refclk-25mhz {
+ compatible = "fixed-clock";
+ clock-output-names = "ref";
+ clock-frequency = <25000000>;
+ #clock-cells = <0>;
+ };
};
&serial0 {
Is it better to modify the reset driver with your suggestion or change
the device tree?
Thanks,
Tomer
On Sun, 16 Mar 2025 at 17:22, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Thu, Sep 12, 2024 at 10:10:37PM +0300, Tomer Maimon wrote:
> > Add NPCM8xx clock controller auxiliary bus device registration.
> >
> > The NPCM8xx clock controller is registered as an aux device because the
> > reset and the clock controller share the same register region.
> >
> > Signed-off-by: Tomer Maimon <tmaimon77@xxxxxxxxx>
> > Tested-by: Benjamin Fair <benjaminfair@xxxxxxxxxx>
> > Reviewed-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
>
> Does this work with real hardware ? I tried with the new qemu emulation,
> but that gets stuck in the serial driver initialization. I found that the clock
> device instantiates but does not register as clock provider because it does
> not have a device node. I needed something like the patch below to get beyond
> that point.
>
> Thanks,
> Guenter
>
> ---
> From: Guenter Roeck <linux@xxxxxxxxxxxx>
> Subject: [PATCH] reset: npcm: Provide device node to clock driver
>
> Without device node, the clock driver can not register itself as clock
> provider. With debugging enabled, this manifests itself with
>
> of_serial f0000000.serial: error -EPROBE_DEFER: failed to get clock
> of_serial f0000000.serial: Driver of_serial requests probe deferral
> platform f0000000.serial: Added to deferred list
> ...
> Warning: unable to open an initial console.
>
> Look up the device node and attach it to the clock device to solve the
> problem.
>
> Fixes: 22823157d90c ("reset: npcm: register npcm8xx clock auxiliary bus device")
> Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> ---
> drivers/reset/reset-npcm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/reset/reset-npcm.c b/drivers/reset/reset-npcm.c
> index e5b6127783a7..43bc46755e82 100644
> --- a/drivers/reset/reset-npcm.c
> +++ b/drivers/reset/reset-npcm.c
> @@ -409,6 +409,8 @@ static struct auxiliary_device *npcm_clock_adev_alloc(struct npcm_rc_data *rst_d
> adev->name = clk_name;
> adev->dev.parent = rst_data->dev;
> adev->dev.release = npcm_clock_adev_release;
> + adev->dev.of_node = of_find_compatible_node(rst_data->dev->parent->of_node,
> + NULL, "nuvoton,npcm845-clk");
> adev->id = 555u;
>
> ret = auxiliary_device_init(adev);
> --
> 2.45.2
>
