All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Gruber <clemens.gruber@pqgruber.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>,
	u.kleine-koenig@pengutronix.de, linux-pwm@vger.kernel.org,
	linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com
Subject: Re: [PATCH 2/4] pwm: pca9685: remove ALL_LED PWM channel
Date: Mon, 30 Mar 2020 18:07:44 +0200	[thread overview]
Message-ID: <20200330160744.GA777@workstation.tuxnet> (raw)
In-Reply-To: <20200330154036.GB2817345@ulmo>

On Mon, Mar 30, 2020 at 05:40:36PM +0200, Thierry Reding wrote:
> On Mon, Mar 30, 2020 at 03:34:50PM +0200, Clemens Gruber wrote:
> > Hi,
> > 
> > On Mon, Mar 30, 2020 at 03:07:57PM +0200, Thierry Reding wrote:
> > > On Wed, Feb 26, 2020 at 02:52:27PM +0100, Matthias Schiffer wrote:
> > > > The interaction of the ALL_LED PWM channel with the other channels was
> > > > not well-defined. As the ALL_LED feature does not seem very useful and
> > > > it was making the code significantly more complex, simply remove it.
> > > > 
> > > > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > > > ---
> > > >  drivers/pwm/pwm-pca9685.c | 115 ++++++--------------------------------
> > > >  1 file changed, 17 insertions(+), 98 deletions(-)
> > > 
> > > Applied, thanks.
> > > 
> > > Thierry
> > 
> > I was not reading the mailing list in the last weeks, so I only saw the
> > patch today.
> > 
> > We are using the ALL_LED channel in production to reduce the delay when
> > all 16 PWM outputs need to be set to the same duty cycle.
> > 
> > I am not sure it is a good idea to remove this feature.
> 
> Can you specify what platform this is and where the code is that does
> this. I can't really find any device tree users of this and I don't know
> if there's a good way to find out what other users there are, but this
> isn't the first time this driver has created confusion, so please help
> collect some more information about it's use so we can avoid this in the
> future.

The platform is ARM, it's a custom board with an NXP i.MX6. The device
tree is not upstreamed. As there are multiple companies involved
in changes to this driver, I assume that it is in use, even though there
are no in-tree users.
Also: As you can set the ALL channel from userspace, it will be very
difficult to find out how often the ALL feature is being used somewhere.

> 
> I'll back out this particular patch since you're using it. Can you give
> the other three patches a try to see if they work for you?

Thanks! I saw your other mail. Patch 1 looks good to me. I will look at
the new version of patches 3 and 4 and test them when they appear on the
list.

Clemens

  parent reply	other threads:[~2020-03-30 16:07 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 13:52 [PATCH 1/4] pwm: pca9685: remove unused duty_cycle struct element 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 [this message]
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       ` (EXT) " Matthias Schiffer
2020-04-08  8:00         ` 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=20200330160744.GA777@workstation.tuxnet \
    --to=clemens.gruber@pqgruber.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=matthias.schiffer@ew.tq-group.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 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.