All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Clemens Gruber <clemens.gruber@pqgruber.com>
Cc: linux-pwm@vger.kernel.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Sven Van Asbroeck <TheSven73@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 7/8] pwm: pca9685: Restrict period change for enabled PWMs
Date: Wed, 7 Apr 2021 23:38:02 +0200	[thread overview]
Message-ID: <20210407213802.yuure3jawpw4wnee@pengutronix.de> (raw)
In-Reply-To: <YG4Y94sIL/xO2u/N@workstation.tuxnet>

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

On Wed, Apr 07, 2021 at 10:41:27PM +0200, Clemens Gruber wrote:
> On Wed, Apr 07, 2021 at 08:12:29AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 06, 2021 at 06:41:39PM +0200, Clemens Gruber wrote:
> > > Previously, the last used PWM channel could change the global prescale
> > > setting, even if other channels are already in use.
> > > 
> > > Fix it by only allowing the first enabled PWM to change the global
> > > chip-wide prescale setting. If there is more than one channel in use,
> > > the prescale settings resulting from the chosen periods must match.
> > > 
> > > GPIOs do not count as enabled PWMs as they are not using the prescaler
> > > and can't change it.
> > > 
> > > Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
> > > ---
> > > Changes since v6:
> > > - Only allow the first PWM that is enabled to change the prescaler, not
> > >   the first one that uses the prescaler
> > > 
> > >  drivers/pwm/pwm-pca9685.c | 66 +++++++++++++++++++++++++++++++++------
> > >  1 file changed, 56 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> > > index 24221ee7a77a..cf0c98e4ef44 100644
> > > --- a/drivers/pwm/pwm-pca9685.c
> > > +++ b/drivers/pwm/pwm-pca9685.c
> > > @@ -23,11 +23,11 @@
> > >  #include <linux/bitmap.h>
> > >  
> > >  /*
> > > - * Because the PCA9685 has only one prescaler per chip, changing the period of
> > > - * one channel affects the period of all 16 PWM outputs!
> > > - * However, the ratio between each configured duty cycle and the chip-wide
> > > - * period remains constant, because the OFF time is set in proportion to the
> > > - * counter range.
> > > + * Because the PCA9685 has only one prescaler per chip, only the first channel
> > > + * that is enabled is allowed to change the prescale register.
> > > + * PWM channels requested afterwards must use a period that results in the same
> > > + * prescale setting as the one set by the first requested channel.
> > > + * GPIOs do not count as enabled PWMs as they are not using the prescaler.
> > >   */
> > >  
> > >  #define PCA9685_MODE1		0x00
> > > @@ -78,8 +78,9 @@
> > >  struct pca9685 {
> > >  	struct pwm_chip chip;
> > >  	struct regmap *regmap;
> > > -#if IS_ENABLED(CONFIG_GPIOLIB)
> > >  	struct mutex lock;
> > > +	DECLARE_BITMAP(pwms_enabled, PCA9685_MAXCHAN + 1);
> > > +#if IS_ENABLED(CONFIG_GPIOLIB)
> > >  	struct gpio_chip gpio;
> > >  	DECLARE_BITMAP(pwms_inuse, PCA9685_MAXCHAN + 1);
> > >  #endif
> > > @@ -90,6 +91,22 @@ static inline struct pca9685 *to_pca(struct pwm_chip *chip)
> > >  	return container_of(chip, struct pca9685, chip);
> > >  }
> > >  
> > > +/* This function is supposed to be called with the lock mutex held */
> > > +static bool pca9685_prescaler_can_change(struct pca9685 *pca, int channel)
> > > +{
> > > +	/* No PWM enabled: Change allowed */
> > > +	if (bitmap_empty(pca->pwms_enabled, PCA9685_MAXCHAN + 1))
> > > +		return true;
> > > +	/* More than one PWM enabled: Change not allowed */
> > > +	if (bitmap_weight(pca->pwms_enabled, PCA9685_MAXCHAN + 1) > 1)
> > > +		return false;
> > > +	/*
> > > +	 * Only one PWM enabled: Change allowed if the PWM about to
> > > +	 * be changed is the one that is already enabled
> > > +	 */
> > > +	return test_bit(channel, pca->pwms_enabled);
> > 
> > Maybe this is a bit more effective?:
> > 
> > 	DECLARE_BITMAP(blablub, PCA9685_MAXCHAN + 1);	
> > 	bitmap_zero(blablub, PCA9685_MAXCHAN + 1);
> > 	bitmap_set(blablub, channel);
> > 	return bitmap_subset(pca->pwms_enabled, blablub);
> 
> But if no PWM is enabled, it should return true, not false.

If no PWM is enabled we have pca->pwms_enabled = empty set which is a
subset of every set. So I'd expect this case to be handled just fine.

> > (but that's a minor issue, the suggested algorithm is correct.)
> 
> I would prefer to keep it explicit because it is a little easier to
> follow and probably not worth optimizing.

I didn't find it hard to follow, but I'm willing to accept that this
isn't representative. I'm ok with keeping the code as is.
 
> I agree that it would be nice to drop the ALL channel support.

Maybe deprecate it using a config item? But no hurry.

Best regards
Uwe

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

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

  reply	other threads:[~2021-04-07 21:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06 16:41 [PATCH v7 1/8] pwm: pca9685: Switch to atomic API Clemens Gruber
2021-04-06 16:41 ` [PATCH v7 2/8] pwm: pca9685: Support hardware readout Clemens Gruber
2021-04-07  5:31   ` Uwe Kleine-König
2021-04-07  7:33     ` Clemens Gruber
2021-04-07  9:09       ` Uwe Kleine-König
2021-04-07  9:53         ` Clemens Gruber
2021-04-06 16:41 ` [PATCH v7 3/8] pwm: pca9685: Improve runtime PM behavior Clemens Gruber
2021-04-09 13:03   ` Thierry Reding
2021-04-09 16:08     ` Clemens Gruber
2021-04-06 16:41 ` [PATCH v7 4/8] dt-bindings: pwm: Support new PWM_STAGGERING_ALLOWED flag Clemens Gruber
2021-04-07  5:33   ` Uwe Kleine-König
2021-04-09 12:27     ` Thierry Reding
2021-04-10 14:01       ` Uwe Kleine-König
2021-04-10 14:02   ` Uwe Kleine-König
2021-04-06 16:41 ` [PATCH v7 5/8] pwm: core: " Clemens Gruber
2021-04-07  5:46   ` Uwe Kleine-König
2021-04-07 20:21     ` Clemens Gruber
2021-04-07 21:34       ` Uwe Kleine-König
2021-04-08 12:50         ` Thierry Reding
2021-04-08 15:51           ` Clemens Gruber
2021-04-08 17:36             ` Uwe Kleine-König
2021-04-08 18:14               ` Clemens Gruber
2021-04-09 11:25               ` Thierry Reding
2021-04-09 16:02                 ` Clemens Gruber
2021-04-09 21:35                 ` Uwe Kleine-König
2021-04-09 11:10             ` Thierry Reding
2021-04-06 16:41 ` [PATCH v7 6/8] pwm: pca9685: " Clemens Gruber
2021-04-06 16:41 ` [PATCH v7 7/8] pwm: pca9685: Restrict period change for enabled PWMs Clemens Gruber
2021-04-07  6:12   ` Uwe Kleine-König
2021-04-07 20:41     ` Clemens Gruber
2021-04-07 21:38       ` Uwe Kleine-König [this message]
2021-04-06 16:41 ` [PATCH v7 8/8] pwm: pca9685: Add error messages for failed regmap calls Clemens Gruber
2021-04-07  6:16   ` Uwe Kleine-König
2021-04-07 20:47     ` Clemens Gruber
2021-04-07 21:41       ` Uwe Kleine-König
2021-04-07  5:24 ` [PATCH v7 1/8] pwm: pca9685: Switch to atomic API Uwe Kleine-König
2021-04-07  7:26   ` 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=20210407213802.yuure3jawpw4wnee@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=TheSven73@gmail.com \
    --cc=clemens.gruber@pqgruber.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=thierry.reding@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.