linux-kernel - Re: [PATCH v3 2/2] pwm: sprd: Add Spreadtrum PWM support

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]

Date:   Thu, 15 Aug 2019 14:25:18 +0200
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Baolin Wang <baolin.wang@...aro.org>
Cc:     Mark Rutland <mark.rutland@....com>, linux-pwm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        DTML <devicetree@...r.kernel.org>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        kernel@...gutronix.de, Orson Zhai <orsonzhai@...il.com>
Subject: Re: [PATCH v3 2/2] pwm: sprd: Add Spreadtrum PWM support

On Thu, Aug 15, 2019 at 07:05:53PM +0800, Baolin Wang wrote:
> On Thu, 15 Aug 2019 at 18:11, Uwe Kleine-König
> <u.kleine-koenig@...gutronix.de> wrote:
> >
> > Hello,
> >
> > On Thu, Aug 15, 2019 at 05:34:02PM +0800, Baolin Wang wrote:
> > > On Thu, 15 Aug 2019 at 16:54, Uwe Kleine-König
> > > <u.kleine-koenig@...gutronix.de> wrote:
> > > > On Thu, Aug 15, 2019 at 04:16:32PM +0800, Baolin Wang wrote:
> > > > > On Thu, 15 Aug 2019 at 14:15, Uwe Kleine-König
> > > > > <u.kleine-koenig@...gutronix.de> wrote:
> > > > > > On Thu, Aug 15, 2019 at 11:34:27AM +0800, Baolin Wang wrote:
> > > > > > > On Wed, 14 Aug 2019 at 23:03, Uwe Kleine-König
> > > > > > > <u.kleine-koenig@...gutronix.de> wrote:
> > > > > > > > On Wed, Aug 14, 2019 at 08:46:11PM +0800, Baolin Wang wrote:
> > > > > > > > > +      * To keep the maths simple we're always using MOD = SPRD_PWM_MOD_MAX.
> > > > > > > >
> > > > > > > > Did you spend some thoughts about how wrong your period can get because
> > > > > > > > of that "lazyness"?
> > > > > > > >
> > > > > > > > Let's assume a clk rate of 100/3 MHz. Then the available period lengths
> > > > > > > > are:
> > > > > > > >
> > > > > > > >         PRESCALE =  0  ->  period =   7.65 µs
> > > > > > > >         PRESCALE =  1  ->  period =  15.30 µs
> > > > > > > >         ...
> > > > > > > >         PRESCALE = 17  ->  period = 137.70 µs
> > > > > > > >         PRESCALE = 18  ->  period = 145.35 µs
> > > > > > > >
> > > > > > > > So the error can be up to (nearly) 7.65 µs (or in general
> > > > > > >
> > > > > > > Yes, but for our use case (pwm backlight), the precision can meet our
> > > > > > > requirement. Moreover, we usually do not change the period, just
> > > > > > > adjust the duty to change the back light.
> > > > > >
> > > > > > Is this a license requirement for you SoC to only drive a backlight with
> > > > > > the PWM? The idea of having a PWM driver on your platform is that it can
> > > > > > also be used to control a step motor or a laser.
> > > > >
> > > > > Not a license requirement. Until now we have not got any higher
> > > > > precision requirements, and we've run this driver for many years in
> > > > > our downstream kernel.
> > > >
> > > > I understood that you're not ambitious to do something better than "it
> > > > worked for years".
> > >
> > > How do you know that?
> >
> > I showed you how you could match the requested PWM output better and
> > you refused telling it worked for years and the added precision isn't
> > necessary for a backlight.
> 
> Please I said the reason, it is not that I do not want a better
> precision. The problem is we do not know how much precision to be
> asked by users if no use case

I don't understand the problem here. If you are asked for period =
145340 ns and configure the hardware to yield 137700 ns in reply to that
but you could provide 144780 ns I don't understand why you need a use
case as 144780 ns is objectively better than 137700 ns. A better match
has only upsides, it doesn't hurt people how don't care about a few
micro seconds in the one or the other direction. OK, your CPU needs a
few more cycles to find the better configuration but that's a poor
argument. With only a backlight as use case you could even hardcode
PRESCALE = 0 without any problems and have the needed calculations a bit
cheaper.

> > > What I mean is use DIV_ROUND_CLOSEST_ULL we can get a nearer value to
> > > the requested like above example.
> >
> > But given that it's unclear if 137700 ns or 145350 ns is better when
> > 145340 ns was requested this is not a strong argument to use
> > DIV_ROUND_CLOSEST_ULL. With the global picture for the pwm framework in
> > mind it is sensible to request the same rounding from all drivers to get
> > a consistent behaviour. And I believe the maths with rounding down is
> > easier than when rounding up or nearest. That's why I argue in this
> > direction.
> 
> Let's wait for Thierry's suggestion to get a consensus firstly.

OK. I'm not sure you want to wait until Thierry and I agree on a
solution here though :-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |