All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "Clemens Gruber" <clemens.gruber@pqgruber.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Sven Van Asbroeck" <thesven73@gmail.com>
Subject: Re: (EXT) Re: (EXT) Re: [PATCH 1/4] pwm: pca9685: remove unused duty_cycle struct element
Date: Tue, 07 Apr 2020 15:00:43 +0200	[thread overview]
Message-ID: <189a1fb7f7aee153151f46fe3bb0f754160472e7.camel@ew.tq-group.com> (raw)
In-Reply-To: <20200406095124.GA475759@ulmo>

On Mon, 2020-04-06 at 11:51 +0200, Thierry Reding wrote:
> 
> On Sat, Apr 04, 2020 at 04:17:00PM -0400, Sven Van Asbroeck wrote:
> > 
> > It does look like we have a square peg (this chip) in a round hole
> > (the
> > standard assumptions the pwm core makes) ?
> 
> There are other chips where a single period is shared across multiple
> PWM channels. Typically what we do there is once a period is
> configured
> for a given channel, all subsequent PWM channel configurations must
> use
> the same period, or otherwise the driver will return an error code.
> 
> See for example:
> 
>   - stm32_pwm_config() in drivers/pwm/pwm-stm32.c
>   - lpc18xx_pwm_config() in drivers/pwm/pwm-lpc18xx-sct.c
>   - pwm_imx_tpm_apply_hw() in drivers/pwm/pwm-imx-tpm.c
>   - fsl_pwm_apply_config() in drivers/pwm/pwm-fsl-ftm.c
> 
> The rationale behind that is that we must not change a PWM
> configuration
> without a consumer having explicitly requested it.

These implementations don't deal with the issue in a consistent way
either though:

1) stm32_pwm_config() only checks for channels that are actually
enabled, regardless if they're requested

2) lpc18xx_pwm_config() checks requested channels instead

"2)" seems more correct to me, as the parameters of a requested channel
can't be changed by another user, but it seems to prevent certain
sequences. I don't have a good grasp of the the usual PWM request
control flow - is it correct that the PWM state is not updated with the
PWM args from OF when the PWM is requested? I only see
pwm_adjust_config() doing something like that, which is not used in
many places (and nothing preventing races) - but I might be overlooking
something.

Meaning, is it possible that two drivers request PWMs from the same
pwmchip of type "2)" (or even a single driver using two PWMs) without
configuring them right away may get into a situation where neither can
set up a period at all even when all users want to use the same period?

Matthias


  reply	other threads:[~2020-04-07 13:00 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
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               ` Matthias Schiffer [this message]
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=189a1fb7f7aee153151f46fe3bb0f754160472e7.camel@ew.tq-group.com \
    --to=matthias.schiffer@ew.tq-group.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=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 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.