- Jul 01, 2021
-
-
Uwe Kleine-König authored
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
tegra_pwm_remove() is only called after tegra_pwm_probe() successfully completed. In this case platform_set_drvdata() was called with a non-NULL value and so platform_get_drvdata(pdev) cannot return NULL. Returning an error code from a platform_driver's remove function is ignored anyway, so it's a good thing this exit path is gone. Signed-off-by:
-
Andy Shevchenko authored
Use devm_add_action_or_reset() instead of devres_alloc() and devres_add(), which works the same. This will simplify the code. There is no functional changes. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Andy Shevchenko authored
There are no users and seems no will come of the devm_pwm_put(). Remove the function. While at it, slightly update documentation. Signed-off-by:
-
Andy Shevchenko authored
Historically we have two different approaches on how to check type of fwnode. Unify them using the latest and greatest fwnode related APIs. Signed-off-by:
-
Andy Shevchenko authored
In ACPI case we may use matching by fwnode as provided via fwnode_to_pwmchip(). This makes device_to_pwmchip() not needed anymore. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Andy Shevchenko authored
When we traverse the list of the registered PWM controllers, use fwnode to match. This will help for further cleanup. Signed-off-by:
-
Andy Shevchenko authored
When PWM support for ACPI has been added into the kernel, it missed the documentation update. Hence update documentation here. Fixes: 4a6ef8e3 ("pwm: Add support referencing PWMs from ACPI") Signed-off-by:
-
Lokesh Vutla authored
Add compatible string for AM64 SoC in device tree binding. IP is compatible with ti,am3352-ecap, so adding the AM64 compatible under enum of one of the compatible list entry. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Lokesh Vutla authored
Convert the tiecap binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked required as driver fails to probe without these properties - Dropped ti,am33xx-ecap as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by:
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. This is a good thing as pwmchip_remove() is usually called from a remove function (mostly for platform devices) and their return value is ignored by the device core anyhow. Signed-off-by:
-
Zou Wei authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
-
Uwe Kleine-König authored
In most functions the driver data variable is called pc. Do the same in the two remaining functions. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() function is only called after .probe() returned successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so platfrom_get_drvdata() returns the same non-NULL value. Signed-off-by:
-
Uwe Kleine-König authored
pwmchip_remove() always returns 0. Don't use the value to make it possible to eventually change the function to return void. This is a good thing as pwmchip_remove() is usually called from a remove function (mostly for platform devices) and their return value is ignored by the device core anyhow. Signed-off-by:
-
Uwe Kleine-König authored
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This just pushes down a slightly optimized variant of how legacy drivers are handled in the core. Signed-off-by:
-
Uwe Kleine-König authored
A struct berlin_pwm_chip * is now always called "bpc" (instead of "pwm" which is usually used for struct pwm_device * or "chip" which is usually used for struct pwm_chip *). The struct pwm_device * variables were named "pwm_dev" or "pwm"; they are now always called "pwm". Signed-off-by:
-
- Jun 28, 2021
-
-
Uwe Kleine-König authored
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This just pushes down a slightly optimized variant of how legacy drivers are handled in the core. Signed-off-by:
-
Uwe Kleine-König authored
ecap_pwm_free is only called when a consumer releases the PWM (using pwm_put() or pwm_free()). The consumer is expected to disable the PWM before doing that. It's not clear if a warning about that is justified, but if it is this is independent of the actual driver and can better be done in the core. Also if there is a good reason it's wrong to disable the hardware and so the call to pm_runtime_put_sync() should be dropped. Moreover there is no matching pwm_runtime_get call and so the runtime usage counter might become negative. Fixes: 8e0cb05b ("pwm: pwm-tiecap: PWM driver support for ECAP APWM") Signed-off-by:
-
Uwe Kleine-König authored
Since the PWM core uses device links (commit b2c200e3 ("pwm: Add consumer device link")) each consumer driver that requested the PWMs is already gone. If they called pwm_put() (as they should) the PWMF_REQUESTED bit is not set. If they failed (which is a bug) the PWMF_REQUESTED bit might still be set, but the driver that cared is gone, so nothing bad happens if the PWM chip goes away even if the PWMF_REQUESTED is still present. So the check can be dropped. With this change pwmchip_remove() returns always 0, so lowlevel drivers don't need to check the return code any more. Once all drivers dropped this check this function can be changed to return void. Signed-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback disables clocks that were not enabled in .probe(). So just probing and then unbinding the driver results in a clk enable imbalance. So just drop the call to disable the clocks. (Which BTW was also in the wrong order because the call makes the PWM unfunctional and so should have come only after pwmchip_remove()). Fixes: 9f4c8f96 ("pwm: imx: Add ipg clock operation") Signed-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
-
Uwe Kleine-König authored
This potentially simplifies low-level PWM drivers. Signed-off-by:
-
- Jun 04, 2021
-
-
Lokesh Vutla authored
Add compatible string for AM64 SoC in device tree binding. EPWM IP in AM64 does not support High resolution, so named epwm instead of ehrpwm in compatible. However IP is till compatible with features supported by driver with ti,am3352-ehrpwm compatible. Signed-off-by:
-
Lokesh Vutla authored
Convert the tiehrpwm binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked as required as driver fails to probe without these properties - Dropped ti,am33xx-ehrpwm as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by:
-
Clemens Gruber authored
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 <clemens.gruber@pqgruber.com> Signed-off-by:
-
Clemens Gruber authored
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 authored
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 authored
If usage_power is set, the PWM driver is only required to maintain the power output but has more freedom regarding signal form. If supported, the signal can be optimized, for example to improve EMI by phase shifting individual channels. Signed-off-by:
-
- May 26, 2021
-
-
Uwe Kleine-König authored
Just using the previous callbacks to implment a similar procedure as the legacy handling in the core. Signed-off-by:
-
Uwe Kleine-König authored
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clocks. The check for pwmchip_remove()'s return value is dropped as this function returns effectively always 0 and returning an error in a remove callback is useless anyhow (as the device core ignores it and drops devm allocated resources). Signed-off-by:
-
Uwe Kleine-König authored
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by:
-
Uwe Kleine-König authored
With the original code a request for period = 65536000 ns and period = 32768000 ns yields the same register settings (which results in 32768000 ns) because the value for pwmc0 was miscalculated. Also simplify using that fls(0) is 0. Fixes: 721b5957 ("pwm: visconti: Add Toshiba Visconti SoC PWM support") Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
Uwe Kleine-König authored
With the previous commit there is no need for the lowlevel driver any more to specify it it uses two or three cells. So simplify accordingly. The only non-trival change affects the pwm-rockchip driver: It used to only support three cells if the hardware supports polarity. Now the default number depends on the device tree which has to match hardware anyhow (and if it doesn't the error is just a bit delayed as a PWM handle with an inverted setting is catched when pwm_apply_state() is called). Signed-off-by:
-
Uwe Kleine-König authored
This allows to simplify all drivers that use three pwm-cells. The only ugly side effect is that if a driver specified of_pwm_n_cells = 2 it suddenly supports device trees that use #pwm-cells = <3>. This however isn't a bad thing because the driver doesn't need explicit support for three cells as the core handles all the details. Also there is no such in-tree driver. Signed-off-by:
-
Uwe Kleine-König authored
Since the previous commit the latter function can do everything that the former does. So simplify accordingly. Signed-off-by:
-
