Re: [PATCH v8 2/2] pwm: add support for NXPs high-side switch MC33XS2410

From: Uwe Kleine-König
Date: Wed Mar 19 2025 - 11:45:12 EST

Next message: Miguel Ojeda: "Re: [PATCH] rust: adds bindings for bitmap.c and bitops.c"
Previous message: Ian Rogers: "Re: [PATCH] libperf: Don't remove -g when EXTRA_CFLAGS are used"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello Dimitri,

On Fri, Jan 10, 2025 at 08:37:55AM +0100, Dimitri Fedrau wrote:
> The MC33XS2410 is a four channel high-side switch. Featuring advanced
> monitoring and control function, the device is operational from 3.0 V to
> 60 V. The device is controlled by SPI port for configuration.
>
> Signed-off-by: Dimitri Fedrau <dima.fedrau@xxxxxxxxx>
> ---
> drivers/pwm/Kconfig | 12 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-mc33xs2410.c | 378 +++++++++++++++++++++++++++++++++++
> 3 files changed, 391 insertions(+)
> create mode 100644 drivers/pwm/pwm-mc33xs2410.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 0915c1e7df16..f513513f9b2f 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -411,6 +411,18 @@ config PWM_LPSS_PLATFORM
> To compile this driver as a module, choose M here: the module
> will be called pwm-lpss-platform.
>
> +config PWM_MC33XS2410
> + tristate "MC33XS2410 PWM support"
> + depends on OF
> + depends on SPI
> + help
> + NXP MC33XS2410 high-side switch driver. The MC33XS2410 is a four
> + channel high-side switch. The device is operational from 3.0 V
> + to 60 V. The device is controlled by SPI port for configuration.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-mc33xs2410.
> +
> config PWM_MESON
> tristate "Amlogic Meson PWM driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 9081e0c0e9e0..c75deeeace40 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
> obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
> obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
> obj-$(CONFIG_PWM_LPSS_PLATFORM) += pwm-lpss-platform.o
> +obj-$(CONFIG_PWM_MC33XS2410) += pwm-mc33xs2410.o
> obj-$(CONFIG_PWM_MESON) += pwm-meson.o
> obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
> obj-$(CONFIG_PWM_MICROCHIP_CORE) += pwm-microchip-core.o
> diff --git a/drivers/pwm/pwm-mc33xs2410.c b/drivers/pwm/pwm-mc33xs2410.c
> new file mode 100644
> index 000000000000..432693b4f8eb
> --- /dev/null
> +++ b/drivers/pwm/pwm-mc33xs2410.c
> @@ -0,0 +1,378 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2024 Liebherr-Electronics and Drives GmbH
> + *
> + * Reference Manual : https://www.nxp.com/docs/en/data-sheet/MC33XS2410.pdf
> + *
> + * Limitations:
> + * - Supports frequencies between 0.5Hz and 2048Hz with following steps:
> + * - 0.5 Hz steps from 0.5 Hz to 32 Hz
> + * - 2 Hz steps from 2 Hz to 128 Hz
> + * - 8 Hz steps from 8 Hz to 512 Hz
> + * - 32 Hz steps from 32 Hz to 2048 Hz
> + * - Cannot generate a 0 % duty cycle.
> + * - Always produces low output if disabled.
> + * - Configuration isn't atomic. When changing polarity, duty cycle or period
> + * the data is taken immediately, counters not being affected, resulting in a
> + * behavior of the output pin that is neither the old nor the new state,
> + * rather something in between.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/math64.h>
> +#include <linux/minmax.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pwm.h>
> +
> +#include <linux/spi/spi.h>
> +
> +#define MC33XS2410_GLB_CTRL 0x00
> +#define MC33XS2410_GLB_CTRL_MODE GENMASK(7, 6)
> +#define MC33XS2410_GLB_CTRL_MODE_NORMAL FIELD_PREP(MC33XS2410_GLB_CTRL_MODE, 1)
> +
> +#define MC33XS2410_PWM_CTRL1 0x05
> +/* x in { 1 ... 4 } */

s/x/chan/

> +#define MC33XS2410_PWM_CTRL1_POL_INV(chan) BIT((chan) + 1)
> +
> +#define MC33XS2410_PWM_CTRL3 0x07
> +/* x in { 1 ... 4 } */
> +#define MC33XS2410_PWM_CTRL3_EN(chan) BIT(4 + (chan) - 1)
> +
> +/* x in { 1 ... 4 } */
> +#define MC33XS2410_PWM_FREQ(chan) (0x08 + (chan) - 1)
> +#define MC33XS2410_PWM_FREQ_STEP GENMASK(7, 6)
> +#define MC33XS2410_PWM_FREQ_COUNT GENMASK(5, 0)
> +
> +/* x in { 1 ... 4 } */
> +#define MC33XS2410_PWM_DC(chan) (0x0c + (chan) - 1)
> +
> +#define MC33XS2410_WDT 0x14
> +
> +#define MC33XS2410_PWM_MIN_PERIOD 488282
> +/* x in { 0 ... 3 } */

