linux-kernel - Re: [PATCH v10 0/3] Change PWM-controlled LED pin active mode and 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] [day] [month] [year] [list]

Message-ID: <CAHh=Yk-p69ppWWspEzzznhDnuk3i6dRGKzUaqZCwg_uAxB3FVA@mail.gmail.com>
Date: Thu, 23 Jan 2025 08:20:43 +0800
From: Nylon Chen <nylon.chen@...ive.com>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org, 
	devicetree@...r.kernel.org, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	Samuel Holland <samuel.holland@...ive.com>, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v10 0/3] Change PWM-controlled LED pin active mode and algorithm

Uwe Kleine-König <u.kleine-koenig@...libre.com> 於 2025年1月22日 週三 下午7:44寫道：
>
> Hello Nylon,
>
> I took another look in the driver and found another problem:
Hi Uwe, Thank you for the information.

I'll need some time to verify and understand these details, as well as
conduct the relevant tests
>
> On Tue, Jan 21, 2025 at 07:12:10PM +0100, Uwe Kleine-König wrote:
> > On Tue, Jan 21, 2025 at 04:47:46PM +0800, Nylon Chen wrote:
> > > Uwe Kleine-König <u.kleine-koenig@...libre.com> 於 2025年1月21日 週二 下午3:47寫道：
> > > >
> > > > Hello,
> > > >
> > > > On Sun, Jan 19, 2025 at 03:03:16PM +0800, Nylon Chen wrote:
> > > > > I ran some basic tests by changing the period and duty cycle in both
> > > > > decreasing and increasing sequences (see the script below).
> > > >
> > > > What is clk_get_rate(ddata->clk) for you?
> > > 130 MHz
> >
> > OK, so the possible period lengths are
> >
> >       (1 << (16 + scale)) / (130 MHz)
> >
> > for scale in [0, .. 15], right? That's
> >
> >       2^scale * 504123.07692307694 ns
> >
> > So testing period in the range between 5000 ns and 15000 ns isn't
> > sensible? Did I get something wrong? If the above is right, switching
> > between period=1008246 ns and 1008247 ns is likely to trigger a
> > warning.
>
> The possible periods are of the form
>
>         2^scale * A
>
> where A is constant and only depends on the input clock rate. scale
> ranges over [0, ... 15]. (If I got it right in my last mail, we have A =
> 504123.07692307694 ns.)
>
> If you request say:
>
>         .period = 3.9 * A
>         .duty_cycle = 1.9 * A
>
> the period actually emitted by the PWM will be 2 * A. But to calculate
> frac the originally requested period (i.e. 3.9 * A) is used. So frac
> becomes 31927 resulting in .duty_cycle being ~0.974 A. A better value
> would be frac = 62259 which results in .duty_cycle ≅ 1.9 * A.
> (Depending on A the values for frac might be off by one due to rounding
> differences.)
>
> So I would expect that PWM_DEBUG is angry with you if you go from
>
>         .period = 2 * A
>         .duty_cycle = 1.9 * A
>
> to
>
>         .period = 3.9 * A
>         .duty_cycle = 1.9 * A
>
> .
>
> Best regards
> Uwe