linux-kernel - Re: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHh=Yk9mBDtFM4TRKEknNgrMN9qK4XtmPWLAT2E2P3RHwVh6ww@mail.gmail.com>
Date:   Fri, 21 Apr 2023 14:16:20 +0800
From:   Nylon Chen <nylon.chen@...ive.com>
To:     Emil Renner Berthing <emil.renner.berthing@...onical.com>
Cc:     aou@...s.berkeley.edu, conor@...nel.org, geert+renesas@...der.be,
        heiko@...ech.de, krzysztof.kozlowski+dt@...aro.org,
        palmer@...belt.com, paul.walmsley@...ive.com, robh+dt@...nel.org,
        thierry.reding@...il.com, u.kleine-koenig@...gutronix.de,
        devicetree@...r.kernel.org, linux-pwm@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        nylon7717@...il.com, zong.li@...ive.com, greentime.hu@...ive.com,
        vincent.chen@...ive.com, Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm

Hi Emil,

Emil Renner Berthing <emil.renner.berthing@...onical.com> 於 2023年4月20日
週四 下午6:46寫道：
>
> On Thu, 20 Apr 2023 at 12:41, Nylon Chen <nylon.chen@...ive.com> wrote:
> >
> > Hi, Emil
> >
> > Emil Renner Berthing <emil.renner.berthing@...onical.com> 於 2023年4月20日 週四 下午6:04寫道：
> > >
> > > On Thu, 20 Apr 2023 at 11:35, Nylon Chen <nylon.chen@...ive.com> wrote:
> > > >
> > > > The `frac` variable represents the pulse inactive time, and the result of
> > > > this algorithm is the pulse active time. Therefore, we must reverse the
> > > > result.
> > > >
> > > > The reference is SiFive FU740-C000 Manual[0]
> > > >
> > > > Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf [0]
> > > >
> > > > Acked-by: Conor Dooley <conor.dooley@...rochip.com>
> > > > Reviewed-by: Conor Dooley <conor.dooley@...rochip.com>
> > > > Signed-off-by: Nylon Chen <nylon.chen@...ive.com>
> > > > Signed-off-by: Vincent Chen <vincent.chen@...ive.com>
> > > > ---
> > > >  drivers/pwm/pwm-sifive.c | 9 ++++++---
> > > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
> > > > index 393a4b97fc19..d5d5f36da297 100644
> > > > --- a/drivers/pwm/pwm-sifive.c
> > > > +++ b/drivers/pwm/pwm-sifive.c
> > > > @@ -132,13 +132,13 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > >  {
> > > >         struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
> > > >         struct pwm_state cur_state;
> > > > -       unsigned int duty_cycle;
> > > > +       unsigned int duty_cycle, period;
> > > >         unsigned long long num;
> > > >         bool enabled;
> > > >         int ret = 0;
> > > >         u32 frac;
> > > >
> > > > -       if (state->polarity != PWM_POLARITY_INVERSED)
> > > > +       if (state->polarity != PWM_POLARITY_NORMAL && state->polarity != PWM_POLARITY_INVERSED)
> > > >                 return -EINVAL;
> > > >
> > > >         cur_state = pwm->state;
> > > > @@ -154,10 +154,13 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > >          * calculating the register values first and then writing them
> > > >          * consecutively
> > > >          */
> > > > +       period = max(state->period, ddata->approx_period);
> > >
> > > Hi Nylon,
> > >
> > > I don't understand this patch. You introduce this new variable,
> > > period, and set it here but you never seem to use it. If you planned
> > > to use it instead of state->period below, why should it be the max of
> > > the old period and what is requested? What happens if the consumer
> > > wants to lower the period?
> > Sorry this was an oversight on my part, there was a line correction that didn't change to
> > - frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
> > + frac = DIV64_U64_ROUND_CLOSEST(num, period);
>
> I see, so then my second question was why period needs to be the
> larger of the previous period and the requested period.
>
> What happens if the requested period, state->period, is lower than the
> old period, ddata->approx_period? Then the period will be changed to
> state->period below, but the calculations will be made using period =
> ddata->approx_period, right?

Your understanding is correct. According to the new algorithm proposed
by Uwe, the goal is to:
Pick the biggest period length possible that is not bigger than the
requested period.
>
> > >
> > > Also above you now allow both PWM_POLARITY_NORMAL and
> > > PWM_POLARITY_INVERSED but you treat both cases the same.
> > I may have misunderstood what Uwe means here, I will confirm again here
> > >
> > > /Emil
> > >
> > > >         num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
> > > >         frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
> > > > -       /* The hardware cannot generate a 100% duty cycle */
> > > >         frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
> > > > +       /* The hardware cannot generate a 100% duty cycle */
> > > > +       frac = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
> > > > +
> > > >
> > > >         mutex_lock(&ddata->lock);
> > > >         if (state->period != ddata->approx_period) {
> > > > --
> > > > 2.40.0
> > > >