linux-stable.git/drivers/pwm, branch v6.11

pwm: stm32: Use the right CCxNP bit in stm32_pwm_enable()

2024-09-05T09:12:01+00:00

The pwm devices for a pwm_chip are numbered starting at 0, the first hw
channel however has the number 1. While introducing a parametrised macro
to simplify register bit usage and making that offset explicit, one of
the usages was converted wrongly. This is fixed here.

Fixes: 7cea05ae1d4e ("pwm-stm32: Make use of parametrised register definitions")
Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20240905090627.197536-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

of: remove internal arguments from of_property_for_each_u32()

2024-07-25T11:53:47+00:00

The of_property_for_each_u32() macro needs five parameters, two of which
are primarily meant as internal variables for the macro itself (in the
for() clause). Yet these two parameters are used by a few drivers, and this
can be considered misuse or at least bad practice.

Now that the kernel uses C11 to build, these two parameters can be avoided
by declaring them internally, thus changing this pattern:

  struct property *prop;
  const __be32 *p;
  u32 val;

  of_property_for_each_u32(np, "xyz", prop, p, val) { ... }

to this:

  u32 val;

  of_property_for_each_u32(np, "xyz", val) { ... }

However two variables cannot be declared in the for clause even with C11,
so declare one struct that contain the two variables we actually need. As
the variables inside this struct are not meant to be used by users of this
macro, give the struct instance the noticeable name "_it" so it is visible
during code reviews, helping to avoid new code to use it directly.

Most usages are trivially converted as they do not use those two
parameters, as expected. The non-trivial cases are:

 - drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway
 - drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the
   checks had to be replicated in a different way, making code more verbose
   and somewhat uglier, but I refrained from a full rework to keep as much
   of the original code untouched having no hardware to test my changes

All the changes have been build tested. The few for which I have the
hardware have been runtime-tested too.

Reviewed-by: Andre Przywara  # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c
Acked-by: Bartosz Golaszewski  # drivers/gpio/gpio-brcmstb.c
Acked-by: Nicolas Ferre  # drivers/irqchip/irq-atmel-aic-common.c
Acked-by: Jonathan Cameron  # drivers/iio/adc/ti_am335x_adc.c
Acked-by: Uwe Kleine-König  # drivers/pwm/pwm-samsung.c
Acked-by: Richard Leitner  # drivers/usb/misc/usb251xb.c
Acked-by: Mark Brown  # sound/soc/codecs/arizona.c
Reviewed-by: Richard Fitzgerald  # sound/soc/codecs/arizona.c
Acked-by: Michael Ellerman  # arch/powerpc/sysdev/xive/spapr.c
Acked-by: Stephen Boyd  # clk
Signed-off-by: Luca Ceresoli 
Acked-by: Lee Jones 
Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com
Signed-off-by: Rob Herring (Arm)

pwm: axi-pwmgen: add .max_register to regmap

2024-07-11T13:44:40+00:00

This was missed in the basic driver and is useful for debug, so add it.

Example regmap output before the patch:

|root@zed-tg:~# cat /sys/kernel/debug/regmap/44a60000.pwm/registers
|0: 00020100

And with it:

|root@zed-tg:~# cat /sys/kernel/debug/regmap/44a60000.pwm/registers
|00: 00020100
|04: 00000000
|08: 00000000
|0c: 601a3471
|10: 00000000
|14: 00000002
|18: 00000001
|1c: 00000000
|...

Signed-off-by: Trevor Gamblin 
Link: https://lore.kernel.org/r/20240711125743.3956935-1-tgamblin@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: atmel-tcb: Make private data variable naming consistent

2024-07-10T15:55:38+00:00

Currently the variables of type struct atmel_tcb_pwm_device
are named "tcbpwm", and variables of type atmel_tcb_pwm_chip are either
named "tcbpwm" (too!) or "tcbpwmc". Rename the chips with device name to
"tcbpwmc" to get a consistent naming.

Signed-off-by: Uwe Kleine-König 
Acked-by: Nicolas Ferre 
Link: https://lore.kernel.org/r/20240709092221.47025-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: atmel-tcb: Simplify checking the companion output

2024-07-10T15:55:12+00:00

The two outputs provided by the supported hardware share some settings,
so access to the other PWM is required when one of them is configured.

Instead of an explicit if to deterimine the other PWM just use
hwpwm ^ 1. Further atcbpwm is never NULL, so drop the corresponding
check.

Signed-off-by: Uwe Kleine-König 
Acked-by: Nicolas Ferre 
Link: https://lore.kernel.org/r/20240709101806.52394-4-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Allow pwm state transitions from an invalid state

2024-07-10T15:53:52+00:00

While driving a PWM via the sysfs API it's hard to determine the right
order of writes to the pseudo files "period" and "duty_cycle":

If you want to go from duty_cycle/period = 50/100 to 150/300 you have to
write period first (because 150/100 is invalid). If however you start at
400/500 the duty_cycle must be configured first. The rule that works is:
If you increase period write period first, otherwise write duty_cycle
first. A complication however is that it's usually sensible to configure
the polarity before both period and duty_cycle. This can only be done if
the current state's duty_cycle and period configuration isn't bogus
though. It is still worse (but I think only theoretic) if you have a PWM
that only supports inverted polarity and you start with period = 0 and
polarity = normal. Then you can change neither period (because polarity
= normal is refused) nor polarity (because there is still period = 0).

To simplify the corner cases for userspace, let invalid target states
pass if the current state is invalid already.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20240628103519.105020-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: xilinx: Simplify using devm_ functions

2024-07-10T15:53:52+00:00

There are devm variants for clk_prepare_enable() and pwmchip_add(); and
clk_prepare_enable() can be done together with devm_clk_get(). This
allows to simplify the error paths in .probe() and drop .remove()
completely.

With the remove callback gone, the last user of platform_get_drvdata()
is gone and so the call to platform_set_drvdata() can be dropped, too.

Signed-off-by: Uwe Kleine-König 
Reviewed-by: Sean Anderson 
Link: https://lore.kernel.org/r/20240628063524.92907-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Use guards for pwm_lookup_lock instead of explicity mutex_lock + mutex_unlock

2024-07-10T15:53:52+00:00

With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/28807cb5d9dbce66860f74829c0f57cd9c01373e.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Use guards for export->lock instead of explicity mutex_lock + mutex_unlock

2024-07-10T15:53:52+00:00

With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.

There is just one caller left for mutex_lock(&export->lock). The code
flow is too complicated there to convert it to the compiler assisted
variant.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/210010f2e579a92476462726e18e0135f6854909.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Use guards for pwm_lock instead of explicity mutex_lock + mutex_unlock

2024-07-10T15:53:51+00:00

With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/2102fe8189bdf1f02ff3785b551a69be27a65af4.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König