Message-ID: <20230921212438.dq66fcwgrgqrg57d@pengutronix.de>
Date:   Thu, 21 Sep 2023 23:24:38 +0200
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Aleksandr Shubin <privatesub2@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
        linux-pwm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v6 2/3] pwm: Add Allwinner's D1/T113-S3/R329 SoCs PWM
 support

Hello Aleksandr,

On Thu, Aug 24, 2023 at 02:40:26PM +0300, Aleksandr Shubin wrote:
> Allwinner's D1, T113-S3 and R329 SoCs have a quite different PWM
> controllers with ones supported by pwm-sun4i driver.
> 
> This patch adds a PWM controller driver for Allwinner's D1,
> T113-S3 and R329 SoCs. The main difference between these SoCs
> is the number of channels defined by the DT property.
> 
> Signed-off-by: Aleksandr Shubin <privatesub2@...il.com>
> ---
>  drivers/pwm/Kconfig      |  10 ++
>  drivers/pwm/Makefile     |   1 +
>  drivers/pwm/pwm-sun20i.c | 328 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 339 insertions(+)
>  create mode 100644 drivers/pwm/pwm-sun20i.c
> 
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 8df861b1f4a3..05c48a36969e 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -594,6 +594,16 @@ config PWM_SUN4I
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called pwm-sun4i.
>  
> +config PWM_SUN20I
> +	tristate "Allwinner D1/T113s/R329 PWM support"
> +	depends on ARCH_SUNXI || COMPILE_TEST
> +	depends on COMMON_CLK
> +	help
> +	  Generic PWM framework driver for Allwinner D1/T113s/R329 SoCs.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called pwm-sun20i.
> +
>  config PWM_SUNPLUS
>  	tristate "Sunplus PWM support"
>  	depends on ARCH_SUNPLUS || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 19899b912e00..cea872e22c78 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_PWM_STM32)		+= pwm-stm32.o
>  obj-$(CONFIG_PWM_STM32_LP)	+= pwm-stm32-lp.o
>  obj-$(CONFIG_PWM_STMPE)		+= pwm-stmpe.o
>  obj-$(CONFIG_PWM_SUN4I)		+= pwm-sun4i.o
> +obj-$(CONFIG_PWM_SUN20I)	+= pwm-sun20i.o
>  obj-$(CONFIG_PWM_SUNPLUS)	+= pwm-sunplus.o
>  obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
>  obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
> diff --git a/drivers/pwm/pwm-sun20i.c b/drivers/pwm/pwm-sun20i.c
> new file mode 100644
> index 000000000000..20e6b7b5b62e
> --- /dev/null
> +++ b/drivers/pwm/pwm-sun20i.c
> @@ -0,0 +1,328 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PWM Controller Driver for sunxi platforms (D1, T113-S3 and R329)
> + *
> + * Limitations:
> + * - When the parameters change, current running period will not be completed
> + *   and run new settings immediately.
> + * - It output HIGH-Z state when PWM channel disabled.
> + *
> + * Copyright (c) 2023 Aleksandr Shubin <privatesub2@...il.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/pwm.h>
> +#include <linux/reset.h>
> +
> +#define PWM_CLK_CFG(chan)		(0x20 + (((chan) >> 1) * 0x4))
> +#define PWM_CLK_CFG_SRC			GENMASK(8, 7)
> +#define PWM_CLK_CFG_DIV_M		GENMASK(3, 0)
> +
> +#define PWM_CLK_GATE			0x40
> +#define PWM_CLK_GATE_BYPASS(chan)	BIT((chan) - 16)

Really? With chan == 0 this gives you BIT(-16).

> +#define PWM_CLK_GATE_GATING(chan)	BIT(chan)
> +
> +#define PWM_ENABLE			0x80
> +#define PWM_ENABLE_EN(chan)		BIT(chan)
> +
> +#define PWM_CTL(chan)			(0x100 + (chan) * 0x20)
> +#define PWM_CTL_ACT_STA			BIT(8)
> +#define PWM_CTL_PRESCAL_K		GENMASK(7, 0)
> +
> +#define PWM_PERIOD(chan)		(0x104 + (chan) * 0x20)
> +#define PWM_PERIOD_ENTIRE_CYCLE		GENMASK(31, 16)
> +#define PWM_PERIOD_ACT_CYCLE		GENMASK(15, 0)
> +
> +#define PWM_MAGIC			(255 * 65535 + 2 * 65534 + 1)

