Message-ID: <20220307131018.6wrdsiixmgdtnodt@pengutronix.de>
Date:   Mon, 7 Mar 2022 14:10:18 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     hammer hsieh <hammerh0314@...il.com>
Cc:     thierry.reding@...il.com, lee.jones@...aro.org, robh+dt@...nel.org,
        linux-pwm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, wells.lu@...plus.com,
        "hammer.hsieh" <hammer.hsieh@...plus.com>, kernel@...gutronix.de
Subject: Re: [PATCH v2 2/2] pwm:sunplus-pwm:Add Sunplus SoC PWM Driver

Hello,

On Mon, Mar 07, 2022 at 08:50:10PM +0800, hammer hsieh wrote:
> Uwe Kleine-König <u.kleine-koenig@...gutronix.de> 於 2022年3月5日 週六 上午2:57寫道：
> > On Fri, Mar 04, 2022 at 02:20:12PM +0800, Hammer Hsieh wrote:
> > > diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c
> > > new file mode 100644
> > > index 0000000..170534f
> > > --- /dev/null
> > > +++ b/drivers/pwm/pwm-sunplus.c
> > > @@ -0,0 +1,229 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * PWM device driver for SUNPLUS SoCs
> >
> > Is there a public manual available for this hardware? If yes, please add
> > a link here.
> 
> yes, will add links as below
> https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview
> https://sunplus.atlassian.net/wiki/spaces/doc/pages/461144198/12.+Pulse+Width+Modulation+PWM
> 
> > > + *
> > > + * Limitations:
> > > + * - Only supports normal polarity.
> >
> > How does the HW behave when it's disabled? Usual candidates are:
> >  - It freezes at where it currently is
> >  - It outputs low
> >  - It becomes tristate
> >
> > Please note this in the Limitations section, too.
> >
> > Another thing to mention is if running periods are completed when the
> > parameters change.
> >
> 
> ok, will add note as below
>   Limitations:
>   - Only supports normal polarity.
>   - It output low when PWM channel disabled.
>   - When the parameters change, current running period will not be completed
>       and run new settings immediately.

Sounds good.

Other thing that might maybe happen: in .apply() you write the register
for period first and then the one for duty_cycle. Can it happen, that
for a moment the output is defined by new period and old duty_cycle?
That would be another thing to note.

