mbox series

[v6,0/2] Nuvoton WPCM450 clock and reset driver

Message ID 20230415111355.696738-1-j.neuschaefer@gmx.net
Headers show
Series Nuvoton WPCM450 clock and reset driver | expand

Message

J. Neuschäfer April 15, 2023, 11:13 a.m. UTC
This series adds support for the clock and reset controller in the Nuvoton
WPCM450 SoC. This means that the clock rates for peripherals will be calculated
automatically based on the clock tree as it was preconfigured by the bootloader.
The 24 MHz dummy clock, that is currently in the devicetree, is no longer needed.
Somewhat unfortunately, this also means that there is a breaking change once
the devicetree starts relying on the clock driver, but I find it acceptable in
this case, because WPCM450 is still at a somewhat early stage.


v6:
- Dropped all patches except the clock binding and the clock driver, because
  they have mostly been merged
- Minor correction to how RESET_SIMPLE is selected

v5:
- Dropped patch 2 (watchdog: npcm: Enable clock if provided), which
  was since merged upstream
- Added patch 2 (clocksource: timer-npcm7xx: Enable timer 1 clock before use) again,
  because I wasn't able to find it in linux-next
- Switched the driver to using struct clk_parent_data
- Rebased on 6.1-rc3

v4:
- Leave WDT clock running during after restart handler
- Fix reset controller initialization
- Dropped patch 2/7 (clocksource: timer-npcm7xx: Enable timer 1 clock before use),
  as it was applied by Daniel Lezcano

v3:
- https://lore.kernel.org/lkml/20220508194333.2170161-1-j.neuschaefer@gmx.net/
- Changed "refclk" string to "ref"
- Fixed some dead code in the driver
- Added clk_prepare_enable call to the watchdog restart handler
- Added a few review tags

v2:
- https://lore.kernel.org/lkml/20220429172030.398011-1-j.neuschaefer@gmx.net/
- various small improvements

v1:
- https://lore.kernel.org/lkml/20220422183012.444674-1-j.neuschaefer@gmx.net/

Jonathan Neuschäfer (2):
  dt-bindings: clock: Add Nuvoton WPCM450 clock/reset controller
  clk: wpcm450: Add Nuvoton WPCM450 clock/reset controller driver

 .../bindings/clock/nuvoton,wpcm450-clk.yaml   |  66 +++
 drivers/clk/Makefile                          |   1 +
 drivers/clk/clk-wpcm450.c                     | 375 ++++++++++++++++++
 drivers/reset/Kconfig                         |   2 +-
 .../dt-bindings/clock/nuvoton,wpcm450-clk.h   |  67 ++++
 5 files changed, 510 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nuvoton,wpcm450-clk.yaml
 create mode 100644 drivers/clk/clk-wpcm450.c
 create mode 100644 include/dt-bindings/clock/nuvoton,wpcm450-clk.h

--
2.39.2

Comments

Christophe JAILLET April 15, 2023, 12:16 p.m. UTC | #1
Le 15/04/2023 à 13:13, Jonathan Neuschäfer a écrit :
> This driver implements the following features w.r.t. the clock and reset
> controller in the WPCM450 SoC:
> 
> - It calculates the rates for all clocks managed by the clock controller
> - It leaves the clock tree mostly unchanged, except that it enables/
>    disables clock gates based on usage.
> - It exposes the reset lines managed by the controller using the
>    Generic Reset Controller subsystem
> 
> NOTE: If the driver and the corresponding devicetree node are present,
>        the driver will disable "unused" clocks. This is problem until
>        the clock relations are properly declared in the devicetree (in a
>        later patch). Until then, the clk_ignore_unused kernel parameter
>        can be used as a workaround.
> 
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
> ---

[...]

