- 20 Dec, 2023 40 commits
-
-
Uwe Kleine-König authored
Recently an unused member was removed from struct cros_ec_pwm_device, but the kernel doc wasn't adapted accordingly. Catch up and drop the documentation, too. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312190757.O4M9dsln-lkp@intel.com/ Fixes: 6c4406ce ("pwm: cros-ec: Drop unused member from driver private data") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
These functions are unused. Also I think there is no valid use case where these are correct to be called. So drop them. Signed-off-by:
-
Uwe Kleine-König authored
Even though the hardware only supports a single period for all PWM outputs, modifying the other (disabled) outputs's period is strange and wrong. Only the pwm core is supposed to update these values. Signed-off-by:
-
Uwe Kleine-König authored
Using dev_err_probe() emitting an error message mentioning a return value and returning that value can be done in a single statement. Make use of that to simplify the probe part of the driver. This has the additional advantage to emit the symbolic name for the error instead of the integer error value. Signed-off-by:
-
Uwe Kleine-König authored
stmpe_reg_read() and stmpe_reg_write() already emit error messages when they fail. So the extra error messages in the pwm driver are only little useful. They are useful in some situation, as they give a bit of context to the failing register write. So don't remove them but degrade them to dev_dbg(). Signed-off-by:
-
Uwe Kleine-König authored
pwm->chip and pwm->chip->ops are used several times in this function. Introduce local variables for these. There is no semantical change, but with ARCH=arm, allmodconfig and gcc-13 bloat-o-meter reports a slight improvement: add/remove: 1/1 grow/shrink: 1/1 up/down: 8/-36 (-28) Function old new delta pwm_apply_state 476 480 +4 __initcall__kmod_core__307_1092_pwm_debugfs_init4 - 4 +4 __initcall__kmod_core__307_1090_pwm_debugfs_init4 4 - -4 pwm_request_from_chip 628 596 -32 Total: Before=15091, After=15063, chg -0.19% Signed-off-by:
-
Uwe Kleine-König authored
All but one local variable of type pointer to struct crystalcove_pwm are called "crc_pwm", the one outlier is called "pwm" which is usually reserved for variables of type pointer to struct pwm_device. So rename that one "pwm" to "crc_pwm" for consistency. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Uwe Kleine-König authored
The pwm driver only provides a single PWM line, so there are no concurrent calls of the callbacks from different consumers. A single consumer is expected not to do concurrent calls into the pwm framework. So there is nothing to serialize and the lock can go away. Signed-off-by:
-
Tony Lindgren authored
Update for yaml and remove the old txt binding. As we can replace most of the custom timer API with standard Linux frameworks such as clock framework, let's tag the properties for ti,prescaler and ti,clock-source as deprecated. Cc: <linux-pwm@vger.kernel.org> Cc: Nishanth Menon <nm@ti.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
-
Sean Young authored
This makes the generated IR much more precise. Before this change, the driver is unreliable and many users opted to use gpio-ir-tx instead. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent rate changes using clk_rate_exclusive_get(). Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
Sean Young authored
Some PWM devices require sleeping, for example if the pwm device is connected over I2C. However, many PWM devices could be used from atomic context, e.g. memory mapped PWM. This is useful for, for example, the pwm-ir-tx driver which requires precise timing. Sleeping causes havoc with the generated IR signal. Since not all PWM devices can support atomic context, we also add a pwm_might_sleep() function to check if is not supported. Signed-off-by:
-
Sean Young authored
No mutex is used in this driver. Reviewed-by:
-
Sean Young authored
According to Documentation/dev-tools/checkpatch.rst ENOTSUPP is not recommended and EOPNOTSUPP should be used instead. Signed-off-by:
-
Sean Young authored
In order to introduce a pwm api which can be used from atomic context, we will need two functions for applying pwm changes: int pwm_apply_might_sleep(struct pwm *, struct pwm_state *); int pwm_apply_atomic(struct pwm *, struct pwm_state *); This commit just deals with renaming pwm_apply_state(), a following commit will introduce the pwm_apply_atomic() function. Acked-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Mark Brown <broonie@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input Acked-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Lee Jones <lee@kernel.org> Signed-off-by:
-
Thierry Reding authored
Drivers have access to the chip via a function argument already, so there is no need to reference it via the PWM device. Reviewed-by:
-
Uwe Kleine-König authored
Commit c572f3b9c8b7 ("pwm: Replace PWM chip unique base by unique ID") changed the members of struct pwm_chip, but failed to update the documentation accordingly. Catch up and document the new member and drop description for the two removed ones. Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Michael Walle authored
Xinlei Lee's mail is bouncing: <xinlei.lee@mediatek.com>: host mailgw02.mediatek.com[216.200.240.185] said: 550 Relaying mail to xinlei.lee@mediatek.com is not allowed (in reply to RCPT TO command) Remove it. Signed-off-by:Michael Walle <mwalle@kernel.org> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Philipp Zabel authored
Make the driver take over hardware state without disabling in .probe() and enable the clock for each enabled channel. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> [ukleinek: split off from a patch that also implemented .get_state()] Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by:
-
Philipp Zabel authored
Implement the &pwm_ops->get_state callback so drivers can inherit PWM state set by the bootloader. Signed-off-by:
-
Philipp Zabel authored
Use hweight32() to count the CCxE bits in stm32_pwm_detect_channels(). Since the return value is assigned to chip.npwm, change it to unsigned int as well. Signed-off-by:
-
Philipp Zabel authored
The channel parameter is only ever set to pwm->hwpwm. Make it unsigned int as well. Signed-off-by:
-
Philipp Zabel authored
The TIM_CCR1...4 registers are consecutive, so replace the switch case with a simple calculation. Since ch is known to be in the 0...3 range (it is set to hwpwm < npwm <= 4), drop the unnecessary error handling. The return value was not checked anyway. What remains does not warrant keeping the write_ccrx() function around, so instead call regmap_write() directly at the singular call site. Signed-off-by:
-
Rob Herring authored
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. As these drivers only do DT based matching, of_match_device() will never return NULL if we've gotten to probe(). Therefore, the NULL check and error returns can be dropped. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Uwe Kleine-König authored
In the expression determining the size of the allocation for chip->pwms it's more natural to use sizeof(*chip->pwms) than sizeof(*pwm). With that changed, the variable pwm is only used in a for loop and its scope can be reduced accordingly. Signed-off-by:
-
Uwe Kleine-König authored
Error messages are supposed to end in \n. Add the line terminator to the two error messages that lack this. Suggested-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding __maybe_unused can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding __maybe_unused can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by:
Andi Shyti <andi.shyti@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding __maybe_unused can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Acked-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Uwe Kleine-König authored
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by:
-
Uwe Kleine-König authored
.dev is unused since the driver was introduced in commit 1f0d3bb0 ("pwm: Add ChromeOS EC PWM driver"). Drop it. Signed-off-by:
-
Uwe Kleine-König authored
While it's not hard to match the entries from /sys/kernel/debug/pwm to the corresponding pwmchip in /sys/class/pwm, it's a bit simpler to have the number mentioned in /sys/kernel/debug/pwm. Link: https://lore.kernel.org/r/20230808165250.942396-3-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Traditionally each PWM device had a unique ID stored in the "pwm" member of struct pwm_device. However this number was hardly used and dropped in the previous commit. To identify a certain PWM you're supposed to use the chip's ID and the hwpwm of the PWM device now. With the PWM chip base gone PWM chips can get their IDs better and simpler using an idr. This is expected to change the numbering of PWM chips, but nothing should rely on the numbering anyhow. Other than that the side effects are: - The PWM chip IDs are smaller and in most cases consecutive. - The ordering in /sys/kernel/debug/pwm is ordered by ascending PWM chip ID. Signed-off-by:
-