> > > +struct sunplus_pwm {
> > > +     struct pwm_chip chip;
> > > +     void __iomem *base;
> > > +     struct clk *clk;
> > > +     u32 approx_period[PWM_SUP_NUM];
> > > +     u32 approx_duty_cycle[PWM_SUP_NUM];
> > > +};
> > > +
> > > +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip)
> > > +{
> > > +     return container_of(chip, struct sunplus_pwm, chip);
> > > +}
> > > +
> > > +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > +{
> > > +     struct sunplus_pwm *priv = to_sunplus_pwm(chip);
> > > +     u32 value;
> > > +
> > > +     /* disable pwm channel output */
> > > +     value = readl(priv->base + PWM_SUP_CONTROL0);
> > > +     value &= ~BIT(pwm->hwpwm);
> > > +     writel(value, priv->base + PWM_SUP_CONTROL0);
> > > +     /* disable pwm channel clk source */
> > > +     value = readl(priv->base + PWM_SUP_CONTROL1);
> > > +     value &= ~BIT(pwm->hwpwm);
> > > +     writel(value, priv->base + PWM_SUP_CONTROL1);
> >
> > the .free callback isn't supposed to modify the hardware.
> 
> But how to turn pwm channel off ?
> I add .free function for turn it off.
> In user space
>   cd /sys/class/pwm/pwmchip0
>   echo 0 > export
>   cd pwm0
>   echo 20000000 > period
>   echo 1000000 > duty_cycle
>   echo 1 > enable
>   cd ..
>   echo 0 > unexport ; turn off pwm will call .free function

unexport should just keep the PWM configured as is. To turn it of, don't
unexport but echo 0 > enable.

> > > +     u32 tmp, rate;
> > > +     u64 max_period, period_ns, duty_ns, clk_rate;
> > > +
> > > +     if (state->polarity != pwm->state.polarity)
> > > +             return -EINVAL;
> > > +
> > > +     if (!state->enabled) {
> > > +             /* disable pwm channel output */
> > > +             value = readl(priv->base + PWM_SUP_CONTROL0);
> > > +             value &= ~BIT(pwm->hwpwm);
> >
> > I'd give this one a name. Something like:
> >
> >         #define PWM_SUP_CONTROL_EN(ch)  BIT(ch)
> >
> > (Pick the right name from the manual.)
> 
> That means it need to implement
> PWM_SUP_CONTROL_EN(ch) and PWM_SUP_CONTROL_DIS(ch) ?

PWM_SUP_CONTROL_EN(ch) should be enough, PWM_SUP_CONTROL_DIS(ch) would
just be 0 which doens't make much sense.

> 
> > > +             writel(value, priv->base + PWM_SUP_CONTROL0);
> > > +             /* disable pwm channel clk source */
> > > +             value = readl(priv->base + PWM_SUP_CONTROL1);
> > > +             value &= ~BIT(pwm->hwpwm);
> > > +             writel(value, priv->base + PWM_SUP_CONTROL1);
> > > +             return 0;
> > > +     }
> > > +
> > > +     clk_rate = clk_get_rate(priv->clk);
> > > +     rate = (u32)clk_rate / 100000;
> >
> > This cast doesn't change anything, does it?
> 
> yes, clk_rate should be 202.5MHz, to prevent overflow use 2025 to calculate.

I only talked about the cast, so

	rate = clk_rate / 100000;

should have the same effect and is a tad nicer.

> > > +     max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate);
> >
> > Here you have rounding issues. Consider rate = 3329. Then you get
> > max_period = 0xffff * (2560000 / 3329) = 0xffff * 768 = 50330880.
> >
> > However the actual result is 50396395.31...
> >
> > Also dividing by the result of a division looses precision.
> >
> 
> I am not sure how to fix the rounding issue.(thinking...)

the mul_u64_u64_div_u64 I suggested should be good.

> > > +     if (dd_freq == 0)
> > > +             return -EINVAL;
> > > +
> > > +     if (dd_freq > PWM_SUP_FREQ_MAX)
> > > +             dd_freq = PWM_SUP_FREQ_MAX;
> > > +
> > > +     writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm));
> > > +
> > > +     /* cal and set pwm duty */
> > > +     value = readl(priv->base + PWM_SUP_CONTROL0);
> > > +     value |= BIT(pwm->hwpwm);
> > > +     value1 = readl(priv->base + PWM_SUP_CONTROL1);
> > > +     value1 |= BIT(pwm->hwpwm);
> > > +     if (duty_ns == period_ns) {
> > > +             value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT);
> > > +             duty = PWM_SUP_DUTY_MAX;
> > > +     } else {
> > > +             value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT);
> > > +             tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER;
> > > +             tmp /= priv->approx_period[pwm->hwpwm];
> >
> > Please use the exact values available.
> 
> The same reason, in case of enable PWM_DEBUG.
> first call .apply , then it will call .get_state for verify the calculation.

The overall goal is not to please PWM_DEBUG, but to use exact
calculations and if you did that, PWM_DEBUG should be happy, too.

> > > +             duty = (u32)tmp;
> > > +             duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT);
> > > +     }
> > > +     writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm));
> > > +     writel(value1, priv->base + PWM_SUP_CONTROL1);
> > > +     writel(value, priv->base + PWM_SUP_CONTROL0);
> >
> > What is the difference between CONTROL1 and CONTROL0?
> 
> PWM CONTROL0 for PWM channel switch.
> PWM CONTROL1 for PWM clock source switch.
> Actually PWM supports 8 channels , but clock source only 4 sets.
> For easy control(now submit), I just support 4 PWM channels, and one
> clock source for one pwm channel.
> For complicated control(not now), 8 PWM channels 4 clock source , need
> to manage clock source / pwm channel enable or not
> while request/free pwm channel.

