linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sven Van Asbroeck <thesven73@gmail.com>
To: Clemens Gruber <clemens.gruber@pqgruber.com>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org, "Lee Jones" <lee.jones@linaro.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"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: Thu, 10 Dec 2020 16:37:01 -0500	[thread overview]
Message-ID: <CAGngYiVAKraGxOYe5bCNhzhPSvFMh5u7cZ-ENqzTv4kvbNjryw@mail.gmail.com> (raw)
In-Reply-To: <X9KK9UrXu+b8F+IT@workstation.tuxnet>

On Thu, Dec 10, 2020 at 3:54 PM Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
>
> After reading your reasoning in this mail and rethinking the whole
> situation, I do no longer have any objections to the more complex
> solution. (Allowing 0% and 100% duty cycle channels with any period)
>
> I first thought it would be too confusing to block users from changing a
> duty cycle when in reality the period is the problem.
> However, if we log an error message, explaining that the periods have to
> match if duty cycles > 0 and < 100% are used, I think it's OK.
>
> Uwe, Sven: Do you have any objections?

No objections, as long as the "fully flexible" solution doesn't get too
complex. Complex code is hard to maintain and extend, but obviously that
decision is for Thierry or Uwe to make.

Thinking this through a little bit, I don't think the "fully flexible"
solution has to be that complex. Keeping track of prescale-inuse may
have to involve a bitmask and not a counter, such as here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pwm/pwm-pca9685.c?h=v5.10-rc7#n81

That way, channels can do set_bit() to mark that they use the prescaler,
clear_bit() when giving up the prescaler, and if (bitmap_weight() <= 1) to
check if they can make a prescale change.

But this is theory - the only way to find out what's best, is to actually
write the code...

> If not, I will prepare a v5 next week.

Looking forward to it, thank you !!

  reply	other threads:[~2020-12-10 21:38 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
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 [this message]
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=CAGngYiVAKraGxOYe5bCNhzhPSvFMh5u7cZ-ENqzTv4kvbNjryw@mail.gmail.com \
    --to=thesven73@gmail.com \
    --cc=clemens.gruber@pqgruber.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).