s/x/step/

> +#define MC33XS2410_PWM_MAX_PERIOD(step) (2000000000 >> (2 * (step)))
> +
> +#define MC33XS2410_FRAME_IN_ADDR GENMASK(15, 8)
> +#define MC33XS2410_FRAME_IN_DATA GENMASK(7, 0)
> +#define MC33XS2410_FRAME_IN_ADDR_WR BIT(7)
> +#define MC33XS2410_FRAME_IN_DATA_RD BIT(7)
> +#define MC33XS2410_FRAME_OUT_DATA GENMASK(13, 0)
> +
> +#define MC33XS2410_MAX_TRANSFERS 5
> +
> +static int mc33xs2410_write_regs(struct spi_device *spi, u8 *reg, u8 *val,
> + unsigned int len)
> +{
> + u16 tx[MC33XS2410_MAX_TRANSFERS];
> + int i;
> +
> + if (len > MC33XS2410_MAX_TRANSFERS)
> + return -EINVAL;
> +
> + for (i = 0; i < len; i++)
> + tx[i] = FIELD_PREP(MC33XS2410_FRAME_IN_DATA, val[i]) |
> + FIELD_PREP(MC33XS2410_FRAME_IN_ADDR,
> + MC33XS2410_FRAME_IN_ADDR_WR | reg[i]);
> +
> + return spi_write(spi, tx, len * 2);
> +}
> +
> +static int mc33xs2410_read_regs(struct spi_device *spi, u8 *reg, u8 flag,
> + u16 *val, unsigned int len)
> +{
> + u16 tx[MC33XS2410_MAX_TRANSFERS];
> + u16 rx[MC33XS2410_MAX_TRANSFERS];
> + struct spi_transfer t = {
> + .tx_buf = tx,
> + .rx_buf = rx,
> + };
> + int i, ret;
> +
> + len++;
> + if (len > MC33XS2410_MAX_TRANSFERS)
> + return -EINVAL;
> +
> + t.len = len * 2;
> + for (i = 0; i < len - 1; i++)
> + tx[i] = FIELD_PREP(MC33XS2410_FRAME_IN_DATA, flag) |
> + FIELD_PREP(MC33XS2410_FRAME_IN_ADDR, reg[i]);
> +
> + ret = spi_sync_transfer(spi, &t, 1);
> + if (ret < 0)
> + return ret;
> +
> + for (i = 1; i < len; i++)
> + val[i - 1] = FIELD_GET(MC33XS2410_FRAME_OUT_DATA, rx[i]);
> +
> + return 0;
> +}
> +
> +static int mc33xs2410_write_reg(struct spi_device *spi, u8 reg, u8 val)
> +{
> + return mc33xs2410_write_regs(spi, &reg, &val, 1);
> +}
> +
> +static int mc33xs2410_read_reg(struct spi_device *spi, u8 reg, u16 *val, u8 flag)
> +{
> + return mc33xs2410_read_regs(spi, &reg, flag, val, 1);
> +}
> +
> +static int mc33xs2410_read_reg_ctrl(struct spi_device *spi, u8 reg, u16 *val)
> +{
> + return mc33xs2410_read_reg(spi, reg, val, MC33XS2410_FRAME_IN_DATA_RD);
> +}
> +
> +static int mc33xs2410_modify_reg(struct spi_device *spi, u8 reg, u8 mask, u8 val)
> +{
> + u16 tmp;
> + int ret;
> +
> + ret = mc33xs2410_read_reg_ctrl(spi, reg, &tmp);
> + if (ret < 0)
> + return ret;
> +
> + tmp &= ~mask;
> + tmp |= val & mask;
> +
> + return mc33xs2410_write_reg(spi, reg, tmp);
> +}
> +
> +static u8 mc33xs2410_pwm_get_freq(u64 period)
> +{
> + u8 step, count;
> +
> + /*
> + * Check which step is appropriate for the given period, starting with
> + * the highest frequency(lowest period). Higher frequencies are
> + * represented with better resolution by the device. Therefore favor
> + * frequency range with the better resolution to minimize error
> + * introduced by the frequency steps.

This is hard to understand as the argument is presented in several
steps:
algo starts with high step values (that's not in the comment,
you have to take that from the switch statement)
high step represents high freq = low period
high freq yield better resolution
better resolution is what is favoured.

After investing some time to reunderstand the rational here
I suggest:

/*
* Check which step [0 .. 3] is appropriate for the given
* period. The period ranges for the different step values
* overlap. Prefer big step values as these allow more
* finegrained duty cycle selection.
*/

> + */
> +
> + switch (period) {
> + case MC33XS2410_PWM_MIN_PERIOD ... MC33XS2410_PWM_MAX_PERIOD(3):
> + step = 3;
> + break;
> + case MC33XS2410_PWM_MAX_PERIOD(3) + 1 ... MC33XS2410_PWM_MAX_PERIOD(2):
> + step = 2;
> + break;
> + case MC33XS2410_PWM_MAX_PERIOD(2) + 1 ... MC33XS2410_PWM_MAX_PERIOD(1):
> + step = 1;
> + break;
> + case MC33XS2410_PWM_MAX_PERIOD(1) + 1 ... MC33XS2410_PWM_MAX_PERIOD(0):
> + step = 0;
> + break;
> + }
> +
> + /*
> + * Round up here because a higher count results in a higher frequency
> + * and so a smaller period.
> + */
> + count = DIV_ROUND_UP((u32)MC33XS2410_PWM_MAX_PERIOD(step), (u32)period);
> + return FIELD_PREP(MC33XS2410_PWM_FREQ_STEP, step) |
> + FIELD_PREP(MC33XS2410_PWM_FREQ_COUNT, count - 1);
> +}
> +
> +static u64 mc33xs2410_pwm_get_period(u8 reg)
> +{
> + u32 freq, code, doubled_steps;
> +
> + /*
> + * steps:
> + * - 0 = 0.5Hz
> + * - 1 = 2Hz
> + * - 2 = 8Hz
> + * - 3 = 32Hz
> + * frequency = (code + 1) x steps.
> + *
> + * To avoid losing precision in case steps value is zero, scale the
> + * steps value for now by two and keep it in mind when calculating the
> + * period that the frequency had been doubled.
> + */
> + doubled_steps = 1 << (FIELD_GET(MC33XS2410_PWM_FREQ_STEP, reg) * 2);
> + code = FIELD_GET(MC33XS2410_PWM_FREQ_COUNT, reg);
> + freq = (code + 1) * doubled_steps;

doubled_freq?

> + /* Convert frequency to period, considering the doubled frequency. */
> + return DIV_ROUND_UP(2 * NSEC_PER_SEC, freq);
> +}
> +
> +static int mc33xs2410_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct spi_device *spi = pwmchip_get_drvdata(chip);
> + u8 reg[4] = {
> + MC33XS2410_PWM_FREQ(pwm->hwpwm + 1),
> + MC33XS2410_PWM_DC(pwm->hwpwm + 1),
> + MC33XS2410_PWM_CTRL1,
> + MC33XS2410_PWM_CTRL3
> + };
> + u64 period, duty_cycle;
> + int ret, rel_dc;
> + u16 rd_val[2];
> + u8 wr_val[4];
> + u8 mask;
> +
> + period = min(state->period, MC33XS2410_PWM_MAX_PERIOD(0));
> + if (period < MC33XS2410_PWM_MIN_PERIOD)
> + return -EINVAL;
> +
> + ret = mc33xs2410_read_regs(spi, &reg[2], MC33XS2410_FRAME_IN_DATA_RD, rd_val, 2);
> + if (ret < 0)
> + return ret;
> +
> + /* frequency */
> + wr_val[0] = mc33xs2410_pwm_get_freq(period);
> + /* Continue calculations with the possibly truncated period */
> + period = mc33xs2410_pwm_get_period(wr_val[0]);
> +
> + /* duty cycle */
> + duty_cycle = min(period, state->duty_cycle);
> + rel_dc = div64_u64(duty_cycle * 256, period) - 1;
> + if (rel_dc < 0)
> + wr_val[1] = 0;
> + else
> + wr_val[1] = rel_dc;
> +
> + /* polarity */
> + mask = MC33XS2410_PWM_CTRL1_POL_INV(pwm->hwpwm + 1);
> + wr_val[2] = (state->polarity == PWM_POLARITY_INVERSED) ?
> + (rd_val[0] | mask) : (rd_val[0] & ~mask);
> +
> + /*
> + * As the hardware cannot generate a 0% relative duty cycle but emits a
> + * constant low signal when disabled, also disable in the duty_cycle = 0
> + * case.
> + */
> + mask = MC33XS2410_PWM_CTRL3_EN(pwm->hwpwm + 1);
> + wr_val[3] = (state->enabled && rel_dc >= 0) ? (rd_val[1] | mask) :
> + (rd_val[1] & ~mask);

This is wrong for inversed polarity I think.

> + return mc33xs2410_write_regs(spi, reg, wr_val, 4);
> +}
> +
> [..]
> +static int mc33xs2410_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct pwm_chip *chip;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, 4, 0);
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + spi->bits_per_word = 16;
> + spi->mode |= SPI_CS_WORD;
> + ret = spi_setup(spi);
> + if (ret < 0)
> + return ret;
> +
> + pwmchip_set_drvdata(chip, spi);
> + chip->ops = &mc33xs2410_pwm_ops;
> + ret = mc33xs2410_reset(dev);

What does this reset? Does it change the output signal if the bootloader
already setup the hardware? The answer to that has to go into a comment.
(And if it interupts the output, better skip the reset part.)

> + if (ret)
> + return ret;

Best regards
Uwe

Attachment: signature.asc
Description: PGP signature

Next message: Miguel Ojeda: "Re: [PATCH] rust: adds bindings for bitmap.c and bitops.c"
Previous message: Ian Rogers: "Re: [PATCH] libperf: Don't remove -g when EXTRA_CFLAGS are used"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]