Re: [PATCH v10 2/2] pwm: sifive: Add a driver for SiFive SoC PWM

[Yash Shah <yash.shah@sifive.com>]

On Tue, Mar 19, 2019 at 3:16 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> [I put Thierry into To: because some remaining questions depend on his
> views]
>
> On Mon, Mar 18, 2019 at 05:17:14PM +0530, Yash Shah wrote:
> > Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC.
> >
> > Signed-off-by: Wesley W. Terpstra <wesley@sifive.com>
> > [Atish: Various fixes and code cleanup]
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Signed-off-by: Yash Shah <yash.shah@sifive.com>
> > ---
> >  drivers/pwm/Kconfig      |  11 ++
> >  drivers/pwm/Makefile     |   1 +
> >  drivers/pwm/pwm-sifive.c | 334 +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 346 insertions(+)
> >  create mode 100644 drivers/pwm/pwm-sifive.c
> >
> > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > index a8f47df..4a61d1a 100644
> > --- a/drivers/pwm/Kconfig
> > +++ b/drivers/pwm/Kconfig
> > @@ -380,6 +380,17 @@ config PWM_SAMSUNG
> >         To compile this driver as a module, choose M here: the module
> >         will be called pwm-samsung.
> >
> > +config PWM_SIFIVE
> > +     tristate "SiFive PWM support"
> > +     depends on OF
> > +     depends on COMMON_CLK
> > +     depends on RISCV || COMPILE_TEST
> > +     help
> > +       Generic PWM framework driver for SiFive SoCs.
> > +
> > +       To compile this driver as a module, choose M here: the module
> > +       will be called pwm-sifive.
> > +
> >  config PWM_SPEAR
> >       tristate "STMicroelectronics SPEAr PWM support"
> >       depends on PLAT_SPEAR
> > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> > index 9c676a0..30089ca 100644
> > --- a/drivers/pwm/Makefile
> > +++ b/drivers/pwm/Makefile
> > @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_RCAR)              += pwm-rcar.o
> >  obj-$(CONFIG_PWM_RENESAS_TPU)        += pwm-renesas-tpu.o
> >  obj-$(CONFIG_PWM_ROCKCHIP)   += pwm-rockchip.o
> >  obj-$(CONFIG_PWM_SAMSUNG)    += pwm-samsung.o
> > +obj-$(CONFIG_PWM_SIFIVE)     += pwm-sifive.o
> >  obj-$(CONFIG_PWM_SPEAR)              += pwm-spear.o
> >  obj-$(CONFIG_PWM_STI)                += pwm-sti.o
> >  obj-$(CONFIG_PWM_STM32)              += pwm-stm32.o
> > diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
> > new file mode 100644
> > index 0000000..4b4d48e
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-sifive.c
> > @@ -0,0 +1,334 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017-2018 SiFive
> > + * For SiFive's PWM IP block documentation please refer Chapter 14 of
> > + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> > + *
> > + * Limitations:
> > + * - When changing both duty cycle and period, we cannot prevent in
> > + *   software that the output might produce a period with mixed
> > + *   settings (new period length and old duty cycle).
> > + * - The hardware cannot generate a 100% duty cycle.
> > + * - The hardware generates only inverted output.
> > + */
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pwm.h>
> > +#include <linux/slab.h>
> > +#include <linux/bitfield.h>
> > +
> > +/* Register offsets */
> > +#define PWM_SIFIVE_PWMCFG            0x0
> > +#define PWM_SIFIVE_PWMCOUNT          0x8
> > +#define PWM_SIFIVE_PWMS                      0x10
> > +#define PWM_SIFIVE_PWMCMP0           0x20
> > +
> > +/* PWMCFG fields */
> > +#define PWM_SIFIVE_PWMCFG_SCALE              GENMASK(3, 0)
> > +#define PWM_SIFIVE_PWMCFG_STICKY     BIT(8)
> > +#define PWM_SIFIVE_PWMCFG_ZERO_CMP   BIT(9)
> > +#define PWM_SIFIVE_PWMCFG_DEGLITCH   BIT(10)
> > +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS  BIT(12)
> > +#define PWM_SIFIVE_PWMCFG_EN_ONCE    BIT(13)
> > +#define PWM_SIFIVE_PWMCFG_CENTER     BIT(16)
> > +#define PWM_SIFIVE_PWMCFG_GANG               BIT(24)
> > +#define PWM_SIFIVE_PWMCFG_IP         BIT(28)
> > +
> > +/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */
> > +#define PWM_SIFIVE_SIZE_PWMCMP               4
> > +#define PWM_SIFIVE_CMPWIDTH          16
> > +#define PWM_SIFIVE_DEFAULT_PERIOD    10000000
> > +
> > +struct pwm_sifive_ddata {
> > +     struct pwm_chip chip;
> > +     struct mutex lock; /* lock to protect user_count */
> > +     struct notifier_block notifier;
> > +     struct clk *clk;
> > +     void __iomem *regs;
> > +     unsigned int real_period;
> > +     unsigned int approx_period;
> > +     int user_count;
> > +};
> > +
> > +static inline
> > +struct pwm_sifive_ddata *pwm_sifive_chip_to_ddata(struct pwm_chip *c)
> > +{
> > +     return container_of(c, struct pwm_sifive_ddata, chip);
> > +}
> > +
> > +static int pwm_sifive_request(struct pwm_chip *chip, struct pwm_device *dev)
> > +{
> > +     struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
> > +
> > +     mutex_lock(&pwm->lock);
> > +     pwm->user_count++;
> > +     mutex_unlock(&pwm->lock);
> > +
> > +     return 0;
> > +}
> > +
> > +static void pwm_sifive_free(struct pwm_chip *chip, struct pwm_device *dev)
> > +{
> > +     struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
> > +
> > +     mutex_lock(&pwm->lock);
> > +     pwm->user_count--;
> > +     mutex_unlock(&pwm->lock);
> > +}
> > +
> > +static void pwm_sifive_update_clock(struct pwm_sifive_ddata *pwm,
> > +                                 unsigned long rate)
> > +{
> > +     u32 val;
> > +     unsigned long long num;
> > +     /*
> > +      * The PWM unit is used with pwmzerocmp=0, so the only way to modify the
> > +      * period length is using pwmscale which provides the number of bits the
> > +      * counter is shifted before being feed to the comparators. A period
> > +      * lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks.
> > +      * (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period
> > +      */
> > +     unsigned long scale_pow =
> > +                     div64_ul(pwm->approx_period * (u64)rate, NSEC_PER_SEC);
> > +     int scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf);
>
> The situation here is as follows: The actual period length calculates
> as:
>
>         period_length = (0x10000 << scale) / rate
>
> Consider a clk rate of 600 MHz, then the driver maps "requested period"
> to "actual period" as follows:
>
>         if requested_period <= 218453 ns:
>                 // scale = 0
>                 actual_period = 109226 ns
>         else if requested_period <= 436906 ns:
>                 // scale = 1
>                 actual_period = 218452 ns
>         else if requested_period <= 873812 ns:
>                 // scale = 2
>                 actual_period = 436904 ns
>         ...
>         else if requested_period <= 3579139413 ns:
>                 // scale = 14
>                 actual_period = 1789569707 ns
>         else:
>                 //scale = 15
>                 actual_period = 3579139413 ns
>
> There is an obvious rounding issue: If 218452 ns are requested, we
> should end in the scale = 1 case for sure. (Similar issues exist for the
> other cases.)
>
> And then there are cases that are not that clear: What if 218000 ns are
> requested? Where should the line be drawn? Thierry?
>
> And what about long periods? The longest actually supported period
> length is around 3.5 seconds. What if a consumer requests 18 seconds?
> Where should the line be drawn when the driver is supposed to return
> -EINVAL (or -ERANGE)? Thierry?
>
> > +     val = PWM_SIFIVE_PWMCFG_EN_ALWAYS |
> > +           FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale);
> > +     writel(val, pwm->regs + PWM_SIFIVE_PWMCFG);
>
> Starting with this write the new period length might be active with the
> previous duty cycle. Is this worth a comment? I think the window where
> this can actually happen should be made as small as possible, so it
> would be great to first calculate both register values and then write
> them in two consecutive writels.