> +
> +static void __init wpcm450_clk_init(struct device_node *clk_np)
> +{
> +	struct clk_hw_onecell_data *clk_data;
> +	static struct clk_hw **hws;
> +	static struct clk_hw *hw;
> +	void __iomem *clk_base;
> +	int i, ret;
> +	struct reset_simple_data *reset;
> +
> +	clk_base = of_iomap(clk_np, 0);
> +	if (!clk_base) {
> +		pr_err("%pOFP: failed to map registers\n", clk_np);
> +		of_node_put(clk_np);
> +		return;
> +	}
> +	of_node_put(clk_np);
> +
> +	clk_data = kzalloc(struct_size(clk_data, hws, WPCM450_NUM_CLKS), GFP_KERNEL);
> +	if (!clk_data)
> +		goto err_unmap;
> +
> +	clk_data->num = WPCM450_NUM_CLKS;
> +	hws = clk_data->hws;
> +
> +	for (i = 0; i < WPCM450_NUM_CLKS; i++)
> +		hws[i] = ERR_PTR(-ENOENT);
> +
> +	// PLLs
> +	for (i = 0; i < ARRAY_SIZE(pll_data); i++) {
> +		const struct wpcm450_pll_data *data = &pll_data[i];
> +
> +		hw = wpcm450_clk_register_pll(clk_base + data->reg, data->name,
> +					      &data->parent, data->flags);
> +		if (IS_ERR(hw)) {
> +			pr_info("Failed to register PLL: %pe", hw);
> +			goto err_free;
> +		}
> +	}
> +
> +	// Early divisors (REF/2)
> +	for (i = 0; i < ARRAY_SIZE(clkdiv_data_early); i++) {
> +		const struct wpcm450_clkdiv_data *data = &clkdiv_data_early[i];
> +
> +		hw = clk_hw_register_divider_table_parent_data(NULL, data->name, &data->parent,
> +							       data->flags, clk_base + REG_CLKDIV,
> +							       data->shift, data->width,
> +							       data->div_flags, data->table,
> +							       &wpcm450_clk_lock);
> +		if (IS_ERR(hw)) {
> +			pr_err("Failed to register div table: %pe\n", hw);
> +			goto err_free;
> +		}
> +	}
> +
> +	// Selects/muxes
> +	for (i = 0; i < ARRAY_SIZE(clksel_data); i++) {
> +		const struct wpcm450_clksel_data *data = &clksel_data[i];
> +
> +		hw = clk_hw_register_mux_parent_data(NULL, data->name, data->parents,
> +						     data->num_parents, data->flags,
> +						     clk_base + REG_CLKSEL, data->shift,
> +						     data->width, 0,
> +						     &wpcm450_clk_lock);
> +		if (IS_ERR(hw)) {
> +			pr_err("Failed to register mux: %pe\n", hw);
> +			goto err_free;
> +		}
> +		if (data->index >= 0)
> +			clk_data->hws[data->index] = hw;
> +	}
> +
> +	// Divisors
> +	for (i = 0; i < ARRAY_SIZE(clkdiv_data); i++) {
> +		const struct wpcm450_clkdiv_data *data = &clkdiv_data[i];
> +
> +		hw = clk_hw_register_divider_table_parent_data(NULL, data->name, &data->parent,
> +							       data->flags, clk_base + REG_CLKDIV,
> +							       data->shift, data->width,
> +							       data->div_flags, data->table,
> +							       &wpcm450_clk_lock);
> +		if (IS_ERR(hw)) {
> +			pr_err("Failed to register divider: %pe\n", hw);
> +			goto err_free;
> +		}
> +	}
> +
> +	// Enables/gates
> +	for (i = 0; i < ARRAY_SIZE(clken_data); i++) {
> +		const struct wpcm450_clken_data *data = &clken_data[i];
> +
> +		hw = clk_hw_register_gate_parent_data(NULL, data->name, &data->parent, data->flags,
> +						      clk_base + REG_CLKEN, data->bitnum,
> +						      data->flags, &wpcm450_clk_lock);

If an error occures in the 'for' loop or after it, should this be 
clk_hw_unregister_gate()'ed somewhere?

CJ

> +		if (IS_ERR(hw)) {
> +			pr_err("Failed to register gate: %pe\n", hw);
> +			goto err_free;
> +		}
> +		clk_data->hws[data->bitnum] = hw;
> +	}
> +
> +	ret = of_clk_add_hw_provider(clk_np, of_clk_hw_onecell_get, clk_data);
> +	if (ret)
> +		pr_err("Failed to add DT provider: %d\n", ret);
> +
> +	// Reset controller
> +	reset = kzalloc(sizeof(*reset), GFP_KERNEL);
> +	if (!reset)
> +		goto err_free;
> +	reset->rcdev.owner = THIS_MODULE;
> +	reset->rcdev.nr_resets = WPCM450_NUM_RESETS;
> +	reset->rcdev.ops = &reset_simple_ops;
> +	reset->rcdev.of_node = clk_np;
> +	reset->membase = clk_base + REG_IPSRST;
> +	ret = reset_controller_register(&reset->rcdev);
> +	if (ret)
> +		pr_err("Failed to register reset controller: %d\n", ret);
> +
> +	of_node_put(clk_np);
> +	return;
> +
> +err_free:
> +	kfree(clk_data->hws);
> +err_unmap:
> +	iounmap(clk_base);
> +	of_node_put(clk_np);
> +}
> +
> +CLK_OF_DECLARE(wpcm450_clk_init, "nuvoton,wpcm450-clk", wpcm450_clk_init);
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 2a52c990d4fec..16e111d213560 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -208,7 +208,7 @@ config RESET_SCMI
> 
>   config RESET_SIMPLE
>   	bool "Simple Reset Controller Driver" if COMPILE_TEST || EXPERT
> -	default ARCH_ASPEED || ARCH_BCMBCA || ARCH_BITMAIN || ARCH_REALTEK || ARCH_STM32 || (ARCH_INTEL_SOCFPGA && ARM64) || ARCH_SUNXI || ARC
> +	default ARCH_ASPEED || ARCH_BCMBCA || ARCH_BITMAIN || ARCH_REALTEK || ARCH_STM32 || (ARCH_INTEL_SOCFPGA && ARM64) || ARCH_SUNXI || ARC || ARCH_WPCM450
>   	depends on HAS_IOMEM
>   	help
>   	  This enables a simple reset controller driver for reset lines that
> --
> 2.39.2
> 
>
J. Neuschäfer April 19, 2023, 9:52 p.m. UTC | #2
Hello Christophe,