A comment about PWM_MAGIC would be nice.

I'd like to have these register defines prefixed with (say) SUN20I_,
otherwise the names are too generic and likely overlap with other
defines.

> +struct sun20i_pwm_chip {
> +	struct clk *clk_bus, *clk_hosc, *clk_apb0;
> +	struct reset_control *rst;
> +	struct pwm_chip chip;
> +	void __iomem *base;
> +	/* Mutex to protect pwm apply state */
> +	struct mutex mutex;
> +};
> +
> +static inline struct sun20i_pwm_chip *to_sun20i_pwm_chip(struct pwm_chip *chip)
> +{
> +	return container_of(chip, struct sun20i_pwm_chip, chip);
> +}
> +
> +static inline u32 sun20i_pwm_readl(struct sun20i_pwm_chip *chip,
> +				   unsigned long offset)
> +{
> +	return readl(chip->base + offset);
> +}
> +
> +static inline void sun20i_pwm_writel(struct sun20i_pwm_chip *chip,
> +				     u32 val, unsigned long offset)
> +{
> +	writel(val, chip->base + offset);
> +}
> +
> +static int sun20i_pwm_get_state(struct pwm_chip *chip,
> +				struct pwm_device *pwm,
> +				struct pwm_state *state)
> +{
> +	struct sun20i_pwm_chip *sun20i_chip = to_sun20i_pwm_chip(chip);
> +	u16 ent_cycle, act_cycle, prescal;
> +	u64 clk_rate, tmp;
> +	u8 div_id;
> +	u32 val;
> +
> +	mutex_lock(&sun20i_chip->mutex);
> +
> +	val = sun20i_pwm_readl(sun20i_chip, PWM_CLK_CFG(pwm->hwpwm));
> +	div_id = FIELD_GET(PWM_CLK_CFG_DIV_M, val);
> +	if (FIELD_GET(PWM_CLK_CFG_SRC, val) == 0)
> +		clk_rate = clk_get_rate(sun20i_chip->clk_hosc);
> +	else
> +		clk_rate = clk_get_rate(sun20i_chip->clk_apb0);
> +
> +	val = sun20i_pwm_readl(sun20i_chip, PWM_CTL(pwm->hwpwm));
> +	state->polarity = (PWM_CTL_ACT_STA & val) ? PWM_POLARITY_NORMAL : PWM_POLARITY_INVERSED;
> +
> +	prescal = FIELD_GET(PWM_CTL_PRESCAL_K, val) + 1;
> +
> +	val = sun20i_pwm_readl(sun20i_chip, PWM_ENABLE);
> +	state->enabled = (PWM_ENABLE_EN(pwm->hwpwm) & val) ? true : false;
> +
> +	val = sun20i_pwm_readl(sun20i_chip, PWM_PERIOD(pwm->hwpwm));

You can release the lock already here (or even after PWM_ENABLE is
read?)

> +	act_cycle = FIELD_GET(PWM_PERIOD_ACT_CYCLE, val);
> +	ent_cycle = FIELD_GET(PWM_PERIOD_ENTIRE_CYCLE, val);
> +
> +	/*
> +	 * The duration of the active phase should not be longer
> +	 * than the duration of the period
> +	 */
> +	if (act_cycle > ent_cycle)
> +		act_cycle = ent_cycle;
> +
> +	tmp = ((u64)(act_cycle) * prescal << div_id) * NSEC_PER_SEC;

act_cycle is a 16 bit value, prescal is <= 256 and div_id is <= 15. So
the maximal value tmp has to hold is 0x1dcd47329b00000000. This doesn't
fit into an u64. You need something like mul_u64_u64_div64_roundup here.

> +	state->duty_cycle = DIV_ROUND_UP_ULL(tmp, clk_rate);
> +	tmp = ((u64)(ent_cycle) * prescal << div_id) * NSEC_PER_SEC;
> +	state->period = DIV_ROUND_UP_ULL(tmp, clk_rate);
> +	mutex_unlock(&sun20i_chip->mutex);
> +
> +	return 0;
> +}
> +
> +static int sun20i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			    const struct pwm_state *state)
> +{
> +	struct sun20i_pwm_chip *sun20i_chip = to_sun20i_pwm_chip(chip);
> +	u32 clk_gate, clk_cfg, pwm_en, ctl, period;
> +	u64 bus_rate, hosc_rate, clk_div, val;
> +	u32 prescaler, div_m;
> +	bool use_bus_clk;
> +	int ret = 0;
> +
> +	mutex_lock(&sun20i_chip->mutex);
> +
> +	pwm_en = sun20i_pwm_readl(sun20i_chip, PWM_ENABLE);
> +
> +	if (state->enabled != pwm->state.enabled)
> +		clk_gate = sun20i_pwm_readl(sun20i_chip, PWM_CLK_GATE);
> +
> +	if (state->enabled != pwm->state.enabled && !state->enabled) {
> +		clk_gate &= ~PWM_CLK_GATE_GATING(pwm->hwpwm);
> +		pwm_en &= ~PWM_ENABLE_EN(pwm->hwpwm);
> +		sun20i_pwm_writel(sun20i_chip, pwm_en, PWM_ENABLE);
> +		sun20i_pwm_writel(sun20i_chip, clk_gate, PWM_CLK_GATE);

Does ENABLE configure if the output pin is driven?

> +	}

You can these to like:

	if (state->enabled != pwm->state.enabled) {
		clk_gate = ...
		if (!state->enabled) {
			...
		}
	}

> +
> +	if (state->polarity != pwm->state.polarity ||
> +	    state->duty_cycle != pwm->state.duty_cycle ||
> +	    state->period != pwm->state.period) {
> +		ctl = sun20i_pwm_readl(sun20i_chip, PWM_CTL(pwm->hwpwm));
> +		clk_cfg = sun20i_pwm_readl(sun20i_chip, PWM_CLK_CFG(pwm->hwpwm));
> +		hosc_rate = clk_get_rate(sun20i_chip->clk_hosc);
> +		bus_rate = clk_get_rate(sun20i_chip->clk_apb0);
> +		if (pwm_en & PWM_ENABLE_EN(pwm->hwpwm ^ 1)) {
> +			/* if the neighbor channel is enable, check period only */
> +			use_bus_clk = FIELD_GET(PWM_CLK_CFG_SRC, clk_cfg) != 0;
> +			val = state->period * (use_bus_clk ? bus_rate : hosc_rate);

This can overflow.

> +			do_div(val, NSEC_PER_SEC);
> +
> +			div_m = FIELD_GET(PWM_CLK_CFG_DIV_M, clk_cfg);
> +		} else {
> +			/* check period and select clock source */
> +			use_bus_clk = false;
> +			val = state->period * hosc_rate;
> +			do_div(val, NSEC_PER_SEC);
> +			if (val <= 1) {
> +				use_bus_clk = true;
> +				val = state->period * bus_rate;
> +				do_div(val, NSEC_PER_SEC);
> +				if (val <= 1) {
> +					ret = -EINVAL;
> +					goto unlock_mutex;
> +				}
> +			}
> +			div_m = fls(DIV_ROUND_DOWN_ULL(val, PWM_MAGIC));
> +			if (div_m >= 9) {

What is 9 here? Something like DIV_M_MAX? There are a few other
constants that might deserve a name.

> +				ret = -EINVAL;
> +				goto unlock_mutex;
> +			}
> +
> +			/* set up the CLK_DIV_M and clock CLK_SRC */
> +			clk_cfg = FIELD_PREP(PWM_CLK_CFG_DIV_M, div_m);
> +			clk_cfg |= FIELD_PREP(PWM_CLK_CFG_SRC, use_bus_clk);
> +
> +			sun20i_pwm_writel(sun20i_chip, clk_cfg, PWM_CLK_CFG(pwm->hwpwm));
> +		}
> +
> +		/* calculate prescaler, PWM entire cycle */
> +		clk_div = val >> div_m;
> +		if (clk_div <= 65534) {
> +			prescaler = 0;
> +		} else {
> +			prescaler = DIV_ROUND_UP_ULL(clk_div - 65534, 65535);

This looks strange. The result is the same as
DIV_ROUND_DOWN_ULL(clk_div, 65535) which by the way also does the right
thing for clk_div <= 65534.

> +			if (prescaler >= 256) {
> +				ret = -EINVAL;
> +				goto unlock_mutex;

If this happens the requested period is too big, right? Please use

	prescaler = 255;

then and proceed. (The idea is to configure the biggest period that is
not bigger than the requested period.)

> +			}
> +			do_div(clk_div, prescaler + 1);
> +		}
> +
> +		period = FIELD_PREP(PWM_PERIOD_ENTIRE_CYCLE, clk_div);
> +
> +		/* set duty cycle */
> +		val = state->duty_cycle * (use_bus_clk ? bus_rate : hosc_rate);
> +		do_div(val, NSEC_PER_SEC);
> +		clk_div = val >> div_m;
> +		do_div(clk_div, prescaler + 1);
> +
> +		/*
> +		 * The formula of the output period and the duty-cycle for PWM are as follows.
> +		 * T period = (PWM01_CLK / PWM0_PRESCALE_K)^-1 * (PPR0.PWM_ENTIRE_CYCLE + 1)
> +		 * T high-level = (PWM01_CLK / PWM0_PRESCALE_K)^-1 * PPR0.PWM_ACT_CYCLE
> +		 * Duty-cycle = T high-level / T period
> +		 * In accordance with this formula, in order to set the duty-cycle to 100%,
> +		 * it is necessary that PWM_ACT_CYCLE >= PWM_ENTIRE_CYCLE + 1
> +		 */
> +		if (state->duty_cycle == state->period)
> +			clk_div++;

Can it happen, that clk_div gets too big here?

> +		period |= FIELD_PREP(PWM_PERIOD_ACT_CYCLE, clk_div);

It's a bit irritating (to me at least) that the variable "period" holds
the configuration for the duty_cycle. Maybe call it "reg_period" or
similar to not confuse it with state->period?

> +		sun20i_pwm_writel(sun20i_chip, period, PWM_PERIOD(pwm->hwpwm));
> +
> +		ctl = FIELD_PREP(PWM_CTL_PRESCAL_K, prescaler);
> +		if (state->polarity == PWM_POLARITY_NORMAL)
> +			ctl |= PWM_CTL_ACT_STA;
> +
> +		sun20i_pwm_writel(sun20i_chip, ctl, PWM_CTL(pwm->hwpwm));

Is there a glitch if you switch polarity? i.e. after period is written a
few lines above, a new period starts already and if you then invert
PWM_CTL_ACT_STA, the output immediately switches polarity? If so that's
something to mention in the Limitations section.

> +	}
> +[...]
> +static int sun20i_pwm_probe(struct platform_device *pdev)
> +{
> +	struct sun20i_pwm_chip *sun20i_chip;
> +	int ret;
> +
> +	sun20i_chip = devm_kzalloc(&pdev->dev, sizeof(*sun20i_chip), GFP_KERNEL);
> +	if (!sun20i_chip)
> +		return -ENOMEM;
> +
> +	sun20i_chip->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(sun20i_chip->base))
> +		return PTR_ERR(sun20i_chip->base);
> +
> +	sun20i_chip->clk_bus = devm_clk_get_enabled(&pdev->dev, "bus");
> +	if (IS_ERR(sun20i_chip->clk_bus))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_bus),
> +				     "failed to get bus clock\n");
> +
> +	sun20i_chip->clk_hosc = devm_clk_get_enabled(&pdev->dev, "hosc");
> +	if (IS_ERR(sun20i_chip->clk_hosc))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_hosc),
> +				     "failed to get hosc clock\n");
> +
> +	sun20i_chip->clk_apb0 = devm_clk_get_enabled(&pdev->dev, "apb0");
> +	if (IS_ERR(sun20i_chip->clk_apb0))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->clk_apb0),
> +				     "failed to get apb0 clock\n");
> +
> +	sun20i_chip->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +	if (IS_ERR(sun20i_chip->rst))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(sun20i_chip->rst),
> +				     "failed to get bus reset\n");
> +
> +	ret = of_property_read_u32(pdev->dev.of_node, "allwinner,pwm-channels",
> +				   &sun20i_chip->chip.npwm);
> +	if (ret)
> +		sun20i_chip->chip.npwm = 8;

The register layout allows npwm <= 16 only, right? I suggest to add a
check for that.

> +	/* Deassert reset */
> +	ret = reset_control_deassert(sun20i_chip->rst);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "failed to deassert reset\n");

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists