| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This prepares the pwm-iqs620a 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.
Link: https://lore.kernel.org/r/85cb0e73baadd76ede364abc4b57ee72000880e5.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
This prepares the driver for further changes that will drop struct
pwm_chip chip from struct iqs620_pwm_private. The only two functions
that make use of struct iqs620_pwm_private::chip (apart from the probe
function that is handled later when converting to pwmchip_alloc()) only
use the chip's device pointer. Introduce such a pointer in driver data
and use that instead.
Link: https://lore.kernel.org/r/e6b1636c0d26d8bcb02a66b2963e2cc394014d76.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
There is no semantic change. The new function just implements what was
open-coded twice in the driver before.
Link: https://lore.kernel.org/r/cc7ab547b4c4b79456b548aa72205bcf4476db8c.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is that new low level drivers cannot forget the assignment and
save one line each. The pwm-crc driver didn't assign .owner, that's not
a problem in practice though as the driver cannot be compiled as a
module.
Acked-by: Andy Shevchenko <[email protected]> # Intel LPSS
Reviewed-by: Florian Fainelli <[email protected]> # pwm-{bcm,brcm}*.c
Acked-by: Jernej Skrabec <[email protected]> # sun4i
Acked-by: Andi Shyti <[email protected]>
Acked-by: Nobuhiro Iwamatsu <[email protected]> # pwm-visconti
Acked-by: Heiko Stuebner <[email protected]> # pwm-rockchip
Acked-by: Michael Walle <[email protected]> # pwm-sl28cpld
Acked-by: Neil Armstrong <[email protected]> # pwm-meson
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The driver only supports normal polarity. Complete the implementation of
.get_state() by setting .polarity accordingly.
Fixes: 6f0841a8197b ("pwm: Add support for Azoteq IQS620A PWM generator")
Reviewed-by: Jeff LaBundy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The call to regmap_update_bits() which was responsible for clearing
the PWM output enable register bit was recently dropped in favor of
a call to regmap_clear_bits(), thereby simplifying the code.
Similarly, the call to regmap_update_bits() which sets the same bit
can be simplified with a call to regmap_set_bits().
Signed-off-by: Jeff LaBundy <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
.get_state() might fail in some cases. To make it possible that a driver
signals such a failure change the prototype of .get_state() to return an
error code.
This patch was created using coccinelle and the following semantic patch:
@p1@
identifier getstatefunc;
identifier driver;
@@
struct pwm_ops driver = {
...,
.get_state = getstatefunc
,...
};
@p2@
identifier p1.getstatefunc;
identifier chip, pwm, state;
@@
-void
+int
getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state)
{
...
- return;
+ return 0;
...
}
plus the actual change of the prototype in include/linux/pwm.h (plus some
manual fixing of indentions and empty lines).
So for now all drivers return success unconditionally. They are adapted
in the following patches to make the changes easier reviewable.
Reviewed-by: Heiko Stuebner <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Nobuhiro Iwamatsu <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Reviewed-by: Dave Stevenson <[email protected]>
Acked-by: Douglas Anderson <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Acked-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Found using coccinelle and the following semantic patch:
@@
expression map, reg, bits;
@@
- regmap_update_bits(map, reg, bits, bits)
+ regmap_set_bits(map, reg, bits)
@@
expression map, reg, bits;
@@
- regmap_update_bits(map, reg, bits, 0)
+ regmap_clear_bits(map, reg, bits)
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
This allows to drop the platform_driver's remove function. This is the
only user of driver data so this can go away, too.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip
base dynamically") all drivers use dynamic ID allocation explicitly. New
drivers are supposed to do the same, so remove support for driver
specified base IDs and drop all assignments in the low-level drivers.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
If duty cycle is first set to a value that is sufficiently high to
enable the output (e.g. 10000 ns) but then lowered to a value that
is quantized to zero (e.g. 1000 ns), the output is disabled as the
device cannot drive a constant zero (as expected).
However if the device is later re-initialized due to watchdog bite,
the output is re-enabled at the next-to-last duty cycle (10000 ns).
This is because the iqs620_pwm->out_en flag unconditionally tracks
state->enabled instead of what was actually written to the device.
To solve this problem, use one state variable that encodes all 257
states of the output (duty_scale) with 0 representing tri-state, 1
representing the minimum available duty cycle and 256 representing
100% duty cycle.
Signed-off-by: Jeff LaBundy <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
If state->duty_cycle is 0x100000000000000, the previous calculation of
duty_scale overflows and yields a duty cycle ratio of 0% instead of
100%. Fix this by clamping the requested duty cycle to the maximal
possible duty cycle first. This way it is possible to use a native
integer division instead of a (depending on the architecture) more
expensive 64bit division.
With this change in place duty_scale cannot be bigger than 256 which
allows to simplify the calculation of duty_val.
Fixes: 6f0841a8197b ("pwm: Add support for Azoteq IQS620A PWM generator")
Tested-by: Jeff LaBundy <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Instead of using a mix of -EOPNOTSUPP and -ENOTSUPP, use the more
standard -EINVAL to signal that the specified polarity value was
invalid.
Acked-by: Uwe Kleine-König <[email protected]>
Acked-by: Lee Jones <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Other drivers use lowercase hexadecimal literals, so convert the IQS620a
driver to do the same for consistency.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The PWM framework is going to change the PWM period and duty cycles to
be 64-bit unsigned integers. To avoid build errors on platforms that do
not natively support 64-bit division, use explicity 64-bit division.
Acked-by: Uwe Kleine-König <[email protected]>
Acked-by: Lee Jones <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
This patch adds support for the Azoteq IQS620A, capable of generating
a 1-kHz PWM output with duty cycle between ~0.4% and 100% (inclusive).
Signed-off-by: Jeff LaBundy <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|