So you can use (say) clk 2 to "drive" PWM channel 6? Where is that
mapping defined. Only implementing 4 channels with a 1:1 mapping is ok,
but you might want to ensure the mapping is indeed 1:1.

> > > +     return 0;
> > > +}
> > > +
> > > +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > > +                               struct pwm_state *state)
> > > +{
> > > +     struct sunplus_pwm *priv = to_sunplus_pwm(chip);
> > > +     u32 value, freq, duty, rate, freq_tmp, duty_tmp;
> > > +     u64 tmp, clk_rate;
> > > +
> > > +     value = readl(priv->base + PWM_SUP_CONTROL0);
> > > +
> > > +     if (value & BIT(pwm->hwpwm)) {
> > > +             clk_rate = clk_get_rate(priv->clk);
> > > +             rate = (u32)clk_rate / 100000;
> > > +             freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm));
> > > +             duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm));
> > > +             duty &= ~GENMASK(9, 8);
> > > +
> > > +             freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100);
> > > +             duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER /
> > > +                             priv->approx_period[pwm->hwpwm];
> > > +
> > > +             if (freq == freq_tmp && duty == duty_tmp) {
> > > +                     state->period = priv->approx_period[pwm->hwpwm] * 100;
> > > +                     state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100;
> > > +             } else {
> > > +                     tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000;
> > > +                     state->period = div64_u64(tmp, rate);
> > > +                     tmp = (u64)freq * (u64)duty * 10000;
> > > +                     state->duty_cycle = div64_u64(tmp, rate);
> > > +             }
> > > +             state->enabled = true;
> > > +     } else {
> > > +             state->enabled = false;
> > > +     }
> > > +
> > > +     state->polarity = PWM_POLARITY_NORMAL;
> > > +}
> >
> > When .get_state() is first called, .apply wasn't called yet. Then
> > priv->approx_period[pwm->hwpwm] is zero and the returned result is
> > wrong. Please read the register values and calculate the implemented
> > output without caching.
> 
> The same reason, in case of enable PWM_DEBUG.
> first call .apply , then it will call .get_state for verify the calculation.
> 
> In get_state, I thought about that.
> first called .get_state, read register value to calculate period and duty_cycle.
> after calling .apply , caching data approx_period / approx_duty_cycle
> will not zero.
> then get_state will use caching data to do PWM_DEBUG self verification.
> I will think about how to solve the PWM_DEBUG ".apply is not idempotent" issue.

I'd say: Don't cache anything. In .get_state() just read the registers and
determine .duty_cycle and .period from them, and in .apply() do the
inverse.

> > > +     priv->clk = devm_clk_get_optional(dev, NULL);
> > > +     if (IS_ERR(priv->clk))
> , > > +             return dev_err_probe(dev, PTR_ERR(priv->clk),
> > > +                                  "get pwm clock failed\n");
> >
> > If priv->clk is the dummy clk, clk_get_rate returns 0. This is bad as
> > (at lease up to now) you divide by rate in .apply().
> >
> 
> I check many pwm drivers , they are called devm_clk_get_optional( ) or
> devm_clk_get( ).
> Could you tell me how to do it in a probe ?

You can only sensibly use devm_clk_get_optional() if you don't rely on
the rate of the clk. So the way to go here is to just use
devm_clk_get().

> > > +     ret = devm_add_action_or_reset(dev,
> > > +                                    (void(*)(void *))clk_disable_unprepare,
> >
> > Without checking my C book I'm unsure if this is save on all platforms.
> > I'd implement a oneline function for this.
> 
> ok, will implement it in one line.
> static void sunplus_pwm_clk_release(*data)
> {
>    struct clk *clk = data;
>    clk_disable_unprepare(clk);
> }
>  ret = devm_add_action_or_reset(dev, sunplus_pwm_clk_release, priv->clk);
> 

*nod*

> > > +                                    priv->clk);
> > > +     if (ret)
> >
> > missing error message
> >
> 
> I didn't see another driver add an error message, is it necessary?

IMHO yes. (Though the most likely error -ENOMEM, in this case no error
message should be emitted.)

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