On Sat, Apr 15, 2023 at 02:16:09PM +0200, Christophe JAILLET wrote:
> Le 15/04/2023 à 13:13, Jonathan Neuschäfer a écrit :
> > This driver implements the following features w.r.t. the clock and reset
> > controller in the WPCM450 SoC:
> > 
> > - It calculates the rates for all clocks managed by the clock controller
> > - It leaves the clock tree mostly unchanged, except that it enables/
> >    disables clock gates based on usage.
> > - It exposes the reset lines managed by the controller using the
> >    Generic Reset Controller subsystem
> > 
> > NOTE: If the driver and the corresponding devicetree node are present,
> >        the driver will disable "unused" clocks. This is problem until
> >        the clock relations are properly declared in the devicetree (in a
> >        later patch). Until then, the clk_ignore_unused kernel parameter
> >        can be used as a workaround.
> > 
> > Signed-off-by: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
> > ---
[...]
> > +	// Enables/gates
> > +	for (i = 0; i < ARRAY_SIZE(clken_data); i++) {
> > +		const struct wpcm450_clken_data *data = &clken_data[i];
> > +
> > +		hw = clk_hw_register_gate_parent_data(NULL, data->name, &data->parent, data->flags,
> > +						      clk_base + REG_CLKEN, data->bitnum,
> > +						      data->flags, &wpcm450_clk_lock);
> 
> If an error occures in the 'for' loop or after it, should this be
> clk_hw_unregister_gate()'ed somewhere?

Ideally yes —

in this case, if the clock driver fails, the system is arguably in such
a bad state that there isn't much point in bothering.


> 
> CJ
> 
> > +		if (IS_ERR(hw)) {
> > +			pr_err("Failed to register gate: %pe\n", hw);
> > +			goto err_free;
> > +		}
> > +		clk_data->hws[data->bitnum] = hw;
> > +	}



