[PATCH 1/2] pwm: add microchip soft ip corePWM driver
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Tue Jun 7 13:07:55 PDT 2022
Hello,
On Tue, Jun 07, 2022 at 09:45:51AM +0100, Conor Dooley wrote:
> Add a driver that supports the Microchip FPGA "soft" PWM IP core.
>
> Signed-off-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> drivers/pwm/Kconfig | 10 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-microchip-core.c | 289 +++++++++++++++++++++++++++++++
> 3 files changed, 300 insertions(+)
> create mode 100644 drivers/pwm/pwm-microchip-core.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 21e3b05a5153..a651848e444b 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -383,6 +383,16 @@ config PWM_MEDIATEK
> To compile this driver as a module, choose M here: the module
> will be called pwm-mediatek.
>
> +config PWM_MICROCHIP_CORE
> + tristate "Microchip corePWM PWM support"
> + depends on SOC_MICROCHIP_POLARFIRE || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + help
> + PWM driver for Microchip FPGA soft IP core.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-microchip-core.
> +
> config PWM_MXS
> tristate "Freescale MXS PWM support"
> depends on ARCH_MXS || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 708840b7fba8..d29754c20f91 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
> obj-$(CONFIG_PWM_LPSS_PLATFORM) += pwm-lpss-platform.o
> obj-$(CONFIG_PWM_MESON) += pwm-meson.o
> obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
> +obj-$(CONFIG_PWM_MICROCHIP_CORE) += pwm-microchip-core.o
> obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
> obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
> obj-$(CONFIG_PWM_NTXEC) += pwm-ntxec.o
> diff --git a/drivers/pwm/pwm-microchip-core.c b/drivers/pwm/pwm-microchip-core.c
> new file mode 100644
> index 000000000000..2cc1de163bcc
> --- /dev/null
> +++ b/drivers/pwm/pwm-microchip-core.c
> @@ -0,0 +1,289 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * corePWM driver for Microchip FPGAs
> + *
> + * Copyright (c) 2021-2022 Microchip Corporation. All rights reserved.
> + * Author: Conor Dooley <conor.dooley at microchip.com>
> + *
Is there a public datasheet for that hardware? If yes, please add a link
here.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/math.h>
> +
> +#define PREG_TO_VAL(PREG) ((PREG) + 1)
> +
> +#define PRESCALE_REG 0x00u
> +#define PERIOD_REG 0x04u
> +#define PWM_EN_LOW_REG 0x08u
> +#define PWM_EN_HIGH_REG 0x0Cu
> +#define SYNC_UPD_REG 0xE4u
> +#define POSEDGE_OFFSET 0x10u
> +#define NEGEDGE_OFFSET 0x14u
> +#define CHANNEL_OFFSET 0x08u
Can you please prefix these register symbols with a driver prefix?
Unique register names are good for tools like ctags and then it's
obvious to the reader, that the defines are driver specific.
> +struct mchp_core_pwm_registers {
> + u8 posedge;
> + u8 negedge;
> + u8 period_steps;
> + u8 prescale;
these are the four registers for each channel, right? Can you add a
short overview how these registers define the resulting output wave.
> +};
> +
> +struct mchp_core_pwm_chip {
> + struct pwm_chip chip;
> + struct clk *clk;
> + void __iomem *base;
> + struct mchp_core_pwm_registers *regs;
> +};
> +
> +static inline struct mchp_core_pwm_chip *to_mchp_core_pwm(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct mchp_core_pwm_chip, chip);
> +}
> +
> +static void mchp_core_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm,
> + bool enable)
> +{
> + struct mchp_core_pwm_chip *mchp_core_pwm = to_mchp_core_pwm(chip);
> + u8 channel_enable, reg_offset, shift;
> +
> + /*
> + * There are two adjacent 8 bit control regs, the lower reg controls
> + * 0-7 and the upper reg 8-15. Check if the pwm is in the upper reg
> + * and if so, offset by the bus width.
> + */
> + reg_offset = PWM_EN_LOW_REG + (pwm->hwpwm >> 3) * sizeof(u32);
> + shift = pwm->hwpwm > 7 ? pwm->hwpwm - 8 : pwm->hwpwm;
> +
> + channel_enable = readb_relaxed(mchp_core_pwm->base + reg_offset);
> + channel_enable &= ~(1 << shift);
> + channel_enable |= (enable << shift);
> +
> + writel_relaxed(channel_enable, mchp_core_pwm->base + reg_offset);
> +}
> +
> +static void mchp_core_pwm_calculate_duty(struct pwm_chip *chip,
> + const struct pwm_state *desired_state,
> + struct mchp_core_pwm_registers *regs)
> +{
> + struct mchp_core_pwm_chip *mchp_core_pwm = to_mchp_core_pwm(chip);
> + u64 clk_period = NSEC_PER_SEC;
> + u64 duty_steps;
> +
> + /* Calculate the clk period and then the duty cycle edges */
> + do_div(clk_period, clk_get_rate(mchp_core_pwm->clk));
> +
> + duty_steps = desired_state->duty_cycle * PREG_TO_VAL(regs->period_steps);
> + do_div(duty_steps, (clk_period * PREG_TO_VAL(regs->period_steps)));
Don't divide by a result of a division.
> + if (desired_state->polarity == PWM_POLARITY_INVERSED) {
> + regs->negedge = 0u;
> + regs->posedge = duty_steps;
> + } else {
> + regs->posedge = 0u;
> + regs->negedge = duty_steps;
> + }
> +}
> +
> +static void mchp_core_pwm_apply_duty(const u8 channel,
> + struct mchp_core_pwm_chip *pwm_chip,
> + struct mchp_core_pwm_registers *regs)
> +{
> + void __iomem *channel_base = pwm_chip->base + channel * CHANNEL_OFFSET;
> +
> + writel_relaxed(regs->posedge, channel_base + POSEDGE_OFFSET);
> + writel_relaxed(regs->negedge, channel_base + NEGEDGE_OFFSET);
> +}
> +
> +static void mchp_core_pwm_apply_period(struct mchp_core_pwm_chip *pwm_chip,
> + struct mchp_core_pwm_registers *regs)
> +{
> + writel_relaxed(regs->prescale, pwm_chip->base + PRESCALE_REG);
> + writel_relaxed(regs->period_steps, pwm_chip->base + PERIOD_REG);
> +}
> +
> +static int mchp_core_pwm_calculate_base(struct pwm_chip *chip,
> + const struct pwm_state *desired_state,
> + u8 *period_steps_r, u8 *prescale_r)
> +{
> + struct mchp_core_pwm_chip *mchp_core_pwm = to_mchp_core_pwm(chip);
> + u64 tmp = desired_state->period;
> +
> + /* Calculate the period cycles and prescale value */
> + tmp *= clk_get_rate(mchp_core_pwm->clk);
> + do_div(tmp, NSEC_PER_SEC);
> +
> + if (tmp > 65535) {
If a too long period is requested, please configure the biggest possible
period.
> + dev_err(chip->dev,
> + "requested prescale exceeds the maximum possible\n");
No error message in .apply() please.
> + return -EINVAL;
> + } else if (tmp <= 256) {
> + *prescale_r = 0;
> + *period_steps_r = tmp - 1;
> + } else {
> + *prescale_r = fls(tmp) - 8;
> + *period_steps_r = (tmp >> *prescale_r) - 1;
> + }
*prescale_r = fls(tmp >> 8);
*period_steps_r = (tmp >> *prescale_r) - 1;
can be used in both branches with the same result.
> +
> + return 0;
> +}
> +
> +static int mchp_core_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *desired_state)
please s/desired_state/state/ for consistency with other drivers.
> +{
> + struct mchp_core_pwm_chip *mchp_core_pwm = to_mchp_core_pwm(chip);
> + struct pwm_state current_state;
> + u8 period_steps_r, prescale_r;
> + int ret;
> + u8 channel = pwm->hwpwm;
> +
> + pwm_get_state(pwm, ¤t_state);
Please don't call pwm API functions in a PWM driver. Simply use
pwm->state for the previously applied state.
> + if (desired_state->enabled) {
> + if (current_state.enabled &&
> + current_state.period == desired_state->period &&
> + current_state.polarity == desired_state->polarity) {
If everything is as before, why are you doing something at all?
> + mchp_core_pwm_calculate_duty(chip, desired_state, mchp_core_pwm->regs);
> + mchp_core_pwm_apply_duty(channel, mchp_core_pwm, mchp_core_pwm->regs);
> + } else {
> + ret = mchp_core_pwm_calculate_base(chip, desired_state, &period_steps_r,
> + &prescale_r);
> + if (ret) {
> + dev_err(chip->dev, "failed to calculate base\n");
mchp_core_pwm_calculate_base might already emit an error message. Apply
shouldn't emit an error message at all.
> + return ret;
> + }
> +
> + mchp_core_pwm->regs->period_steps = period_steps_r;
> + mchp_core_pwm->regs->prescale = prescale_r;
> +
> + mchp_core_pwm_calculate_duty(chip, desired_state, mchp_core_pwm->regs);
> + mchp_core_pwm_apply_duty(channel, mchp_core_pwm, mchp_core_pwm->regs);
> + mchp_core_pwm_apply_period(mchp_core_pwm, mchp_core_pwm->regs);
Is there a race where e.g. the output is defined by the previous period
and the new duty_cycle?
> + }
> +
> + if (mchp_core_pwm->regs->posedge == mchp_core_pwm->regs->negedge)
> + mchp_core_pwm_enable(chip, pwm, false);
> + else
> + mchp_core_pwm_enable(chip, pwm, true);
Here is a race: If the PWM is running and it configured to be disabled
with a different duty_cycle/period the duty_cycle/period might be
(shortly) visible on the output with is undesirable.
> + } else if (!desired_state->enabled) {
This can be simplified to just "} else {"
> + mchp_core_pwm_enable(chip, pwm, false);
> + }
> +
> + return 0;
I think this can be considerably simplified by unrolling the helper
functions.
> +}
> +
> +static void mchp_core_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct mchp_core_pwm_chip *mchp_core_pwm = to_mchp_core_pwm(chip);
> + void __iomem *channel_base = mchp_core_pwm->base + pwm->hwpwm * CHANNEL_OFFSET;
> + u64 clk_period = NSEC_PER_SEC;
> + u8 prescale, period_steps, duty_steps;
> + u8 posedge, negedge;
> + u16 channel_enabled;
> +
> + channel_enabled = (((u16)readb_relaxed(mchp_core_pwm->base + PWM_EN_HIGH_REG) << 8) |
> + readb_relaxed(mchp_core_pwm->base + PWM_EN_LOW_REG));
> +
> + posedge = readb_relaxed(channel_base + POSEDGE_OFFSET);
> + negedge = readb_relaxed(channel_base + NEGEDGE_OFFSET);
> +
> + duty_steps = abs((s8)posedge - (s8)negedge);
> + state->polarity = negedge < posedge ? PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
> +
> + prescale = readb_relaxed(mchp_core_pwm->base + PRESCALE_REG);
> + period_steps = readb_relaxed(mchp_core_pwm->base + PERIOD_REG);
> +
> + do_div(clk_period, clk_get_rate(mchp_core_pwm->clk));
> + state->duty_cycle = PREG_TO_VAL(prescale) * clk_period * duty_steps;
Dividing early results in rounding errors.
> + state->period = PREG_TO_VAL(prescale) * clk_period * PREG_TO_VAL(period_steps);
> +
> + if (channel_enabled & 1 << pwm->hwpwm)
> + state->enabled = true;
> + else
> + state->enabled = false;
> +}
Have you tested your driver with PWM_DEBUG enabled? The rounding is
wrong here. (The supposed rounding behaviour is that .apply rounds down
and to make .apply(.getstate()) a noop, .get_state() must round up.
If you do something like:
echo 0 > duty_cycle
for i in $(seq 10000 -1 1); do
echo $i > period
done
for i in $(seq 1 10000); do
echo $i > period
done
for i in $(seq 10000 -1 1); do
echo $i > duty_cycle
done
for i in $(seq 1 10000); do
echo $i > duty_cycle
done
with PWM_DEBUG enabled, you should catch most rounding errors. (Maybe
adapt the boundaries according to your driver's capabilities.)
> +static const struct pwm_ops mchp_core_pwm_ops = {
> + .apply = mchp_core_pwm_apply,
> + .get_state = mchp_core_pwm_get_state,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct of_device_id mchp_core_of_match[] = {
> + {
> + .compatible = "microchip,corepwm-rtl-v4",
> + },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mchp_core_of_match);
> +
> +static int mchp_core_pwm_probe(struct platform_device *pdev)
> +{
> + struct mchp_core_pwm_chip *mchp_pwm;
> + struct resource *regs;
> + int ret;
> +
> + mchp_pwm = devm_kzalloc(&pdev->dev, sizeof(*mchp_pwm), GFP_KERNEL);
> + if (!mchp_pwm)
> + return -ENOMEM;
> +
> + mchp_pwm->regs = devm_kzalloc(&pdev->dev, sizeof(*regs), GFP_KERNEL);
> + if (!mchp_pwm->regs)
> + return -ENOMEM;
If you make regs not a pointer but embed the structure directly in
struct mchp_core_pwm_chip, you only need a single allocation. Having
said that I wonder if you need to store this in driver data at all.
> + mchp_pwm->base = devm_platform_get_and_ioremap_resource(pdev, 0, ®s);
> + if (IS_ERR(mchp_pwm->base))
> + return PTR_ERR(mchp_pwm->base);
> +
> + mchp_pwm->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(mchp_pwm->clk))
> + return PTR_ERR(mchp_pwm->clk);
> +
> + ret = clk_prepare(mchp_pwm->clk);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "failed to prepare PWM clock\n");
> +
> + mchp_pwm->chip.dev = &pdev->dev;
> + mchp_pwm->chip.ops = &mchp_core_pwm_ops;
> + mchp_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> + mchp_pwm->chip.of_pwm_n_cells = 3;
> + mchp_pwm->chip.base = -1;
Please drop the assignment to base.
> + mchp_pwm->chip.npwm = 16;
> +
> + ret = pwmchip_add(&mchp_pwm->chip);
> + if (ret < 0)
clk_unprepare missing here.
> + return dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n");
> +
> + writel_relaxed(0u, mchp_pwm->base + PWM_EN_LOW_REG);
> + writel_relaxed(0u, mchp_pwm->base + PWM_EN_HIGH_REG);
What is the effect here? Don't modify the hardware after pwmchip_add().
When that function returns a consumer might already have configured the
hardware.
> + platform_set_drvdata(pdev, mchp_pwm);
This is unused, please drop.
> + dev_info(&pdev->dev, "Successfully registered Microchip corePWM\n");
> +
> + return 0;
> +}
> +
> +static int mchp_core_pwm_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
Here you're missing to undo pwmchip_add and clk_prepare.
> +static struct platform_driver mchp_core_pwm_driver = {
> + .driver = {
> + .name = "mchp-core-pwm",
> + .of_match_table = mchp_core_of_match,
> + },
> + .probe = mchp_core_pwm_probe,
> + .remove = mchp_core_pwm_remove,
> +};
> +module_platform_driver(mchp_core_pwm_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Conor Dooley <conor.dooley at microchip.com>");
> +MODULE_DESCRIPTION("corePWM driver for Microchip FPGAs");
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20220607/4ff70870/attachment.sig>
More information about the linux-riscv
mailing list