Re: [PATCH 2/2] pwm: sophgo: add driver for SG2044

Uwe Kleine-König
2025-04-07T09:38:30Z

[-- Attachment #1: Type: text/plain, Size: 7807 bytes --]

On Mon, Apr 07, 2025 at 03:20:39PM +0800, Longbin Li wrote:
> From: ghost <2990955050@qq.com>

Huh, is that a real name?

> Add PWM controller for SG2044.
>
> Signed-off-by: Longbin Li <looong.bin@gmail.com>
> ---
> drivers/pwm/pwm-sophgo-sg2042.c | 162 +++++++++++++++++++++++++++-----
> 1 file changed, 138 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/pwm/pwm-sophgo-sg2042.c b/drivers/pwm/pwm-sophgo-sg2042.c
> index ff4639d849ce..c62e8c758d87 100644
> --- a/drivers/pwm/pwm-sophgo-sg2042.c
> +++ b/drivers/pwm/pwm-sophgo-sg2042.c

The Limitations paragraph needs updating. E.g. SG2044 seems to support
polarity while SG2042 doesn't.

> @@ -26,20 +26,22 @@
> #include <linux/pwm.h>
> #include <linux/reset.h>
>
> -/*
> - * Offset RegisterName
> - * 0x0000 HLPERIOD0
> - * 0x0004 PERIOD0
> - * 0x0008 HLPERIOD1
> - * 0x000C PERIOD1
> - * 0x0010 HLPERIOD2
> - * 0x0014 PERIOD2
> - * 0x0018 HLPERIOD3
> - * 0x001C PERIOD3
> - * Four groups and every group is composed of HLPERIOD & PERIOD
> - */
> -#define SG2042_PWM_HLPERIOD(chan) ((chan) * 8 + 0)
> -#define SG2042_PWM_PERIOD(chan) ((chan) * 8 + 4)
> +#define REG_HLPERIOD 0x0
> +#define REG_PERIOD 0x4
> +#define REG_GROUP 0x8

REG_GROUP belongs to a different category than REG_PERIOD. So please use
a different schema to name it (or drop it, see below).

> +#define REG_POLARITY 0x40
> +
> +#define REG_PWMSTART 0x44
> +#define REG_PWMUPDATE 0x4C
> +#define REG_SHIFTCOUNT 0x80
> +#define REG_SHIFTSTART 0x90

REG_SHIFTCOUNT and REG_SHIFTSTART are unused.

> +#define REG_PWM_OE 0xD0

Actually I liked the old prefix better. E.g. "REG_POLARITY" looks more
generic that it actually is.

> +
> +#define PWM_REG_NUM 0x80

This is unused?

> +
> +#define PWM_POLARITY_MASK(n) BIT(n)
> +#define PWM_HLPERIOD(chan) ((chan) * REG_GROUP + REG_HLPERIOD)
> +#define PWM_PERIOD(chan) ((chan) * REG_GROUP + REG_PERIOD)

((chan) * 8 + 0) is IMHO better. I guess this is subjective because at
least the *8 is repeated several times, but the advantage of not using a
define for 8 (and 0 and 4) is that by looking at

#define SG2042_PWM_HLPERIOD(chan) ((chan) * 8 + 0)

you immediatly see the offsets of the HLPERIOD register, while for

#define PWM_HLPERIOD(chan) ((chan) * REG_GROUP + REG_HLPERIOD)

you have to lookup two additional symbols.

Also PWM is a prefix that is too generic.

> #define SG2042_PWM_CHANNELNUM 4
>
> @@ -51,6 +53,12 @@
> struct sg2042_pwm_ddata {
> void __iomem *base;
> unsigned long clk_rate_hz;
> + struct mutex lock;

What does this lock protect? Note that there is a chip lock that is held
when .apply() is called, to serialize apply calls for a single chip. I
guess this can and should be dropped.

> +};
> +
> +struct sg2042_chip_data {
> + const struct pwm_ops ops;
> + bool atomic;
> };
>
> /*
> @@ -62,8 +70,8 @@ static void pwm_sg2042_config(struct sg2042_pwm_ddata *ddata, unsigned int chan,
> {
> void __iomem *base = ddata->base;
>
> - writel(period_ticks, base + SG2042_PWM_PERIOD(chan));
> - writel(hlperiod_ticks, base + SG2042_PWM_HLPERIOD(chan));
> + writel(period_ticks, base + PWM_PERIOD(chan));
> + writel(hlperiod_ticks, base + PWM_HLPERIOD(chan));

The register renaming adds really quite some noise that is actually
unrelated to this patch. If you really think the register defines need
renaming, do that in a separate patch (and justify it well).

> }
>
> static int pwm_sg2042_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> @@ -104,8 +112,8 @@ static int pwm_sg2042_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> u32 hlperiod_ticks;
> u32 period_ticks;
>
> - period_ticks = readl(ddata->base + SG2042_PWM_PERIOD(chan));
> - hlperiod_ticks = readl(ddata->base + SG2042_PWM_HLPERIOD(chan));
> + period_ticks = readl(ddata->base + PWM_PERIOD(chan));
> + hlperiod_ticks = readl(ddata->base + PWM_HLPERIOD(chan));
>
> if (!period_ticks) {
> state->enabled = false;
> @@ -123,13 +131,112 @@ static int pwm_sg2042_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> return 0;
> }
>
> -static const struct pwm_ops pwm_sg2042_ops = {
> - .apply = pwm_sg2042_apply,
> - .get_state = pwm_sg2042_get_state,
> +static void pwm_sg2044_config(struct sg2042_pwm_ddata *ddata, struct pwm_device *pwm, bool enabled)
> +{
> + u32 pwm_value;
> +
> + pwm_value = readl(ddata->base + REG_PWMSTART);
> +
> + if (enabled)
> + writel(pwm_value | BIT(pwm->hwpwm), ddata->base + REG_PWMSTART);
> + else
> + writel(pwm_value & ~BIT(pwm->hwpwm), ddata->base + REG_PWMSTART);
> +}
> +
> +static void pwm_sg2044_set_outputenable(struct sg2042_pwm_ddata *ddata, struct pwm_device *pwm,
> + bool enabled)
> +{
> + u32 pwm_value;
> +
> + pwm_value = readl(ddata->base + REG_PWM_OE);
> +
> + if (enabled)
> + writel(pwm_value | BIT(pwm->hwpwm), ddata->base + REG_PWM_OE);
> + else
> + writel(pwm_value & ~BIT(pwm->hwpwm), ddata->base + REG_PWM_OE);
> +}
> +
> +static int pwm_sg2044_set_polarity(struct sg2042_pwm_ddata *ddata, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + enum pwm_polarity polarity;
> + u32 pwm_value;
> +
> + pwm_value = readl(ddata->base + REG_POLARITY);
> +
> + polarity = state->polarity;
> +
> + if (polarity == PWM_POLARITY_NORMAL)
> + pwm_value &= ~BIT(pwm->hwpwm);
> + else
> + pwm_value |= BIT(pwm->hwpwm);
> +
> + writel(pwm_value, ddata->base + REG_POLARITY);

I like this idiom better than the one used in
pwm_sg2044_set_outputenable() and pwm_sg2044_config(). However drop the
local variable polarity.

> + return 0;
> +}
> +
> +static int pwm_sg2044_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct sg2042_pwm_ddata *ddata = pwmchip_get_drvdata(chip);
> + u32 hlperiod_ticks;
> + u32 period_ticks;
> +
> + if (!state->enabled) {
> + pwm_sg2044_config(ddata, pwm, false);
> + return 0;
> + }
> +
> + pwm_sg2044_set_polarity(ddata, pwm, state);
> +
> + /*
> + * Duration of High level (duty_cycle) = HLPERIOD x Period_of_input_clk
> + * Duration of One Cycle (period) = PERIOD x Period_of_input_clk
> + */
> + period_ticks = min(mul_u64_u64_div_u64(ddata->clk_rate_hz, state->period,
> + NSEC_PER_SEC), U32_MAX);
> + hlperiod_ticks = min(mul_u64_u64_div_u64(ddata->clk_rate_hz, state->duty_cycle,
> + NSEC_PER_SEC), U32_MAX);

This is the same calculation as for sg2042. I think I'd put that in a
function that is used by both variants.

> + dev_dbg(pwmchip_parent(chip), "chan[%u]: PERIOD=%u, HLPERIOD=%u\n",
> + pwm->hwpwm, period_ticks, hlperiod_ticks);

Now that there are more register values, please add them all to the
debug output.

> + pwm_sg2042_config(ddata, pwm->hwpwm, period_ticks, hlperiod_ticks);
> +
> + guard(mutex)(&ddata->lock);
> +
> + /*
> + * re-enable PWMSTART to refresh the register period
> + */
> + pwm_sg2044_config(ddata, pwm, false);

pwm_sg2044_config() is conceptually different to pwm_sg2042_config().
This is irritating, so please find a better name.

> + pwm_sg2044_set_outputenable(ddata, pwm, true);
> + pwm_sg2044_config(ddata, pwm, true);
> +
> + return 0;
> +}
> +
> +static const struct sg2042_chip_data sg2042_chip_data = {
> + .ops = {
> + .apply = pwm_sg2042_apply,
> + .get_state = pwm_sg2042_get_state,
> + },
> + .atomic = true,
> +};
> +
> +static const struct sg2042_chip_data sg2044_chip_data = {
> + .ops = {
> + .apply = pwm_sg2044_apply,
> + .get_state = pwm_sg2042_get_state,
> + },
> + .atomic = false,

If you drop the mutex don't forget to drop this one, too.

> };

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]