Use the dedicated helper for comparing device names against strings.
Note, the current code has a check for the dev_name() against NULL.
With the current implementations of the device_add() and dev_set_name()
it most likely a theoretical assumption that that might happen, while
I don't see how. Hence, that check has simply been removed.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20241025142704.405340-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Implement workaround for ERR051198
(https://www.nxp.com/docs/en/errata/IMX8MN_0N14Y.pdf)
PWM output may not function correctly if the FIFO is empty when a new SAR
value is programmed.
Description:
When the PWM FIFO is empty, a new value programmed to the PWM Sample
register (PWM_PWMSAR) will be directly applied even if the current timer
period has not expired. If the new SAMPLE value programmed in the
PWM_PWMSAR register is less than the previous value, and the PWM counter
register (PWM_PWMCNR) that contains the current COUNT value is greater
than the new programmed SAMPLE value, the current period will not flip
the level. This may result in an output pulse with a duty cycle of 100%.
Workaround:
Program the current SAMPLE value in the PWM_PWMSAR register before
updating the new duty cycle to the SAMPLE value in the PWM_PWMSAR
register. This will ensure that the new SAMPLE value is modified during
a non-empty FIFO, and can be successfully updated after the period
expires.
Write the old SAR value before updating the new duty cycle to SAR. This
avoids writing the new value into an empty FIFO.
This only resolves the issue when the PWM period is longer than 2us
(or <500kHz) because write register is not quick enough when PWM period is
very short.
Reproduce steps:
cd /sys/class/pwm/pwmchip1/pwm0
echo 2000000000 > period # It is easy to observe by using long period
echo 1000000000 > duty_cycle
echo 1 > enable
echo 8000 > duty_cycle # One full high pulse will be seen by scope
Fixes: 166091b189 ("[ARM] MXC: add pwm driver for i.MX SoCs")
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20241008194123.1943141-1-Frank.Li@nxp.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Enable the FORCE_ALIGN flag by default in the AXI PWMGEN driver. This
flag makes the behavior of the PWM output consistent with the
description at the top of the driver file.
* Limitations:
* - The writes to registers for period and duty are shadowed until
* LOAD_CONFIG is written to AXI_PWMGEN_REG_RSTN, at which point
* they take effect.
* - Writing LOAD_CONFIG also has the effect of re-synchronizing all
* enabled channels, which could cause glitching on other channels. It
* is therefore expected that channels are assigned harmonic periods
* and all have a single user coordinating this.
Without this flag, the PWM output does not change until the period of
all PWM output channels has run out, which makes the PWM impossible to
use in some cases because it takes too long to change the output.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20241009-pwm-axi-pwmgen-enable-force_align-v1-2-5d6ad8cbf5b4@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Rename the 0x10 register from REG_CONFIG to REG_RSTN. Also rename the
associated bit macros accordingly.
While touching this, move the bit macros close to the register address
macro for better organization.
According to [1], the name of the 0x10 register is REG_RSTN, and there
is a different register named REG_CONFIG (0x18). So we should not be
using REG_CONFIG for the 0x10 register to avoid confusion.
[1]: http://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.html
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20241009-pwm-axi-pwmgen-enable-force_align-v1-1-5d6ad8cbf5b4@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Support a new abstraction for pwm configuration that allows to specify
the time between start of period and the raising edge of the signal
("duty offset").
This is used in a patch series by Trevor Gamblin for triggering an ADC
conversion and afterwards read out the result. See
https://lore.kernel.org/linux-iio/20240909-ad7625_r1-v5-0-60a397768b25@baylibre.com/
for more details.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmcDeZsACgkQj4D7WH0S
/k7gqwf+LcXVzZ9APuhh7hYVMBKvM0f0VhihGBlTS/1hXdA/807Ooe0+VIlxAdBi
im6nIQzS6JWwkowYro0MRB5JWQgRUwDMdwhIKP8lFU+jRZs+TOjeCGs6bolgw+26
rLd7hpWTo3m9PD0Hp+y8xQq999ALaBIcAtrJM/Mop7YKa2FJvTwLtirH9rOImDVc
Vkdx36N870gzOAUSNSghWlSFATJp2fWc7T51XhBLBzVShZQ6cCy9oRJ8mZdPjcf0
hq8HwhVkKHMZidYo9KZpa10qz5S4diLUt6yr01LcmSNGgoqsWHWPFhcmAn2j64ok
pmC8NxY0HSgwgkxQxjDmBZe3eW2Wiw==
=C4Cy
-----END PGP SIGNATURE-----
Merge tag 'pwm/duty_offset-for-6.13-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux
pwm: Support for duty_offset
Support a new abstraction for pwm configuration that allows to specify
the time between start of period and the raising edge of the signal
("duty offset").
This is used in a patch series by Trevor Gamblin for triggering an ADC
conversion and afterwards read out the result. See
https://lore.kernel.org/linux-iio/20240909-ad7625_r1-v5-0-60a397768b25@baylibre.com/
for more details.
Compared to direct calls to pwmchip_get_drvdata() a dedicated function
has two upsides: A better name and the right type. So the code becomes
easier to read and the new function is harder to use wrongly.
Another side effect (which is the secret motivation for this patch, but
shhh) is that the driver becomes a bit easier to backport to kernel
versions that don't have devm_pwmchip_alloc() yet.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com>
Link: https://lore.kernel.org/r/20240923125418.16558-2-u.kleine-koenig@baylibre.com
[ukleinek: added an * to the new function's prototype to make the compiler happy]
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Use the min() macro to simplify the atmel_tcb_pwm_apply() function
and improve its readability.
Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>
Link: https://lore.kernel.org/r/20240827075749.67583-1-shenlichuan@vivo.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The modulo register defines the period of the edge-aligned PWM mode
(which is the only mode implemented). The reference manual states:
"The EPWM period is determined by (MOD + 0001h) ..." So the value that
is written to the MOD register must therefore be one less than the
calculated period length. Return -EINVAL if the calculated length is
already zero.
A correct MODULO value is particularly relevant if the PWM has to output
a high frequency due to a low period value.
Fixes: 738a1cfec2 ("pwm: Add i.MX TPM PWM driver support")
Cc: stable@vger.kernel.org
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
Link: https://lore.kernel.org/r/1a3890966d68b9f800d457cbf095746627495e18.camel@iris-sensing.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
This moves pwm_get() and friends above the functions handling
registration of pwmchips. The motivation is that character device
support needs pwm_get() and pwm_put() and so ideally is defined below
these and when a pwmchip is registered this registers the character
device. So the natural order is
pwm_get() and friend
pwm character device symbols
pwm_chip functions
. The advantage of having these in their natural order is that static
functions don't need to be forward declared.
Note that the diff that git produces for this change some functions are
moved down instead. This is technically equivalent, but not how this
change was created.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/193b3d933294da34e020650bff93b778de46b1c5.1726819463.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Provide API functions for consumers to work with waveforms.
Note that one relevant difference between pwm_get_state() and
pwm_get_waveform*() is that the latter yields the actually configured
hardware state, while the former yields the last state passed to
pwm_apply*() and so doesn't account for hardware specific rounding.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Link: https://lore.kernel.org/r/6c97d27682853f603e18e9196043886dd671845d.1726819463.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Up to now the configuration of a PWM setting is described exclusively by
a struct pwm_state which contains information about period, duty_cycle,
polarity and if the PWM is enabled. (There is another member usage_power
which doesn't completely fit into pwm_state, I ignore it here for
simplicity.)
Instead of a polarity the new abstraction has a member duty_offset_ns
that defines when the rising edge happens after the period start. This
is more general, as with a pwm_state the rising edge can only happen at
the period's start or such that the falling edge is at the end of the
period (i.e. duty_offset_ns == 0 or duty_offset_ns == period_length_ns -
duty_length_ns).
A disabled PWM is modeled by .period_length_ns = 0. In my eyes this is a
nice usage of that otherwise unusable setting, as it doesn't define
anything about the future which matches the fact that consumers should
consider the state of the output as undefined and it's just there to say
"No further requirements about the output, you can save some power.".
Further I renamed period and duty_cycle to period_length_ns and
duty_length_ns. In the past there was confusion from time to time about
duty_cycle being measured in nanoseconds because people expected a
percentage of period instead. With "length_ns" as suffix the semantic
should be more obvious to people unfamiliar with the pwm subsystem.
period is renamed to period_length_ns for consistency.
The API for consumers doesn't change yet, but lowlevel drivers can
implement callbacks that work with pwm_waveforms instead of pwm_states.
A new thing about these callbacks is that the calculation of hardware
settings needed to implement a certain waveform is separated from
actually writing these settings. The motivation for that is that this
allows a consumer to query the hardware capabilities without actually
modifying the hardware state.
The rounding rules that are expected to be implemented in the
round_waveform_tohw() are: First pick the biggest possible period not
bigger than wf->period_length_ns. For that period pick the biggest
possible duty setting not bigger than wf->duty_length_ns. Third pick the
biggest possible offset not bigger than wf->duty_offset_ns. If the
requested period is too small for the hardware, it's expected that a
setting with the minimal period and duty_length_ns = duty_offset_ns = 0
is returned and this fact is signaled by a return value of 1.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Link: https://lore.kernel.org/r/df0faa33bf9e7c9e2e5eab8d31bbf61e861bd401.1726819463.git.u.kleine-koenig@baylibre.com
[ukleinek: Update pwm_check_rounding() to return bool instead of int.]
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
This ensures that a pwm_chip that has no corresponding driver isn't used
and that a driver doesn't go away while a callback is still running.
In the presence of device links this isn't necessary yet (so this is no
fix) but for pwm character device support this is needed.
To not serialize all pwm_apply_state() calls, this introduces a per chip
lock. An additional complication is that for atomic chips a mutex cannot
be used (as pwm_apply_atomic() must not sleep) and a spinlock cannot be
held while calling an operation for a sleeping chip. So depending on the
chip being atomic or not a spinlock or a mutex is used.
An additional change implemented here is that on driver remove the
.free() callback is called for each requested pwm_device. This is the
right time because later (e.g. when the consumer calls pwm_put()) the
free function is (maybe) not available any more.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/026aa891c8270a11723a1ba7e4256f456f7e1e86.1726819463.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
This concludes a long journey towards replacing the old
board files with devictree description on the Cirrus Logic
EP93xx platform.
Nikita Shubin has been working on this for a long time,
for details see the last post on
https://lore.kernel.org/lkml/20240909-ep93xx-v12-0-e86ab2423d4b@maquefel.me/
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmb1croACgkQYKtH/8kJ
UicY0g//XXEXcBgE2CLfKzGimN3gREIElEqFCpd7v32XWGIQNFdS7StiGqNx1MeU
UYdILm97ldgpx+NnHd3Cb9HbLQ1CTIIvAZ2ngFLDeeZO+wgzBVxWTrdUUp57ZIBn
5Fq0hNaR1bfqSr+J+ZbgizH5N96EvLr3OPz/eJetY7egVBUID/0OpwssPJxW1Ns0
f+W+yIc7BomVa71xGgI+RkHrG/5DSaoFtrB+ESt7q1nNUIeMn32JqBYqE0U2iCRN
ADO8I+WfAjIcO1uN5n3KM3tigZI3GKSrBdllByr8wWNbp9l5rMYfFAPEaI109iyI
7PFrB6qhAlY9LckXMNhwLyjlnWt6qrI0B+tyg+3tW6+4OwFnpPN0cIhszFPOmrhv
njsDSvybp0q9V6Mn7f394H6v9sk9RHr68mpu12hO65UBP7Qe7mrdl3snnFcm0FHL
jCLnvjdmCSqRlV6YFsKDHuDzZOG88sAwH0mySKd3c/CVvgaNDsaJduelPGpuXlXX
P7op6D8kyKFKfmwK0kz3t+3+2ozgYq3nu4amI7rJ72MOvJKBocTwwqpAesIuegde
bn3ZN30yZDTbfEFuveOAzx7rqDlZYX/tN0uspL4VBN0rdayxBng5hneV2PypTtW0
wE9ptz5qIz8AssJ7NInwpgRTDjEut4SY3m3CS2/66V08B4EznAA=
=Y3Cd
-----END PGP SIGNATURE-----
Merge tag 'soc-ep93xx-dt-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC update from Arnd Bergmann:
"Convert ep93xx to devicetree
This concludes a long journey towards replacing the old board files
with devictree description on the Cirrus Logic EP93xx platform.
Nikita Shubin has been working on this for a long time, for details
see the last post on
https://lore.kernel.org/lkml/20240909-ep93xx-v12-0-e86ab2423d4b@maquefel.me/"
* tag 'soc-ep93xx-dt-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (47 commits)
dt-bindings: gpio: ep9301: Add missing "#interrupt-cells" to examples
MAINTAINERS: Update EP93XX ARM ARCHITECTURE maintainer
soc: ep93xx: drop reference to removed EP93XX_SOC_COMMON config
net: cirrus: use u8 for addr to calm down sparse
dmaengine: cirrus: use snprintf() to calm down gcc 13.3.0
dmaengine: ep93xx: Fix a NULL vs IS_ERR() check in probe()
pinctrl: ep93xx: Fix raster pins typo
spi: ep93xx: update kerneldoc comments for ep93xx_spi
clk: ep93xx: Fix off by one in ep93xx_div_recalc_rate()
clk: ep93xx: add module license
dmaengine: cirrus: remove platform code
ASoC: cirrus: edb93xx: Delete driver
ARM: ep93xx: soc: drop defines
ARM: ep93xx: delete all boardfiles
ata: pata_ep93xx: remove legacy pinctrl use
pwm: ep93xx: drop legacy pinctrl
ARM: ep93xx: DT for the Cirrus ep93xx SoC platforms
ARM: dts: ep93xx: Add EDB9302 DT
ARM: dts: ep93xx: add ts7250 board
ARM: dts: add Cirrus EP93XX SoC .dtsi
...
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all pwm drivers to use .remove(), with the eventual goal to drop
struct platform_driver::remove_new(). As .remove() and .remove_new() have
the same prototypes, conversion is done by just changing the structure
member name in the driver initializer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240909073125.382040-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Drop the trailing comma in the terminator entry for the ID table to make
code robust against misrebases.
Signed-off-by: Liao Chen <liaochen4@huawei.com>
Link: https://lore.kernel.org/r/20240831075059.790861-3-liaochen4@huawei.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based
on the alias from of_device_id table.
Signed-off-by: Liao Chen <liaochen4@huawei.com>
Link: https://lore.kernel.org/r/20240831075059.790861-2-liaochen4@huawei.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Use of_property_read_bool() to read boolean properties rather than
of_get_property(). This is part of a larger effort to remove callers
of of_get_property() and similar functions. of_get_property() leaks
the DT property data pointer which is a problem for dynamically
allocated nodes which may be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240731191312.1710417-25-robh@kernel.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
It turns out that OSC_EN bit in GERNERAL_CFG register has to be set to 1
when PWM state is enabled, otherwise PWM signal won't be generated.
Fixes: e9b503879f ("pwm: adp5585: Add Analog Devices ADP5585 support")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20240826083337.1835405-1-victor.liu@nxp.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The return value from the call to of_property_count_u32_elems() is int.
However, the return value is being assigned to an u32 variable
'num_outputs', so making 'num_outputs' an int.
./drivers/pwm/pwm-lp3943.c:238:6-17: WARNING: Unsigned expression compared with zero: num_outputs <= 0.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9710
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Fixes: 75f0cb339b ("pwm: lp3943: Use of_property_count_u32_elems() to get property length")
Link: https://lore.kernel.org/r/20240809080523.32717-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Replace of_get_property() with the type specific
of_property_count_u32_elems() to get the property length.
This is part of a larger effort to remove callers of of_get_property()
and similar functions. of_get_property() leaks the DT property data
pointer which is a problem for dynamically allocated nodes which may
be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240731201407.1838385-8-robh@kernel.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
There is only a single caller of this function, and that's in
drivers/pwm/core.c itself. So don't export the function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240712171821.1470833-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
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: 7cea05ae1d ("pwm-stm32: Make use of parametrised register definitions")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240905090627.197536-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The ADP5585 is a 10/11 input/output port expander with a built in keypad
matrix decoder, programmable logic, reset generator, and PWM generator.
This driver supports the PWM function using the platform device
registered by the core MFD driver.
The driver is derived from an initial implementation from NXP, available
in commit 113113742208 ("MLK-25922-1 pwm: adp5585: add adp5585 PWM
support") in their BSP kernel tree. It has been extensively rewritten.
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Link: https://lore.kernel.org/r/20240722121100.2855-5-laurent.pinchart@ideasonboard.com
Signed-off-by: Lee Jones <lee@kernel.org>
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 <andre.przywara@arm.com> # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # drivers/gpio/gpio-brcmstb.c
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # drivers/irqchip/irq-atmel-aic-common.c
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # drivers/iio/adc/ti_am335x_adc.c
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> # drivers/pwm/pwm-samsung.c
Acked-by: Richard Leitner <richard.leitner@linux.dev> # drivers/usb/misc/usb251xb.c
Acked-by: Mark Brown <broonie@kernel.org> # sound/soc/codecs/arizona.c
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> # sound/soc/codecs/arizona.c
Acked-by: Michael Ellerman <mpe@ellerman.id.au> # arch/powerpc/sysdev/xive/spapr.c
Acked-by: Stephen Boyd <sboyd@kernel.org> # clk
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
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 <tgamblin@baylibre.com>
Link: https://lore.kernel.org/r/20240711125743.3956935-1-tgamblin@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
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 <u.kleine-koenig@baylibre.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20240709092221.47025-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
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 <u.kleine-koenig@baylibre.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20240709101806.52394-4-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
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 <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240628103519.105020-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
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 <u.kleine-koenig@baylibre.com>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
Link: https://lore.kernel.org/r/20240628063524.92907-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
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 <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/210010f2e579a92476462726e18e0135f6854909.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
While the debugfs operations don't technically depend on an initialized
class, they loop over the idr that only can get entries when the class
is properly initialized.
This also fixes the ugly (but harmless) corner case that the debugfs
file stays around after the pwm class failed to initialize.
While at it, add an appropriate error message when class initialization
fails.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240626222529.2901200-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Apply the pinctrl setting of sleep state when system enters
suspend state.
Restore to the default pinctrl setting when system resumes.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Link: https://lore.kernel.org/r/20240702164514.11007-1-shenwei.wang@nxp.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
We no longer need empty runtime PM handles for PCI devices after
commits [1] and [2]. Drop them and let PCI core take care of power
state transitions.
[1] c5eb119007 ("PCI / PM: Allow runtime PM without callback functions")
[2] fa885b06ec ("PCI/PM: Allow runtime PM with no PM callbacks at all")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Link: https://lore.kernel.org/r/20240605131533.20037-3-raag.jadav@intel.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
There is no semantic change, but it is a nicer on the eyes of a reader,
because
TIM_CCR1 + 4 * ch
encodes internal register knowledge, while
TIM_CCRx(ch + 1)
keeps that information completely in the header defining the registers.
While I expected this to not result in any changes in the binary, gcc 13
(as provided by Debian in the gcc-13-arm-linux-gnueabihf 13.2.0-12cross1
package) compiles the new version with an allmodconfig to more compact
code:
$ source/scripts/bloat-o-meter drivers/pwm/pwm-stm32.o-pre drivers/pwm/pwm-stm32.o
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-488 (-488)
Function old new delta
stm32_pwm_get_state 968 936 -32
stm32_pwm_apply_locked 1920 1464 -456
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/d7ef7a6158df4ba6687233b0e00d37796b069fb3.1718791090.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add a software PWM which toggles a GPIO from a high-resolution timer.
This will naturally not be as accurate or as efficient as a hardware
PWM, but it is useful in some cases. I have for example used it for
evaluating LED brightness handling (via leds-pwm) on a board where the
LED was just hooked up to a GPIO, and for a simple verification of the
timer frequency on another platform.
Since high-resolution timers are used, sleeping GPIO chips are not
supported and are rejected in the probe function.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Co-developed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Co-developed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20240604-pwm-gpio-v7-2-6b67cf60db92@linaro.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The last user of this function outside of core.c is gone, so it can be
made static.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20240607084416.897777-8-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The cros-ec device tree binding only uses #pwm-cells = <1>, and so there
is no period provided in the device tree. Up to now this was handled by
hardcoding the period to the only supported value in the custom xlate
callback. Apart from that, the default xlate callback (i.e.
of_pwm_xlate_with_flags()) handles this just fine (and better, e.g. by
checking args->args_count >= 1 before accessing args->args[0]).
To simplify make use of of_pwm_xlate_with_flags(), drop the custom
callback and provide the default period in .probe() already.
Apart from simplifying the driver this also drops the last non-core user
of pwm_request_from_chip() and so makes further simplifications
possible.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20240607084416.897777-7-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The get_state() callback is never called (in a visible way) after there
is a consumer for a pwm device. The core handles loosing the information
about duty_cycle just fine.
Simplify the driver accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20240607084416.897777-6-u.kleine-koenig@baylibre.com
[Drop kdoc comment for channel to make W=1 builds happy]
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Define all pwm core's symbols in the namespace "PWM". The necessary
module import statement is just added to the main header, this way every
file that knows about the public functions automatically has this
namespace available.
Thanks to Biju Das for pointing out a cut'n'paste failure in my initial
patch.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240607160012.1206874-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-imx1.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-imx27.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-intel-lgm.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-mediatek.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-pxa.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-samsung.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-spear.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-visconti.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240610-md-drivers-pwm-v2-1-b337cfaa70ea@quicinc.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Similar to commit 7d91999954 ("pwm: jz4740: Use
regmap_{set,clear}_bits") convert two more regmap_update_bits() calls to
regmap_{set,clear}_bits() which were missed back then.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20240606164047.534741-5-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add support for the Analog Devices AXI PWM Generator. This device is an
FPGA-implemented peripheral used as PWM signal generator and can be
interfaced with AXI4. The register map of this peripheral makes it
possible to configure the period and duty cycle of the output signal.
Link: https://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.html
Co-developed-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Co-developed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Co-developed-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Link: https://lore.kernel.org/r/20240605203507.1934434-3-tgamblin@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The hardware only supports a single period length for both PWM outputs. So
atmel_tcb_pwm_config() checks the configuration of the other output if it's
compatible with the currently requested setting. The register values are
then actually updated in atmel_tcb_pwm_enable(). To make this race free
the lock must be held during the whole process, so grab the lock in
.apply() instead of individually in atmel_tcb_pwm_disable() and
atmel_tcb_pwm_enable() which then also covers atmel_tcb_pwm_config().
To simplify handling, use the guard helper to let the compiler care for
unlocking. Otherwise unlocking would be more difficult as there is more
than one exit path in atmel_tcb_pwm_apply().
Fixes: 9421bade07 ("pwm: atmel: add Timer Counter Block PWM driver")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20240709101806.52394-3-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
When the state changes from enabled to disabled, polarity, duty_cycle
and period are not configured in hardware and TIM_CCER_CCxE is just
cleared. However if the state changes from one disabled state to
another, all parameters are written to hardware because the early exit
from stm32_pwm_apply() is only taken if the pwm is currently enabled.
This yields surprises like: Applying
{ .period = 1, .duty_cycle = 0, .enabled = false }
succeeds if the pwm is initially on, but fails if it's already off
because 1 is a too small period.
Update the check for lazy disable to always exit early if the target
state is disabled, no matter what is currently configured.
Fixes: 7edf736920 ("pwm: Add driver for STM32 plaftorm")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240703110010.672654-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
"Failed to lock the clock" is an appropriate error message for
clk_rate_exclusive_get() failing, but not for the clock running too
fast for the driver's calculations.
Adapt the error message accordingly.
Fixes: d44d635635 ("pwm: stm32: Fix for settings using period > UINT32_MAX")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/285182163211203fc823a65b180761f46e828dcb.1718979150.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
A small prescaler is beneficial, as this improves the resolution of the
duty_cycle configuration. However if the prescaler is too small, the
maximal possible period becomes considerably smaller than the requested
value.
One situation where this goes wrong is the following: With a parent
clock rate of 208877930 Hz and max_arr = 0xffff = 65535, a request for
period = 941243 ns currently results in PSC = 1. The value for ARR is
then calculated to
ARR = 941243 * 208877930 / (1000000000 * 2) - 1 = 98301
This value is bigger than 65535 however and so doesn't fit into the
respective register field. In this particular case the PWM was
configured for a period of 313733.4806027616 ns (with ARR = 98301 &
0xffff). Even if ARR was configured to its maximal value, only period =
627495.6861167669 ns would be achievable.
Fix the calculation accordingly and adapt the comment to match the new
algorithm.
With the calculation fixed the above case results in PSC = 2 and so an
actual period of 941229.1667195285 ns.
Fixes: 8002fbeef1 ("pwm: stm32: Calculate prescaler with a division instead of a loop")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/b4d96b79917617434a540df45f20cb5de4142f88.1718979150.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The driver doesn't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also remove the trailing commas after the sentinel entry.
Link: https://lore.kernel.org/r/20240508130618.2148631-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
While calculating frequency for the given period u64 numbers are
multiplied before division what can lead to overflow in theory so use
secure mul_u64_u64_div_u64() which handles overflow correctly.
Fixes: 329db102a2 ("pwm: meson: make full use of common clock framework")
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: George Stark <gnstark@salutedevices.com>
Link: https://lore.kernel.org/r/20240425171253.2752877-4-gnstark@salutedevices.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
clk_round_rate() can return not only zero if requested frequency can not
be provided but also negative error code so add check for it too.
Also change type of variable holding clk_round_rate() result from
unsigned long to long. It's safe due to clk_round_rate() returns long.
Fixes: 329db102a2 ("pwm: meson: make full use of common clock framework")
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Signed-off-by: George Stark <gnstark@salutedevices.com>
Link: https://lore.kernel.org/r/20240425171253.2752877-3-gnstark@salutedevices.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Drop checking state argument for NULL pointer in meson_pwm_get_state()
due to it is called only from pwm core with always valid arguments.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Signed-off-by: George Stark <gnstark@salutedevices.com>
Link: https://lore.kernel.org/r/20240425171253.2752877-2-gnstark@salutedevices.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Introduce a new compatible support in the Amlogic PWM driver.
The PWM HW is actually the same for all SoCs supported so far. A specific
compatible is needed only because the clock sources of the PWMs are
hard-coded in the driver.
It is better to have the clock source described in DT but this changes the
bindings so a new compatible must be introduced.
When all supported platform have migrated to the new compatible, support
for the legacy ones may be removed from the driver.
The addition of this new compatible makes the old ones obsolete, as
described in the DT documentation.
Adding a callback to setup the clock will also make it easier to add
support for the new PWM HW found in a1, s4, c3 and t7 SoC families.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20240221151154.26452-6-jbrunet@baylibre.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
stm32_pwm_config() took the duty_cycle and period values with the type
int, however stm32_pwm_apply() passed u64 values there. Expand the
function parameters to u64 to not discard relevant bits and adapt the
calculations to the wider type.
To ensure the calculations won't overflow, check in .probe() the input
clk doesn't run faster than 1 GHz.
Link: https://lore.kernel.org/r/06b4a650a608d0887d934c1b2b8919e0f78e4db2.1710711976.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
While mathematically it's ok to calculate the number of cyles for the
duty cycle as:
duty_cycles = period_cycles * duty_ns / period_ns
this doesn't always give the right result when doing integer math. This
is best demonstrated using an example: With the input clock running at
208877930 Hz a request for duty_cycle = 383 ns and period = 49996 ns
results in
period_cycles = clkrate * period_ns / NSEC_PER_SEC = 10443.06098828
Now calculating duty_cycles with the above formula gives:
duty_cycles = 10443.06098828 * 383 / 49996 = 80.00024719
However with period_cycle truncated to an integer results in:
duty_cycles = 10443 * 383 / 49996 = 79.99977998239859
So while a value of (a little more than) 80 would be the right result,
only 79 is used here. The problem here is that 14443 is a rounded result
that should better not be used to do further math. So to fix that use
the exact formular similar to how period_cycles is calculated.
Link: https://lore.kernel.org/r/7628ecd8a7538aa5a7397f0fc4199a077168e8a6.1710711976.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Giving an indication about the problem if probing a device fails is a
nice move. Do that for the stm32 pwm driver.
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20240315145443.982807-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
After assigning chip = pwm->chip; the compiler is free to assume that
pwm is non-NULL and so can optimize out the check for pwm against NULL.
While it's probably a programming error to pass a NULL pointer to
pwm_put() this shouldn't be dropped without careful consideration and
wasn't intended.
So assign chip only after the NULL check.
Reported-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/66a6f562-1fdd-4e45-995a-e7995432aa0c@baylibre.com
Fixes: 4c56b1434b ("pwm: Add a struct device to struct pwm_chip")
Link: https://lore.kernel.org/r/20240329101648.544155-2-u.kleine-koenig@pengutronix.de
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
It's required to not free the memory underlying a requested PWM
while a consumer still has a reference to it. While currently a pwm_chip
doesn't live long enough in all cases, linking the struct pwm to the
pwm_chip results in the right lifetime as soon as the pwmchip is living
long enough. This happens with the following commits.
Note this is a breaking change for all pwm drivers that don't use
pwmchip_alloc().
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> # for struct_size() and __counted_by()
Link: https://lore.kernel.org/r/7e9e958841f049026c0023b309cc9deecf0ab61d.1710670958.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
With the upcoming restructuring having all in a single file simplifies
things a bit. The relevant and somewhat visible changes are:
- Some dropped prototypes from include/linux/pwm.h that were only
necessary that core.c has a declaration of the symbols defined in
sysfs.c. The respective functions are static now.
- The pwm class now also exists if CONFIG_SYSFS isn't enabled. Having
CONFIG_SYSFS is not very relevant today, but even without it the
class and device stuff still provides lifetime tracking.
- Both files had an initcall, these are merged into a single one now.
Instead of a big #ifdef block for CONFIG_DEBUG_FS, a single
if (IS_ENABLED(CONFIG_DEBUG_FS)) is used now. This increases compile
coverage a bit and is a tad nicer on the eyes.
Link: https://lore.kernel.org/r/9e2d39a5280d7dda5bfc6682a8aef510148635b2.1710670958.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The code handling the sysfs API uses "child" and "parent" to refer to
the devices corresponding to a struct pwm or a struct pwm_chip
respectively.
Other parts of the pwm core use "parent" to refer to the parent device of
a struct pwm_chip.
So rename "child" to "pwm_dev" and "parent" to "pwmchip_dev" which
better explains the semantic. Also two functions are changed to match
the new names:
child_to_pwm_export() -> pwmexport_from_dev()
child_to_pwm_device() -> pwm_from_dev()
(which have the additional advantage to start with "pwm" which gives the
right scope). Additionally introduce a wrapper for dev_get_drvdata() to
convert a pwmchip_dev to the respective pwm_chip.
Link: https://lore.kernel.org/r/9cc05aceeae2f06ecb850bccb15ba821e768c183.1710670958.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
While the compiler probably optimizes out the pointer dereference, using
the local variable holding the same value also benefits the human
reader. So simplify accordingly. Also move a loop over all capture lines
into the capture if block to group the operations related to capturing
in .probe().
Link: https://lore.kernel.org/r/a7a81f3838f7ed7f4d6dbee3d646989cc265f676.1710068192.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This has the advantage of handling EPROBE_DEFER correctly and being more
compact.
This change also introduces an error message for a few error paths that
lacked an error indicator before. Also sti_pwm_probe_dt() is renamed to
sti_pwm_probe_regmap() to better fit what it actually does.
Link: https://lore.kernel.org/r/8e540733ab882f2b8873712faf85c4f0cb48133a.1710068192.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has
several advantages:
- Combines getting the clock and a call to clk_prepare(). The latter
can be dropped from sti_pwm_probe() accordingly.
- Cares for calling clk_put() which is missing in both probe's error
path and the remove function.
- Cares for calling clk_unprepare() which can be dropped from the error
paths and the remove function. (Note that not all error path got this
right.)
With additionally using devm_pwmchip_add() instead of pwmchip_add() the
remove callback can be dropped completely. With it the last user of
platform_get_drvdata() goes away and so platform_set_drvdata() can be
dropped from the probe function, too.
Fixes: 378fe115d1 ("pwm: sti: Add new driver for ST's PWM IP")
Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Memory holding a struct device must not be freed before the reference
count drops to zero. So a struct pwm_chip must not live in memory
freed by a driver on unbind. All in-tree drivers were fixed accordingly,
but as out-of-tree drivers, that were not adapted, still compile fine,
catch these in pwmchip_add().
Link: https://lore.kernel.org/r/35f5b229c98f78b2f6ce2397259a4a936be477c0.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
With 16 channel pwm support, we're registering two instances of pwm_chip
with 8 channels each. We need to update PM functions to use both instances
of pwm_chip during power state transitions.
Introduce struct dwc_pwm_drvdata and use it as driver_data, which will
maintain both instances of pwm_chip along with dwc_pwm_info and allow us
to use them inside suspend/resume handles.
Fixes: ebf2c89eb9 ("pwm: dwc: Add 16 channel support for Intel Elkhart Lake")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240415074051.14681-1-raag.jadav@intel.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
22e8e19 has introduced a regression in the imgchip->pwm_clk lookup, whereas
the clock name has also been renamed to "imgchip". This causes the driver
failing to load:
[ 0.546905] img-pwm 18101300.pwm: failed to get imgchip clock
[ 0.553418] img-pwm: probe of 18101300.pwm failed with error -2
Fix this lookup by reverting the clock name back to "pwm".
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Link: https://lore.kernel.org/r/20240320083602.81592-1-wigyori@uid0.hu
Fixes: 22e8e19a46 ("pwm: img: Rename variable pointing to driver private data")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The following commit abf6569d64 ("pwm: imx-tpm: Make use of
devm_pwmchip_alloc() function") introduced an issue that accessing
registers without clock which results in the following boot crash
on MX7ULP platform. Fixed it by enabling clock properly.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0978004
[f0978004] *pgd=64009811, *pte=40250653, *ppte=40250453
Internal error: : 1008 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc6-next-20240301 #18
Hardware name: Freescale i.MX7ULP (Device Tree)
PC is at pwm_imx_tpm_probe+0x1c/0xd8
LR is at __devm_ioremap_resource+0xf8/0x1dc
pc : [<c0629e58>] lr : [<c0562d4c>] psr: 80000053
sp : f0825e10 ip : 00000000 fp : 00000000
r10: c148f8c0 r9 : c41fc338 r8 : c164b000
r7 : 00000000 r6 : c406b400 r5 : c406b410 r4 : f0978000
r3 : 00000005 r2 : 00000000 r1 : a0000053 r0 : f0978000
Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6000406a DAC: 00000051
...
Call trace:
pwm_imx_tpm_probe from platform_probe+0x58/0xb0
platform_probe from really_probe+0xc4/0x2e0
really_probe from __driver_probe_device+0x84/0x19c
__driver_probe_device from driver_probe_device+0x2c/0x104
driver_probe_device from __driver_attach+0x90/0x170
__driver_attach from bus_for_each_dev+0x7c/0xd0
bus_for_each_dev from bus_add_driver+0xc4/0x1cc
bus_add_driver from driver_register+0x7c/0x114
driver_register from do_one_initcall+0x58/0x270
do_one_initcall from kernel_init_freeable+0x170/0x218
kernel_init_freeable from kernel_init+0x14/0x140
kernel_init from ret_from_fork+0x14/0x20
Fixes: abf6569d64 ("pwm: imx-tpm: Make use of devm_pwmchip_alloc() function")
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Link: https://lore.kernel.org/r/20240304102929.893542-1-aisheng.dong@nxp.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Meson8 pwm type always has 4 input clocks. Some inputs may be grounded,
like in the AO domain of some SoCs.
Drop the parent number parameter and make this is constant.
This is also done to make the addition of generic meson8 compatible easier.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20240221151154.26452-4-jbrunet@baylibre.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Simplify error handling in ->probe() function using dev_err_probe() helper
and while at it, drop error codes from the message to prevent duplication.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20240219033835.11369-5-raag.jadav@intel.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Intel Elkhart Lake PSE includes two instances of PWM as a single PCI
function with 8 channels each. Add support for the remaining channels.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
Link: https://lore.kernel.org/r/20240219033835.11369-4-raag.jadav@intel.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
pcim_iomap_table() fails only if pcim_iomap_regions() fails. No need to
check for failure if the latter is already successful.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20240219033835.11369-3-raag.jadav@intel.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This prepares the pwm-vt8500 driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.
Also convert the to_vt8500_chip() helper macro to a static inline to
get some type safety.
Link: https://lore.kernel.org/r/b203c4448db23ebad1165b7bce43ac41468c4e89.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This prepares the driver for further changes that will make it harder to
determine the pwm_chip from a given ehrpwm_pwm_chip. To just not have to
do that, rework ehrpwm_pwm_save_context() and
ehrpwm_pwm_restore_context() take a pwm_chip. Also use the pwm_chip as
driver data instead of the ehrpwm_pwm_chip.
Link: https://lore.kernel.org/r/79052207cdf71f0882ae13fe1a192ef6f6dba35b.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This prepares the driver for further changes that will make it harder to
determine the pwm_chip from a given ecap_pwm_chip. To just not have to
do that, rework ecap_pwm_save_context() and ecap_pwm_restore_context
take a pwm_chip. Also use the pwm_chip as driver data instead of the
ecap_pwm_chip.
Link: https://lore.kernel.org/r/ed031f201ff52c6b298de2dc81b06aad3a0207f8.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The driver uses three different names for variables of type
sun4i_pwm_chip:
$ git grep 'struct sun4i_pwm_chip \*' v6.8-rc1 -- drivers/pwm/pwm-sun4i.c
v6.8-rc1:drivers/pwm/pwm-sun4i.c:static inline struct sun4i_pwm_chip *to_sun4i_pwm_chip(struct pwm_chip *chip)
v6.8-rc1:drivers/pwm/pwm-sun4i.c:static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
v6.8-rc1:drivers/pwm/pwm-sun4i.c:static inline void sun4i_pwm_writel(struct sun4i_pwm_chip *chip,
v6.8-rc1:drivers/pwm/pwm-sun4i.c: struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
v6.8-rc1:drivers/pwm/pwm-sun4i.c:static int sun4i_pwm_calculate(struct sun4i_pwm_chip *sun4i_pwm,
v6.8-rc1:drivers/pwm/pwm-sun4i.c: struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
v6.8-rc1:drivers/pwm/pwm-sun4i.c: struct sun4i_pwm_chip *sun4ichip;
v6.8-rc1:drivers/pwm/pwm-sun4i.c: struct sun4i_pwm_chip *sun4ichip = platform_get_drvdata(pdev);
"chip" is usually reserved for variables of type struct pwm_chip. So
pick sun4ichip as common name which better matches the type name than
sun4i_pwm.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/705f54a13b59fff50eaa345d8b1e0c691345b996.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This prepares the driver for further changes that will drop struct
pwm_chip chip from struct sun4i_pwm_chip. Use the pwm_chip as driver
data instead of the sun4i_pwm_chip to get access to the pwm_chip in
sun4i_pwm_remove() without using sun4ichip->chip.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/f8e3fb96fe341ba0a4bed982aa731c5c7c355b83.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
When the stm32 pwm driver is converted to pwmchip_alloc(), the number of
available PWM lines must be known before the driver private data can be
allocated. So rework the helper function that determines this number to
not take the driver private data struct as input parameter.
Link: https://lore.kernel.org/r/13d4d3e90a9ee1bcd04674dfdc16f242615b8320.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
To be able to convert the sprd driver to pwmchip_alloc() the number of
PWM channels must be known when the driver private data is allocated. So
make sprd_pwm_clk_init() not take a struct sprd_pwm_chip. On the plus
side this allows to drop a member of said driver private data.
Reviewed-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/682cbbafbfc4982383d66c3871bb9e52d4e03195.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This prepares the driver for further changes that will drop struct
pwm_chip chip from struct pwm_sifive_ddata. Use the pwm_chip as driver
data instead of the pwm_sifive_ddata to get access to the pwm_chip in
pwm_sifive_remove() without using ddata->chip. In the clock rate
notifier it's not possible to get the pwm_chip without adding a pointer
to this to struct pwm_sifive_ddata. Instead of that add a parent device
pointer which is all that is needed there.
Link: https://lore.kernel.org/r/b7b7985f4dc746f6a36c5048d428c4ed0a2d42dc.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This prepares the driver for further changes that will make it harder to
determine the pwm_chip from a given samsung_pwm_chip. To just not have
to do that, rework pwm_samsung_calc_tin() and pwm_samsung_parse_dt take
a pwm_chip. Also use the pwm_chip as driver data instead of the
samsung_pwm_chip.
Link: https://lore.kernel.org/r/33ea7d7fbf3be4a542ae8aafa213470c5831487e.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
