From: Clemens Gruber <clemens.gruber@pqgruber.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-pwm@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
linux-kernel@vger.kernel.org,
Sven Van Asbroeck <TheSven73@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
David Jander <david@protonic.nl>
Subject: Re: [PATCH v4 1/4] pwm: pca9685: Switch to atomic API
Date: Tue, 8 Dec 2020 11:12:18 +0100 [thread overview]
Message-ID: <X89RgpTb3sBBI++w@workstation.tuxnet> (raw)
In-Reply-To: <20201208091033.bxzrlad7mjbe3dsp@pengutronix.de>
Hello Uwe,
On Tue, Dec 08, 2020 at 10:10:33AM +0100, Uwe Kleine-König wrote:
> Hello Clemens,
>
> On Tue, Dec 08, 2020 at 12:13:44AM +0100, Clemens Gruber wrote:
> > On Mon, Dec 07, 2020 at 11:00:25PM +0100, Uwe Kleine-König wrote:
> > > On Mon, Dec 07, 2020 at 08:36:27PM +0100, Clemens Gruber wrote:
> > > > The hardware readout may return slightly different values than those
> > > > that were set in apply due to the limited range of possible prescale and
> > > > counter register values. If one channel is reconfigured with new duty
> > > > cycle and period, the others will keep the same relative duty cycle to
> > > > period ratio as they had before, even though the per-chip / global
> > > > frequency changed. (The PCA9685 has only one prescaler!)
> > >
> > > This is not acceptable, if you have two PWM outputs and a consumer
> > > modifies one of them the other must change. So if this chip only
> > > supports a single period length of all channels, the first consumer
> > > enabling a channel defines the period to be used. All later consumers
> > > must live with that. (Also the first must be denied modifying the period
> > > if a second consumer has enabled its PWM.)
> >
> > Good idea, but is it OK to potentially break users relying on the old
> > behavior ("the last one who changes the period wins") ?
>
> If this is already in the old code, this probably warrants a separate
> fix, and yes, I consider this a severe bug. (Consider one channel
> driving a motor and reconfiguring an LED modifies the motor's speed.)
Yes, but a user could also be relying on the old behavior as follows:
1. Requests & enables pwm 0 for a backlight, using a period of 5000000ns
(does not care about the frequency as long as it does not flicker)
2. Requests & enables pwm 1 for a motor, using a period of 1000000ns
(does care about the frequency)
In the previous kernel versions, this would work, but with your
suggested change, (2) would fail and the motor would no longer work.
We are basically changing "the last one to set the period wins" to "the
first one to set the period wins".
If we do it like this, I'll split it out so we can at least revert it if
someone complains that it breaks his application, without reverting the
whole series.
Thanks,
Clemens
next prev parent reply other threads:[~2020-12-08 10:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 19:36 [PATCH v4 1/4] pwm: pca9685: Switch to atomic API Clemens Gruber
2020-12-07 19:36 ` [PATCH v4 2/4] pwm: pca9685: Set full OFF bits in probe Clemens Gruber
2020-12-07 19:36 ` [PATCH v4 3/4] pwm: pca9685: Support staggered output ON times Clemens Gruber
2020-12-07 19:38 ` [PATCH v4 4/4] dt-bindings: pwm: pca9685: Add nxp,staggered-outputs property Clemens Gruber
2020-12-07 22:00 ` [PATCH v4 1/4] pwm: pca9685: Switch to atomic API Uwe Kleine-König
2020-12-07 22:34 ` Sven Van Asbroeck
2020-12-07 23:24 ` Clemens Gruber
2020-12-08 9:17 ` Uwe Kleine-König
2020-12-07 23:13 ` Clemens Gruber
2020-12-08 9:10 ` Uwe Kleine-König
2020-12-08 10:12 ` Clemens Gruber [this message]
2020-12-08 13:44 ` Thierry Reding
2020-12-08 14:44 ` Sven Van Asbroeck
2020-12-08 16:57 ` Thierry Reding
2020-12-08 18:15 ` Sven Van Asbroeck
2020-12-08 20:25 ` Uwe Kleine-König
2020-12-08 18:26 ` Uwe Kleine-König
2020-12-08 20:54 ` Clemens Gruber
2020-12-09 17:02 ` Thierry Reding
2020-12-10 9:01 ` Uwe Kleine-König
2020-12-10 17:10 ` Thierry Reding
2020-12-10 20:39 ` Uwe Kleine-König
2020-12-11 8:33 ` Thierry Reding
2020-12-11 10:34 ` Uwe Kleine-König
2020-12-14 14:28 ` Thierry Reding
2020-12-14 16:09 ` Clemens Gruber
2020-12-14 16:27 ` Sven Van Asbroeck
2020-12-14 16:44 ` Sven Van Asbroeck
2020-12-10 20:54 ` Clemens Gruber
2020-12-10 21:37 ` Sven Van Asbroeck
2020-12-07 23:22 ` Sven Van Asbroeck
2020-12-07 23:56 ` Clemens Gruber
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=X89RgpTb3sBBI++w@workstation.tuxnet \
--to=clemens.gruber@pqgruber.com \
--cc=TheSven73@gmail.com \
--cc=david@protonic.nl \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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;
as well as URLs for NNTP newsgroup(s).