From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
To: Sven Van Asbroeck <thesven73@gmail.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Thierry Reding" <thierry.reding@gmail.com>,
linux-pwm@vger.kernel.org,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Clemens Gruber" <clemens.gruber@pqgruber.com>
Subject: Re: (EXT) Re: (EXT) Re: [PATCH 1/4] pwm: pca9685: remove unused duty_cycle struct element
Date: Tue, 07 Apr 2020 16:46:58 +0200 [thread overview]
Message-ID: <3ec5c2bd67cd714f86178a1e7143cd247759aaf8.camel@ew.tq-group.com> (raw)
In-Reply-To: <CAGngYiUinGeppRdnsWvX4DBLVcHFBSGWamUKdTC+rTY3kpFWcQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
On Fri, 2020-04-03 at 19:47 -0400, Sven Van Asbroeck wrote:
> On Wed, Feb 26, 2020 at 12:04 PM Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
> >
> > > - Is this racy somehow (i.e. can it happen that when going from
> > > duty_cycle/period = 1000/5000 to duty_cycle/period =
> > > 4000/10000
> > > the
> > > output is 1000/10000 (or 4000/5000) for one cycle)?
> >
> > It currently is racy. It should be possible to fix that either by
> > updating all 4 registers in a single I2C write, or by using the
> > "update
> > on ACK" mode which requires all 4 registers to be updated before
> > the
> > new setting is applied (I'm not sure if this mode would require
> > using a
> > single I2C write as well though).
>
> Matthias, did you verify experimentally that changing the period is
> racy?
>
> Looking at the datasheet and driver code, it shouldn't be. This is
> because
> the OFF time is set as a proportion of the counter range. When the
> period
> changes from 5000 to 10000, then 5000*20%/5000 and 10000*20%/10000
> will result in the same 20% ratio (disregarding rounding errors).
>
> This is documented at the beginning of the driver:
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pwm/pwm-pca9685.c?h=v5.6#n25
>
> Should we move that comment to pwm_config(), so future versions of
> ourselves won't overlook it?
You are right, this results in the same ratio - the absolute on/off
times may be wrong for a moment though when the period is changed.
In the attached image, I have changed the period, but kept the absolute
duty cycle fixed (note: this is in inverted mode, so the duty cycle
controls the low time). It can be seen that after a too long high time
(chip is in sleep mode) one period with too long low time follows (new
period, old relative duty cycle), before the counter is reprogrammed to
match the previous absolute duty cycle.
I don't care too much about the details of the behaviour, as I only
control LEDs using this chip and don't need to change the period after
initial setup, but we should accurately document the shortcomings of
the hardware and the driver (when we have decided how to fix some of
the driver issues).
Matthias
[-- Attachment #2: osc.jpg --]
[-- Type: image/jpeg, Size: 51521 bytes --]
next prev parent reply other threads:[~2020-04-07 14:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 13:52 Matthias Schiffer
2020-02-26 13:52 ` [PATCH 2/4] pwm: pca9685: remove ALL_LED PWM channel Matthias Schiffer
2020-03-30 13:07 ` Thierry Reding
2020-03-30 13:15 ` Thierry Reding
2020-03-30 13:19 ` Andy Shevchenko
2020-03-30 15:38 ` Thierry Reding
2020-03-30 13:34 ` Clemens Gruber
2020-03-30 15:40 ` Thierry Reding
2020-03-30 15:43 ` Thierry Reding
2020-03-30 16:07 ` Clemens Gruber
2020-03-31 12:09 ` (EXT) " Matthias Schiffer
2020-03-31 13:14 ` Clemens Gruber
2020-02-26 13:52 ` [PATCH 3/4] pwm: pca9685: initialize all LED registers during probe Matthias Schiffer
2020-02-26 15:00 ` Uwe Kleine-König
2020-02-26 16:13 ` (EXT) " Matthias Schiffer
2020-03-30 13:07 ` Thierry Reding
2020-02-26 13:52 ` [PATCH 4/4] pwm: pca9685: migrate config/enable/disable to apply Matthias Schiffer
2020-02-26 15:05 ` Uwe Kleine-König
2020-02-26 15:10 ` [PATCH 1/4] pwm: pca9685: remove unused duty_cycle struct element Uwe Kleine-König
2020-02-26 17:03 ` (EXT) " Matthias Schiffer
2020-02-26 19:21 ` Uwe Kleine-König
2020-02-28 13:26 ` (EXT) " Matthias Schiffer
2020-03-30 15:12 ` Clemens Gruber
2020-04-03 23:50 ` Sven Van Asbroeck
2020-04-04 17:35 ` Clemens Gruber
2020-04-04 20:17 ` Sven Van Asbroeck
2020-04-06 9:51 ` Thierry Reding
2020-04-07 13:00 ` (EXT) " Matthias Schiffer
2020-04-09 11:42 ` Sven Van Asbroeck
2020-04-03 23:47 ` Sven Van Asbroeck
2020-04-07 14:46 ` Matthias Schiffer [this message]
2020-04-08 8:00 ` (EXT) " Matthias Schiffer
2020-03-30 13:07 ` Thierry Reding
2020-03-30 13:18 ` Andy Shevchenko
2020-03-30 16:02 ` Thierry Reding
2020-03-30 16:10 ` Clemens Gruber
2020-04-01 16:36 ` Clemens Gruber
2020-04-01 17:45 ` Thierry Reding
2020-04-02 7:10 ` (EXT) " Matthias Schiffer
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=3ec5c2bd67cd714f86178a1e7143cd247759aaf8.camel@ew.tq-group.com \
--to=matthias.schiffer@ew.tq-group.com \
--cc=clemens.gruber@pqgruber.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=thesven73@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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
all inboxes | Powered by JetHome®