linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Clemens Gruber <clemens.gruber@pqgruber.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org,
	"Sven Van Asbroeck" <TheSven73@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 4/7] pwm: pca9685: Support staggered output ON times
Date: Thu, 1 Apr 2021 15:47:26 +0200	[thread overview]
Message-ID: <YGXO7oKWPjYYrVFy@orome.fritz.box> (raw)
In-Reply-To: <YGV7VJ72nWDIjNbu@workstation.tuxnet>

[-- Attachment #1: Type: text/plain, Size: 5499 bytes --]

On Thu, Apr 01, 2021 at 09:50:44AM +0200, Clemens Gruber wrote:
> Hi Thierry,
> 
> On Wed, Mar 31, 2021 at 06:21:32PM +0200, Thierry Reding wrote:
> > On Wed, Mar 31, 2021 at 02:26:14PM +0200, Clemens Gruber wrote:
> > > On Mon, Mar 29, 2021 at 08:02:06PM +0200, Uwe Kleine-König wrote:
> > > > On Mon, Mar 29, 2021 at 07:16:38PM +0200, Clemens Gruber wrote:
> > > > > On Mon, Mar 29, 2021 at 07:03:57PM +0200, Uwe Kleine-König wrote:
> > > > > > On Mon, Mar 29, 2021 at 02:57:04PM +0200, Clemens Gruber wrote:
> > > > > > > The PCA9685 supports staggered LED output ON times to minimize current
> > > > > > > surges and reduce EMI.
> > > > > > > When this new option is enabled, the ON times of each channel are
> > > > > > > delayed by channel number x counter range / 16, which avoids asserting
> > > > > > > all enabled outputs at the same counter value while still maintaining
> > > > > > > the configured duty cycle of each output.
> > > > > > > 
> > > > > > > Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
> > > > > > 
> > > > > > Is there a reason to not want this staggered output? If it never hurts I
> > > > > > suggest to always stagger and drop the dt property.
> > > > > 
> > > > > There might be applications where you want multiple outputs to assert at
> > > > > the same time / to be synchronized.
> > > > > With staggered outputs mode always enabled, this would no longer be
> > > > > possible as they are spread out according to their channel number.
> > > > > 
> > > > > Not sure how often that usecase is required, but just enforcing the
> > > > > staggered mode by default sounds risky to me.
> > > > 
> > > > There is no such guarantee in the PWM framework, so I don't think we
> > > > need to fear breaking setups. Thierry?
> > > 
> > > Still, someone might rely on it? But let's wait for Thierry's opinion.
> > 
> > There's currently no way to synchronize two PWM channels in the PWM
> > framework. And given that each PWM channel is handled separately the
> > programming for two channels will never happen atomically or even
> > concurrently, so I don't see how you could run two PWMs completely
> > synchronized to one another.
> 
> As the PCA9685 has only one prescaler and one counter per chip, by
> default, all PWMs enabled will go high at the same time. If they also
> have the same duty cycle configured, they also go low at the same time.

What happens if you enable one of them, it then goes high and then you
enable the next one? Is the second one going to get enabled on the next
period? Or will it start in the middle of the period?

To truly enable them atomically, you'd have to ensure they all get
enabled in basically the same write, right? Because otherwise you can
still end up with just a subset enabled and the rest getting enabled
only after the first period.

> > Or did I misunderstand and it's only the start time of the rising edge
> > that's shifted, but the signal will remain high for a full duty cycle
> > after that and then go down and remain low for period - duty - offset?
> 
> Yes, that's how it works.

That's less problematic because the signal will remain a standard PWM,
it's just shifted by some amount. Technically pwm_apply_state() must
only return when the signal has been enabled, so very strictly speaking
you'd have to wait for a given amount of time to ensure that's correct.
But again, I doubt that any use-case would require you to be that
deterministic.

> > That's slightly better than the above in that it likely won't trip up
> > any consumers. But it might still be worth to make this configurable per
> > PWM (perhaps by specifying a third specifier cell, in addition to the
> > period and flags, that defines the offset/phase of the signal).
> > 
> > In both cases, doing this on a per-PWM basis will allow the consumer to
> > specify that they're okay with staggered mode and you won't actually
> > force it onto anyone. This effectively makes this opt-in and there will
> > be no change for existing consumers.
> 
> I agree that it should be opt-in, but I am not sure about doing it
> per-pwm:
> The reason why you'd want staggered mode is to reduce EMI or current
> spikes and it is most effective if it is enabled for all PWMs.
> 
> If it is specified in the DT anyway and you have a consumer that does
> not support staggered mode (probably rare but can happen), then I'd
> suggest just disabling it globally by not specifying nxp,staggered-mode;
> 
> Also it would make the configuration more complicated: You have to do
> the "staggering" yourself and assign offsets per channel.
> It's certainly easier to just enable or disable it.
> 
> What do you think?

Yeah, if you use an offset in the PWM specifier, users would have to
manually specify the offset. An interesting "feature" of that would be
that they could configure a subset of PWM channels to run synchronized
(module the atomicity problems discussed above). Not sure if that's
something anyone would ever want to do.

Another option would be to add some new flag that specifies that a given
PWM channel may use this mode. In that case users wouldn't have to care
about specifying the exact offset and instead just use the flag and rely
on the driver to pick some offset. Within the driver you could then just
keep the same computation that offsets by channel index, or you could
have any other mechanism that you want.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-04-01 18:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 12:57 [PATCH v6 1/7] pwm: pca9685: Switch to atomic API Clemens Gruber
2021-03-29 12:57 ` [PATCH v6 2/7] pwm: pca9685: Support hardware readout Clemens Gruber
2021-03-29 15:51   ` Uwe Kleine-König
2021-03-29 16:33     ` Clemens Gruber
2021-03-29 16:54   ` Uwe Kleine-König
2021-03-29 17:11     ` Clemens Gruber
2021-03-29 17:41       ` Uwe Kleine-König
2021-03-29 12:57 ` [PATCH v6 3/7] pwm: pca9685: Improve runtime PM behavior Clemens Gruber
2021-03-29 15:55   ` Uwe Kleine-König
2021-03-29 16:31     ` Clemens Gruber
2021-03-29 12:57 ` [PATCH v6 4/7] pwm: pca9685: Support staggered output ON times Clemens Gruber
2021-03-29 17:03   ` Uwe Kleine-König
2021-03-29 17:16     ` Clemens Gruber
2021-03-29 18:02       ` Uwe Kleine-König
2021-03-31 12:26         ` Clemens Gruber
2021-03-31 13:55           ` Clemens Gruber
2021-04-01 20:59             ` Uwe Kleine-König
2021-04-01 21:53               ` Clemens Gruber
2021-03-31 16:21           ` Thierry Reding
2021-04-01  7:50             ` Clemens Gruber
2021-04-01 13:47               ` Thierry Reding [this message]
2021-04-01 15:19                 ` Clemens Gruber
2021-04-02 19:48             ` Uwe Kleine-König
2021-04-01 20:58           ` Uwe Kleine-König
2021-04-01 21:37             ` Clemens Gruber
2021-04-02 20:23           ` Uwe Kleine-König
2021-03-29 12:57 ` [PATCH v6 5/7] dt-bindings: pwm: pca9685: Add nxp,staggered-outputs property Clemens Gruber
2021-04-02 19:52   ` Uwe Kleine-König
2021-03-29 12:57 ` [PATCH v6 6/7] pwm: pca9685: Restrict period change for prescaler users Clemens Gruber
2021-03-29 17:15   ` Uwe Kleine-König
2021-03-29 17:33     ` Clemens Gruber
2021-03-29 17:49       ` Uwe Kleine-König
2021-03-29 12:57 ` [PATCH v6 7/7] pwm: pca9685: Add error messages for failed regmap calls 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=YGXO7oKWPjYYrVFy@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=TheSven73@gmail.com \
    --cc=clemens.gruber@pqgruber.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --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).