linux-pwm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sven Van Asbroeck <thesven73@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Clemens Gruber <clemens.gruber@pqgruber.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	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: Fri, 29 Jan 2021 08:42:13 -0500	[thread overview]
Message-ID: <CAGngYiW=KhCOZX3tPMFykXzpWLpj3qusN2OXVPSfHLRcyts+wA@mail.gmail.com> (raw)
In-Reply-To: <20210111203532.m3yvq6e5bcpjs7mc@pengutronix.de>

On Mon, Jan 11, 2021 at 3:35 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> My position here is: A consumer should disable a PWM before calling
> pwm_put. The driver should however not enforce this and so should not
> modify the hardware state in .free().
>
> Also .probe should not change the PWM configuration.

I agree that this is the most user-friendly behaviour.

The problem however with the pca9685 is that it has many degrees of
freedom: there are many possible register values which produce the same
physical chip outputs.

This could lead to a situation where, if .probe() does not reset the register
values, subsequent writes may lead to different outputs than expected.

One possible solution is to write .get_state() so that it always reads the
correct state, even if "unconventional" register settings are present, i.e.
those written by an outside entity, e.g. a bootloader. Then write that
state back using driver conventions.

This may be trickier than it sounds - after all we've learnt that the pca9685
looks simple on the surface, but is actually quite challenging to get right.

Clemens, Uwe, what do you think?

Sven

  parent reply	other threads:[~2021-01-29 13:42 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 [this message]
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
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='CAGngYiW=KhCOZX3tPMFykXzpWLpj3qusN2OXVPSfHLRcyts+wA@mail.gmail.com' \
    --to=thesven73@gmail.com \
    --cc=clemens.gruber@pqgruber.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --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).