linux-pwm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Clemens Gruber <clemens.gruber@pqgruber.com>
To: Sven Van Asbroeck <thesven73@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v5 2/7] pwm: pca9685: Support hardware readout
Date: Mon, 1 Feb 2021 18:24:02 +0100	[thread overview]
Message-ID: <YBg5MlvJQ0N2u+j6@workstation.tuxnet> (raw)
In-Reply-To: <CAGngYiV5GGJvHTwG7k6mv76uR1RLnHOJoO8+d2ofiZAQi3K0BA@mail.gmail.com>

Hi Sven, Thierry, Uwe,

On Fri, Jan 29, 2021 at 05:16:51PM -0500, Sven Van Asbroeck wrote:
> Hi Clemens,
> 
> On Fri, Jan 29, 2021 at 4:24 PM Sven Van Asbroeck <thesven73@gmail.com> wrote:
> >
> > LEN_ON = 409, LED_OFF = 1228 and
> > LED_ON = 419, LED_OFF = 1238
> > produce the same result. you can't see the difference between the two
> > when scoping the channel. there are probably more ways to do this,
> > some might surprise us. It's a tricky chip.
> 
> Please ignore this example, it's bogus. In my defence, it's a Friday
> afternoon here :)

Happens to the best of us :)

> 
> But consider the following: imagine the bootloader has enabled a few
> pwm channels, and the driver's .probe() has left them on/unchanged.
> Then the user enables another pwm channel, and tries to change the
> period/prescaler. How would pca9685_may_change_prescaler() know
> if changing the prescaler is allowed?
> 
> And the following: imagine the bootloader has enabled a few
> pwm channels, and the driver's .probe() has left them on/unchanged.
> After .probe(), the runtime_pm will immediately put the chip to sleep,
> because it's unaware that some channels are alive.

(We could read out the state in .probe. If a pwm is already enabled by
the bootloader, then the user can't change the period. Also, the chip
would not be put to sleep.

The user then can export channels and see if they are enabled. If he
wants to change the period, he needs to find the one enabled by the
bootloader and change the period there, before he requests more.
If the bootloader enabled more than one, then he has to disable all but
one to change the period.

Or did I miss something?)

> 
> I'm sure I'm overlooking a few complications here. probe not changing
> the existing configuration, will add a lot of complexity to the driver.
> I'm not saying this is necessarily bad, just a tradeoff. Or, a management
> decision.

But I agree that it is simpler if we keep the resets in probe. It would
also avoid a potentially breaking change for users that do not reset
their pca9685 chips in their bootloader code.
There might be users out there that depend on the driver to reset the
OFF registers in .probe.

If Thierry agrees / allows it, I can keep the resets for now.

Removing the resets could then be left as something to discuss further
in the future and something that belongs in a separate patch series?

Clemens

  reply	other threads:[~2021-02-01 17:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20201216125320.5277-1-clemens.gruber@pqgruber.com>
     [not found] ` <20201216125320.5277-2-clemens.gruber@pqgruber.com>
2020-12-17  4:00   ` [PATCH v5 2/7] pwm: pca9685: Support hardware readout Sven Van Asbroeck
2020-12-17 17:43     ` Clemens Gruber
2020-12-17 17:52       ` Sven Van Asbroeck
2021-01-03 17:04         ` Clemens Gruber
2021-01-07 14:18           ` Sven Van Asbroeck
2021-01-11 20:43           ` Uwe Kleine-König
2021-03-22  8:34             ` Thierry Reding
2021-03-31 10:25               ` Uwe Kleine-König
2021-03-31 15:52                 ` Thierry Reding
2021-04-06  6:33                   ` Uwe Kleine-König
2021-04-06 13:47                     ` Thierry Reding
2021-04-06 20:44                       ` Uwe Kleine-König
2021-03-22  8:15           ` Thierry Reding
2021-01-11 20:35       ` Uwe Kleine-König
2021-01-14 17:16         ` Clemens Gruber
2021-01-14 18:05           ` Uwe Kleine-König
2021-03-22  8:53           ` Thierry Reding
2021-01-29 13:42         ` Sven Van Asbroeck
2021-01-29 16:31           ` Clemens Gruber
2021-01-29 18:05             ` Sven Van Asbroeck
2021-01-29 20:37               ` Clemens Gruber
2021-01-29 21:24                 ` Sven Van Asbroeck
2021-01-29 22:16                   ` Sven Van Asbroeck
2021-02-01 17:24                     ` Clemens Gruber [this message]
2021-03-01 21:52                       ` Uwe Kleine-König
2021-03-04 13:22                         ` Clemens Gruber
2021-02-14 14:46                 ` Clemens Gruber
2021-03-22  9:19                 ` Thierry Reding
2021-03-22  9:38                   ` Andy Shevchenko
2021-03-22 11:22                     ` Uwe Kleine-König
2021-03-22 11:40                       ` Andy Shevchenko
2021-03-22 11:48                         ` Uwe Kleine-König
2021-03-22 12:15                           ` Andy Shevchenko
2021-03-22 13:25                             ` Uwe Kleine-König
2021-03-27 16:05                   ` Clemens Gruber
2021-03-22  9:14               ` Thierry Reding
2021-03-22  8:47         ` Thierry Reding
2020-12-15 21:22 [PATCH v5 1/7] pwm: pca9685: Switch to atomic API Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 2/7] pwm: pca9685: Support hardware readout 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=YBg5MlvJQ0N2u+j6@workstation.tuxnet \
    --to=clemens.gruber@pqgruber.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=thesven73@gmail.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).