Merge tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

Pull pwm updates from Thierry Reding:
 "This contains a bunch of cleanups and simplifications across the
  board, as well as a number of small fixes.

  Perhaps the most notable change here is the addition of an API that
  allows PWMs to be used in atomic contexts, which is useful when time-
  critical operations are involved, such as using a PWM to generate IR
  signals.

  Finally, I have decided to step down as PWM subsystem maintainer. Due
  to other responsibilities I have lately not been able to find the time
  that the subsystem deserves and Uwe, who has been helping out a lot
  for the past few years and has many things planned for the future, has
  kindly volunteered to take over. I have no doubt that he will be a
  suitable replacement"

* tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
  MAINTAINERS: pwm: Thierry steps down, Uwe takes over
  pwm: linux/pwm.h: fix Excess kernel-doc description warning
  pwm: Add pwm_apply_state() compatibility stub
  pwm: cros-ec: Drop documentation for dropped struct member
  pwm: Drop two unused API functions
  pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs
  pwm: meson: Simplify using dev_err_probe()
  pwm: stmpe: Silence duplicate error messages
  pwm: Reduce number of pointer dereferences in pwm_device_request()
  pwm: crc: Use consistent variable naming for driver data
  pwm: omap-dmtimer: Drop locking
  dt-bindings: pwm: ti,pwm-omap-dmtimer: Update binding for yaml
  media: pwm-ir-tx: Trigger edges from hrtimer interrupt context
  pwm: bcm2835: Allow PWM driver to be used in atomic context
  pwm: Make it possible to apply PWM changes in atomic context
  pwm: renesas: Remove unused include
  pwm: Replace ENOTSUPP with EOPNOTSUPP
  pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
  pwm: Stop referencing pwm->chip
  pwm: Update kernel doc for struct pwm_chip
  ...

1 files changed, 13 insertions, 4 deletions

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index bb264490a87a..3c28ccc4b611 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -41,11 +41,20 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
 
 After being requested, a PWM has to be configured using::
 
-	int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+	int pwm_apply_might_sleep(struct pwm_device *pwm, struct pwm_state *state);
 
 This API controls both the PWM period/duty_cycle config and the
 enable/disable state.
 
+PWM devices can be used from atomic context, if the PWM does not sleep. You
+can check if this the case with::
+
+        bool pwm_might_sleep(struct pwm_device *pwm);
+
+If false, the PWM can also be configured from atomic context with::
+
+	int pwm_apply_atomic(struct pwm_device *pwm, struct pwm_state *state);
+
 As a consumer, don't rely on the output's state for a disabled PWM. If it's
 easily possible, drivers are supposed to emit the inactive state, but some
 drivers cannot. If you rely on getting the inactive state, use .duty_cycle=0,
@@ -57,13 +66,13 @@ If supported by the driver, the signal can be optimized, for example to improve
 EMI by phase shifting the individual channels of a chip.
 
 The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_might_sleep() and should not be used if the user wants to change
 several parameter at once. For example, if you see pwm_config() and
 pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_might_sleep().
 
 The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_might_sleep() using pwm_get_state(). Note this is
 different to what the driver has actually implemented if the request cannot be
 satisfied exactly with the hardware in use. There is currently no way for
 consumers to get the actually implemented settings.