From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-pwm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
DTML <devicetree@vger.kernel.org>,
Chunyan Zhang <zhang.lyra@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
kernel@pengutronix.de, Orson Zhai <orsonzhai@gmail.com>
Subject: Re: [PATCH v3 2/2] pwm: sprd: Add Spreadtrum PWM support
Date: Fri, 16 Aug 2019 08:45:08 +0200 [thread overview]
Message-ID: <20190816064508.5tyimuqcjcr2hbkp@pengutronix.de> (raw)
In-Reply-To: <CAMz4kuJBbTrR9+7XfDhRtmJovFJnne_RPGrdOYe09mdRDrDrig@mail.gmail.com>
Hello Baolin,
On Fri, Aug 16, 2019 at 10:44:41AM +0800, Baolin Wang wrote:
> On Thu, 15 Aug 2019 at 20:25, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > 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@pengutronix.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@pengutronix.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@pengutronix.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@pengutronix.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
>
> You are wrong, we will provide 145350 ns with
> DIV_ROUND_CLOSEST_ULL()., which is better than your 144780.
There are two problems with your statement:
- You're ignoring the fact that I base my argumentation on not using
DIV_ROUND_CLOSEST_ULL because it has downsides I pointed out to you.
If my suggested algorithm targeted a closest match (and not
closest-but-not-bigger) it would pick 145350 ns, too. (I didn't check
if something in the interval [145331, 145349] could be achieved. If
there is, this should of course be preferred.)
I obviously would have to pick a different example request to show
that "targeting nearest with MOD always 255" is for some requests
worse (probably by a similar factor) than "targeting nearest".
It's not surprising that your apple is a better apple than my orange.
- It's not objective that when 145340 ns was requested 145350 ns is
better than 144780 ns. Some approximations are obviously better than
others, but these two are not comparable in a way that all PWM
consumers agree.
I'm not perfect and I do mistakes of course. But I'm still convinced
that my argumentation here is right.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2019-08-16 6:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 12:46 [PATCH v3 1/2] dt-bindings: pwm: sprd: Add Spreadtrum PWM documentation Baolin Wang
2019-08-14 12:46 ` [PATCH v3 2/2] pwm: sprd: Add Spreadtrum PWM support Baolin Wang
2019-08-14 15:03 ` Uwe Kleine-König
2019-08-15 3:34 ` Baolin Wang
2019-08-15 6:15 ` Uwe Kleine-König
2019-08-15 8:16 ` Baolin Wang
2019-08-15 8:54 ` Uwe Kleine-König
2019-08-15 9:34 ` Baolin Wang
2019-08-15 10:11 ` Uwe Kleine-König
2019-08-15 11:05 ` Baolin Wang
2019-08-15 12:25 ` Uwe Kleine-König
2019-08-16 2:44 ` Baolin Wang
2019-08-16 6:45 ` Uwe Kleine-König [this message]
2019-08-27 16:20 ` [PATCH v3 1/2] dt-bindings: pwm: sprd: Add Spreadtrum PWM documentation Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190816064508.5tyimuqcjcr2hbkp@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=baolin.wang@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=orsonzhai@gmail.com \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vincent.guittot@linaro.org \
--cc=zhang.lyra@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).