The comment for this scenario has already been mentioned under the
limitation on top of this driver.
Anyway, I will try to implement your suggestion of consecutive writes

>
> > +     /* As scale <= 15 the shift operation cannot overflow. */
> > +     num = (unsigned long long)NSEC_PER_SEC << (PWM_SIFIVE_CMPWIDTH + scale);
> > +     pwm->real_period = div64_ul(num, rate);
>
> What about rounding here? I'd say use "round closest" instead of "round
> down".
>
> > +     dev_dbg(pwm->chip.dev, "New real_period = %u ns\n", pwm->real_period);
> > +}
> > +
> > +static void pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *dev,
> > +                              struct pwm_state *state)
> > +{
> > +     struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
> > +     u32 duty, val;
> > +
> > +     duty = readl(pwm->regs + PWM_SIFIVE_PWMCMP0 +
> > +                  dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP);
> > +
> > +     state->enabled = duty > 0;
> > +
> > +     val = readl(pwm->regs + PWM_SIFIVE_PWMCFG);
> > +     if (!(val & PWM_SIFIVE_PWMCFG_EN_ALWAYS))
> > +             state->enabled = false;
> > +
> > +     state->period = pwm->real_period;
> > +     state->duty_cycle =
> > +             (u64)duty * pwm->real_period >> PWM_SIFIVE_CMPWIDTH;
> > +     state->polarity = PWM_POLARITY_INVERSED;
>
> If the PWM was configured for { .period = 1000000, .duty_cycle =
> 1000000, .enabled = false, ... }, .get_state still returns .duty_cycle =
> 0. Is this acceptable?
>
> > +}
> > +
> > +static int pwm_sifive_enable(struct pwm_chip *chip, bool enable)
> > +{
> > +     struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
> > +     int ret;
> > +
> > +     if (enable) {
> > +             ret = clk_enable(pwm->clk);
> > +             if (ret) {
> > +                     dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret);
>
> Space after : please. Also applies to the other error strings.

Sure

>
> > +                     return ret;
> > +             }
> > +     }
> > +
> > +     if (!enable)
> > +             clk_disable(pwm->clk);
> > +
> > +     return 0;
> > +}
> > +
> > +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev,
> > +                         struct pwm_state *state)
> > +{
> > +     struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
>
> I think it would be more common to call the struct pwm_device pointer
> "pwm" and the struct pwm_sifive_ddata pointer "ddata".
> "dev" is usually a pointer to a struct device. The other functions need
> the same adaption of course.

Ok. Will change that

>
> > +     unsigned int duty_cycle;
> > +     u32 frac;
> > +     struct pwm_state cur_state;
> > +     bool enabled;
> > +     int ret = 0;
> > +     unsigned long long num;
> > +
> > +     if (state->polarity != PWM_POLARITY_INVERSED)
> > +             return -EINVAL;
> > +
> > +     ret = clk_enable(pwm->clk);
> > +     if (ret) {
> > +             dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret);
> > +             return ret;
> > +     }
> > +
> > +     mutex_lock(&pwm->lock);
> > +     cur_state = dev->state;
> > +     enabled = cur_state.enabled;
> > +
> > +     if (state->period != pwm->approx_period) {
> > +             if (pwm->user_count != 1) {
> > +                     ret = -EBUSY;
> > +                     goto exit;
> > +             }
> > +             pwm->approx_period = state->period;
> > +             pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk));
> > +     }
> > +
> > +     duty_cycle = state->duty_cycle;
> > +     if (!state->enabled)
> > +             duty_cycle = 0;
> > +
> > +     num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
> > +     frac = DIV_ROUND_CLOSEST_ULL(num, state->period);
> > +     /* The hardware cannot generate a 100% duty cycle */
> > +     frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
> > +
> > +     writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 +
> > +            dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP);
>
> Here is another rounding question. Given that the period length can only
> be modified by factors of two there are cases where the real period is
> off by a factor of at least 1.4 which has an effect on the duty cycle.
> Consider again an input clk rate of 600 MHz, and:
>
>         .duty_cycle = 109226 [ns]
>         .period = 152916 [ns]
>
> We either have to go for real period = 109226 ns (as is currently
> implemented) or with 218452 ns. Which one should be chosen I already
> asked above. Here the question is (probably depending on the former
> question) how should the actual duty_cycle be calculated?
>
> > +     if (state->enabled != enabled) {
> > +             ret = pwm_sifive_enable(chip, state->enabled);
> > +             if (ret)
> > +                     goto exit;
>
> This goto is a noop and so can be dropped.

Sure

>
> > +     }
> > +
> > +exit:
> > +     clk_disable(pwm->clk);
> > +     mutex_unlock(&pwm->lock);
> > +     return ret;
> > +}
> > +
> > +static const struct pwm_ops pwm_sifive_ops = {
> > +     .request = pwm_sifive_request,
> > +     .free = pwm_sifive_free,
> > +     .get_state = pwm_sifive_get_state,
> > +     .apply = pwm_sifive_apply,
> > +     .owner = THIS_MODULE,
> > +};
> > +
> > +static int pwm_sifive_clock_notifier(struct notifier_block *nb,
> > +                                  unsigned long event, void *data)
> > +{
> > +     struct clk_notifier_data *ndata = data;
> > +     struct pwm_sifive_ddata *pwm =
> > +             container_of(nb, struct pwm_sifive_ddata, notifier);
> > +
> > +     if (event == POST_RATE_CHANGE)
> > +             pwm_sifive_update_clock(pwm, ndata->new_rate);
> > +
> > +     return NOTIFY_OK;
> > +}
> > +
> > +static int pwm_sifive_probe(struct platform_device *pdev)
> > +{
> > +     struct device *dev = &pdev->dev;
> > +     struct pwm_sifive_ddata *pwm;
> > +     struct pwm_chip *chip;
> > +     struct resource *res;
> > +     int ret;
> > +
> > +     pwm = devm_kzalloc(dev, sizeof(*pwm), GFP_KERNEL);
> > +     if (!pwm)
> > +             return -ENOMEM;
> > +
> > +     mutex_init(&pwm->lock);
> > +     chip = &pwm->chip;
> > +     chip->dev = dev;
> > +     chip->ops = &pwm_sifive_ops;
> > +     chip->of_pwm_n_cells = 3;
> > +     chip->base = -1;
> > +     chip->npwm = 4;
> > +
> > +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +     pwm->regs = devm_ioremap_resource(dev, res);
> > +     if (IS_ERR(pwm->regs)) {
> > +             dev_err(dev, "Unable to map IO resources\n");
> > +             return PTR_ERR(pwm->regs);
> > +     }
> > +
> > +     pwm->clk = devm_clk_get(dev, NULL);
> > +     if (IS_ERR(pwm->clk)) {
> > +             if (PTR_ERR(pwm->clk) != -EPROBE_DEFER)
> > +                     dev_err(dev, "Unable to find controller clock\n");
> > +             return PTR_ERR(pwm->clk);
> > +     }
> > +
> > +     ret = clk_prepare_enable(pwm->clk);
> > +     if (ret) {
> > +             dev_err(dev, "failed to enable clock for pwm: %d\n", ret);
> > +             return ret;
> > +     }
> > +
> > +     /* Watch for changes to underlying clock frequency */
> > +     pwm->notifier.notifier_call = pwm_sifive_clock_notifier;
> > +     ret = clk_notifier_register(pwm->clk, &pwm->notifier);
>
> Is it a problem when the notifier is called before pwmchip_add was
> called? Out of interest: Is a real problem addressed here? I.e.: Does
> the input clock actually change in practise? Also note that
> pwm_sifive_clock_notifier only adapts the period but not the duty cycle
> (any more).
>
> Given that a clk rate change affects the output, I wonder if the change
> should be declined if the pwm is running.
>
> > +     if (ret) {
> > +             dev_err(dev, "failed to register clock notifier: %d\n", ret);
> > +             goto disable_clk;
> > +     }
> > +
> > +     /* Initialize PWM */
> > +     pwm->approx_period = PWM_SIFIVE_DEFAULT_PERIOD;
> > +     pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk));
>
> If the bootloader setup a display with a backlight driven by a PWM it
> would be ideal to not modify the already running hardware here.