Best regards,
Jonathan
Christophe JAILLET April 20, 2023, 5:32 a.m. UTC | #3
Le 19/04/2023 à 23:52, Jonathan Neuschäfer a écrit :
> Hello Christophe,
> 
> On Sat, Apr 15, 2023 at 02:16:09PM +0200, Christophe JAILLET wrote:
>> Le 15/04/2023 à 13:13, Jonathan Neuschäfer a écrit :
>>> This driver implements the following features w.r.t. the clock and reset
>>> controller in the WPCM450 SoC:
>>>
>>> - It calculates the rates for all clocks managed by the clock controller
>>> - It leaves the clock tree mostly unchanged, except that it enables/
>>>     disables clock gates based on usage.
>>> - It exposes the reset lines managed by the controller using the
>>>     Generic Reset Controller subsystem
>>>
>>> NOTE: If the driver and the corresponding devicetree node are present,
>>>         the driver will disable "unused" clocks. This is problem until
>>>         the clock relations are properly declared in the devicetree (in a
>>>         later patch). Until then, the clk_ignore_unused kernel parameter
>>>         can be used as a workaround.
>>>
>>> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
>>> ---
> [...]
>>> +	// Enables/gates
>>> +	for (i = 0; i < ARRAY_SIZE(clken_data); i++) {
>>> +		const struct wpcm450_clken_data *data = &clken_data[i];
>>> +
>>> +		hw = clk_hw_register_gate_parent_data(NULL, data->name, &data->parent, data->flags,
>>> +						      clk_base + REG_CLKEN, data->bitnum,
>>> +						      data->flags, &wpcm450_clk_lock);
>>
>> If an error occures in the 'for' loop or after it, should this be
>> clk_hw_unregister_gate()'ed somewhere?
> 
> Ideally yes —
> 
> in this case, if the clock driver fails, the system is arguably in such
> a bad state that there isn't much point in bothering.
> 

Ok, but below we care about freeing clk_data->hws in the error handling 
path.

Why do we handle just half of the resources?
Shouldn't it be all (to be clean, if it makes sense) or nothing (to 
reduce the LoC and have a smaller driver)?

CJ

> 
>>
>> CJ
>>
>>> +		if (IS_ERR(hw)) {
>>> +			pr_err("Failed to register gate: %pe\n", hw);
>>> +			goto err_free;
>>> +		}
>>> +		clk_data->hws[data->bitnum] = hw;
>>> +	}
> 
> 
> 
> Best regards,
> Jonathan
J. Neuschäfer April 22, 2023, 3:56 p.m. UTC | #4
On Thu, Apr 20, 2023 at 07:32:07AM +0200, Christophe JAILLET wrote:
> Le 19/04/2023 à 23:52, Jonathan Neuschäfer a écrit :
> > On Sat, Apr 15, 2023 at 02:16:09PM +0200, Christophe JAILLET wrote:
> > > Le 15/04/2023 à 13:13, Jonathan Neuschäfer a écrit :
[...]
> > > > +	// Enables/gates
> > > > +	for (i = 0; i < ARRAY_SIZE(clken_data); i++) {
> > > > +		const struct wpcm450_clken_data *data = &clken_data[i];
> > > > +
> > > > +		hw = clk_hw_register_gate_parent_data(NULL, data->name, &data->parent, data->flags,
> > > > +						      clk_base + REG_CLKEN, data->bitnum,
> > > > +						      data->flags, &wpcm450_clk_lock);
> > > 
> > > If an error occures in the 'for' loop or after it, should this be
> > > clk_hw_unregister_gate()'ed somewhere?
> > 
> > Ideally yes —
> > 
> > in this case, if the clock driver fails, the system is arguably in such
> > a bad state that there isn't much point in bothering.
> > 
> 
> Ok, but below we care about freeing clk_data->hws in the error handling
> path.
> 
> Why do we handle just half of the resources?
> Shouldn't it be all (to be clean, if it makes sense) or nothing (to reduce
> the LoC and have a smaller driver)?

I thought about it for a bit, and I think I'm ok with reducing the
deallocation in this driver to nothing. I'll spin a new version.

Conversely, if I were to implement proper error handling here, I'd
convert it into a platform driver and use devm_* functions, because
dealing with all the little clock objects is just too painful and
fragile for my taste.


Thanks,
Jonathan