| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
i2c_device_id::driver_data to 0
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/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
This prepares the pwm-pca9685 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/4cb65adc92414a901dd3c0b8412de075196a3c54.1707900770.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the accessor
function provided for exactly this purpose.
Link: https://lore.kernel.org/r/14b6ec2bdaa7050b9f49a69f35edef731fd84c25.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 pca9685. Use the pwm_chip as i2c client data
and gpiochip data instead of the pca9685 to get access to the
pwm_chip in pca9685_pwm_remove(), pca9685_pwm_runtime_suspend(),
pca9685_pwm_runtime_resume(), pca9685_pwm_gpio_request() and the gpio
callbacks without using pca->chip. Also the prototype for various helper
functions is changed to take a pwm_chip instead of a pca9685 for the
same reason.
Link: https://lore.kernel.org/r/e87b378545cee15a52f0d410fcceebf671ab90e0.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]>
|
|
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter")
convert back to (the new) .probe() to be able to eventually drop
.probe_new() from struct i2c_driver.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-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]>
|
|
The value returned by an i2c driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Reviewed-by: Peter Senna Tschudin <[email protected]>
Reviewed-by: Jeremy Kerr <[email protected]>
Reviewed-by: Benjamin Mugnier <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Crt Mori <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Marek Behún <[email protected]> # for leds-turris-omnia
Acked-by: Andy Shevchenko <[email protected]>
Reviewed-by: Petr Machata <[email protected]> # for mlxsw
Reviewed-by: Maximilian Luz <[email protected]> # for surface3_power
Acked-by: Srinivas Pandruvada <[email protected]> # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil <[email protected]> # for media/* + staging/media/*
Acked-by: Miguel Ojeda <[email protected]> # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli <[email protected]> # for versaclock5
Reviewed-by: Ajay Gupta <[email protected]> # for ucsi_ccg
Acked-by: Jonathan Cameron <[email protected]> # for iio
Acked-by: Peter Rosin <[email protected]> # for i2c-mux-*, max9860
Acked-by: Adrien Grassein <[email protected]> # for lontium-lt8912b
Reviewed-by: Jean Delvare <[email protected]> # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard <[email protected]> # for IPMI
Reviewed-by: Vladimir Oltean <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Sebastian Reichel <[email protected]> # for drivers/power
Acked-by: Krzysztof Hałasa <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
During the driver probe, registers are not set to their POR value.
Signed-off-by: Lionel Vitte <[email protected]>
Acked-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
pwmchip_remove() returns always 0. Don't use the value to make it
possible to eventually change the function to return void. Also the
driver core ignores the return value of pca9685_pwm_remove()
and considers the device removed anyhow. So returning early results
in a resource leak.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Regmap operations can fail if the underlying subsystem is not working
properly (e.g. hogged I2C bus, etc.)
As this is useful information for the user, print an error message if it
happens.
Let probe fail if the first regmap_read or the first regmap_write fails.
Signed-off-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Previously, the last used PWM channel could change the global prescale
setting, even if other channels are already in use.
Fix it by only allowing the first enabled PWM to change the global
chip-wide prescale setting. If there is more than one channel in use,
the prescale settings resulting from the chosen periods must match.
GPIOs do not count as enabled PWMs as they are not using the prescaler
and can't change it.
Signed-off-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
If usage_power is set, the pca9685 driver will phase shift the
individual channels relative to their channel number. This improves EMI
because the enabled channels no longer turn on at the same time, while
still maintaining the configured duty cycle / power output.
Signed-off-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The chip does not come out of POR in active state but in sleep state.
To be sure (in case the bootloader woke it up) we force it to sleep in
probe.
If runtime PM is disabled, we instead wake the chip in .probe and put it
to sleep in .remove.
Signed-off-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Implement .get_state to read-out the current hardware state.
The hardware readout may return slightly different values than those
that were set in apply due to the limited range of possible prescale and
counter register values.
Also note that although the datasheet mentions 200 Hz as default
frequency when using the internal 25 MHz oscillator, the calculated
period from the default prescaler register setting of 30 is 5079040ns.
Signed-off-by: Clemens Gruber <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The switch to the atomic API goes hand in hand with a few fixes to
previously experienced issues:
- The duty cycle is no longer lost after disable/enable (previously the
OFF registers were cleared in disable and the user was required to
call config to restore the duty cycle settings)
- If one sets a period resulting in the same prescale register value,
the sleep and write to the register is now skipped
- Previously, only the full ON bit was toggled in GPIO mode (and full
OFF cleared if set to high), which could result in both full OFF and
full ON not being set and on=0, off=0, which is not allowed according
to the datasheet
- The OFF registers were reset to 0 in probe, which could lead to the
forbidden on=0, off=0. Fixed by resetting to POR default (full OFF)
Signed-off-by: Clemens Gruber <[email protected]>
Acked-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]>
|
|
The PCA9685 supports listening to 1 or more alternative I2C chip addresses
for some special features that this driver does not support.
By default the LED ALLCALL address is active (default 0x70), which causes
this chip to respond to address 0x70 in addition to its main address
(0x41). This is not desireable if there is another device on the same bus
that uses this address (like a TMP103 for example).
Since this feature is not supported by this driver, it is best to disable
these addresses in the chip to avoid unsuspected bus collisions.
Signed-off-by: David Jander <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Signed-off-by: David Jander <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Make all explanatory comments start with an uppercase char.
Signed-off-by: David Jander <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
This driver allows pwms to be requested as gpios via gpiolib. Obviously,
it should not be allowed to request a GPIO when its corresponding PWM is
already requested (and vice versa). So it requires some exclusion code.
Given that the PWMm and GPIO cores are not synchronized with respect to
each other, this exclusion code will also require proper
synchronization.
Such a mechanism was in place, but was inadvertently removed by Uwe's
clean-up in commit e926b12c611c ("pwm: Clear chip_data in pwm_put()").
Upon revisiting the synchronization mechanism, we found that
theoretically, it could allow two threads to successfully request
conflicting PWMs/GPIOs.
Replace with a bitmap which tracks PWMs in-use, plus a mutex. As long as
PWM and GPIO's respective request/free functions modify the in-use
bitmap while holding the mutex, proper synchronization will be
guaranteed.
Reported-by: YueHaibing <[email protected]>
Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
Cc: Mika Westerberg <[email protected]>
Cc: Uwe Kleine-König <[email protected]>
Cc: YueHaibing <[email protected]>
Link: https://lkml.org/lkml/2019/5/31/963
Signed-off-by: Sven Van Asbroeck <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
[cg: Tested on an i.MX6Q board with two NXP PCA9685 chips]
Tested-by: Clemens Gruber <[email protected]>
Reviewed-by: Sven Van Asbroeck <[email protected]> # cg's rebase
Link: https://lore.kernel.org/lkml/20200330160238.GD2817345@ulmo/
Signed-off-by: Thierry Reding <[email protected]>
|
|
GPIO core recently added macro to uniformly specify direction of a GPIO
line, so use it.
Signed-off-by: Rishi Gupta <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The __maybe_unused attribute is preferred over CONFIG_PM to prevent
potential build time issues. This commit replaces CONFIG_PM with this
attribute.
Signed-off-by: Rishi Gupta <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
duty_cycle was only set, never read.
Signed-off-by: Matthias Schiffer <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/pwm/pwm-pca9685.c: In function ‘pca9685_pwm_gpio_free’:
drivers/pwm/pwm-pca9685.c:162:21: warning: variable ‘pwm’ set but not used [-Wunused-but-set-variable]
It is never used, and so can be removed. In that case, hold and release
the lock 'pca->lock' can be removed since nothing will be done between
them.
Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
Signed-off-by: yu kuai <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation this program is
distributed in the hope that it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not see http www gnu org
licenses
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 503 file(s).
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Alexios Zavras <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
After a PWM is disposed by its user the per chip data becomes invalid.
Clear the data in common code instead of the device drivers to get
consistent behaviour. Before this patch only three of nine drivers
cleaned up here.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The function
static void pca9685_set_sleep_mode(struct pca9685 *pca, int sleep)
takes the chip in and out of sleep mode, depending on the value of
sleep, which is interpreted as a boolean.
To clarify that 'int sleep' is a boolean and not a sleep delay,
change the function interface to:
static void pca9685_set_sleep_mode(struct pca9685 *pca, bool enable)
Suggested-by: Andy Shevchenko <[email protected]>
Signed-off-by: Sven Van Asbroeck <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
GPIO-only driver operation never clears the SLEEP bit, which can cause
the GPIOs to become unusable.
Example:
1. user requests first PWM -> driver clears SLEEP bit
2. user frees last PWM -> driver sets SLEEP bit
3. user requests GPIO
4. user switches GPIO on -> output does not turn on
because SLEEP bit is set
Prevent this behaviour by letting the runtime PM framework control the
SLEEP bit. This will put the chip to SLEEP if no PWMs/GPIOs are exported
or in use.
Fixes: bccec89f0a35 ("Allow any of the 16 PWMs to be used as a GPIO")
Reported-by: Sven Van Asbroeck <[email protected]>
Signed-off-by: Sven Van Asbroeck <[email protected]>
Suggested-by: Mika Westerberg <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
|
|
When first implementing support for changing the output frequency, an
optimization was added to continue the PWM after changing the prescaler
without having to reprogram the ON and OFF registers for the duty cycle,
in case the duty cycle stayed the same. This was flawed, because we
compared the absolute value of the duty cycle in nanoseconds instead of
the ratio to the period.
Fix the problem by removing the shortcut.
Fixes: 01ec8472009c9 ("pwm-pca9685: Support changing the output frequency")
Cc: <[email protected]> # v4.3+
Signed-off-by: Clemens Gruber <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The PCA9685 controller has full on/off bit for each PWM channel. Setting
this bit bypasses the PWM control and the line works just as it would be a
GPIO. Furthermore in Intel Galileo it is actually used as GPIO output for
discreet muxes on the board.
This patch adds GPIO output only support for the driver so that we can
control the muxes on Galileo using standard GPIO interfaces available in
the kernel. GPIO and PWM functionality is exclusive so only one can be
active at a time on a single PWM channel.
Signed-off-by: Mika Westerberg <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
All PWM devices have been marked as "might sleep" since v4.5, there is
no longer a need to differentiate on a per-chip basis.
Signed-off-by: Thierry Reding <[email protected]>
|
|
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Previously, period_ns and duty_ns were only used to determine the
ratio of ON and OFF time, the default frequency of 200 Hz was never
changed.
The PCA9685 however is capable of changing the PWM output frequency,
which is expected when changing the period.
This patch configures the prescaler accordingly, using the formula
and notes provided in the PCA9685 datasheet.
Bounds checking for the minimum and maximum frequencies, last updated
in revision v.4 of said datasheet, is also added.
The prescaler is only touched if the period changed, because we have to
put the chip into sleep mode to unlock the prescale register.
If it is changed, the PWM output frequency changes for all outputs,
because there is one prescaler per chip. This is documented in the
PCA9685 datasheet and in the comments.
If the duty cycle is not changed at the same time as the period, then
we restart the PWM output using the duty cycle to period ratio from
before the period change.
When using LEDs for example, previously set brightness levels stay the
same when the frequency changes.
Cc: Thierry Reding <[email protected]>
Cc: Steffen Trumtrar <[email protected]>
Signed-off-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Problems:
- When duty_ns == period_ns, the full OFF bit was not cleared and the
PWM output of the PCA9685 stayed off.
- When duty_ns == period_ns and the catch-all channel was used, the
ALL_LED_OFF_L register was not cleared.
- The full ON bit was not cleared when setting the OFF time, therefore
the exact OFF time was ignored when setting a duty_ns < period_ns
Solution: Clear both OFF registers when setting full ON and clear the
full ON bit when changing the OFF registers.
Cc: Thierry Reding <[email protected]>
Cc: Steffen Trumtrar <[email protected]>
Signed-off-by: Clemens Gruber <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Current code actually does not set MODE1_SLEEP bit because the new value for
bitmask (0x1) is wrong. To set MODE1_SLEEP bit, we should pass MODE1_SLEEP
as the new value for bitmask.
Signed-off-by: Axel Lin <[email protected]>
Reviewed-by: Steffen Trumtrar <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Some drivers don't set the .owner fields of the struct device_driver or
struct pwm_ops, which causes the module usage count to become wrong.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Add pwm driver for the NXP pca9685 16 channel pwm-led controller.
The driver is really barebones at this stage. E.g. the OE' pin and
therefore the corresponding registers are not supported.
The driver was tested on a HW where this pin is tied to GND.
Signed-off-by: Steffen Trumtrar <[email protected]>
[[email protected]: style and whitespace cleanups]
Signed-off-by: Thierry Reding <[email protected]>
|