Ok, will drop this initialization.

>
> > +     ret = pwmchip_add(chip);
> > +     if (ret < 0) {
> > +             dev_err(dev, "cannot register PWM: %d\n", ret);
> > +             goto unregister_clk;
> > +     }
> > +
> > +     platform_set_drvdata(pdev, pwm);
> > +     dev_dbg(dev, "SiFive PWM chip registered %d PWMs\n", chip->npwm);
> > +
> > +     return 0;
> > +
> > +unregister_clk:
> > +     clk_notifier_unregister(pwm->clk, &pwm->notifier);
> > +disable_clk:
> > +     clk_disable_unprepare(pwm->clk);
> > +
> > +     return ret;
> > +}
> > +
> > +static int pwm_sifive_remove(struct platform_device *dev)
> > +{
> > +     struct pwm_sifive_ddata *pwm = platform_get_drvdata(dev);
> > +     int ret, ch;
> > +     bool is_enabled = false;
> > +
> > +     ret = pwmchip_remove(&pwm->chip);
> > +     clk_notifier_unregister(pwm->clk, &pwm->notifier);
> > +
> > +     for (ch = 0; ch < pwm->chip.npwm; ch++) {
> > +             if (pwm_is_enabled(&pwm->chip.pwms[ch])) {
>
> Here is another consumer API function call.

Will avoid using it.

>
> > +                     is_enabled = true;
> > +                     break;
> > +             }
> > +     }
> > +     if (is_enabled)
> > +             clk_disable(pwm->clk);
> > +     clk_unprepare(pwm->clk);
>
> I think you're leaking a clk_enable here. The probe function does one
> unconditionally that is never undone.

Will use clk_disable_unprepare instead of clk_unprepare

>
> > +     return ret;
> > +}
> > +
> > +static const struct of_device_id pwm_sifive_of_match[] = {
> > +     { .compatible = "sifive,pwm0" },
> > +     {},
> > +};
> > +MODULE_DEVICE_TABLE(of, pwm_sifive_of_match);
> > +
> > +static struct platform_driver pwm_sifive_driver = {
> > +     .probe = pwm_sifive_probe,
> > +     .remove = pwm_sifive_remove,
> > +     .driver = {
> > +             .name = "pwm-sifive",
> > +             .of_match_table = pwm_sifive_of_match,
> > +     },
> > +};
> > +module_platform_driver(pwm_sifive_driver);
> > +
> > +MODULE_DESCRIPTION("SiFive PWM driver");
> > +MODULE_LICENSE("GPL v2");
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv