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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This allows to drop the platform_driver's remove function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There are no arm64 specific constructs in this driver and it compiles
just fine with ARCH=arm.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There are no mips specific constructs in this driver and it compiles
just fine with ARCH=arm.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since commit f9a8ee8c8b ("pwm: Always allocate PWM chip base ID
dynamically") there is no effect any more for assigning this variable.
When the patch resulting in f9a8ee8c8b was created, this driver didn't
exist yet, so this was missed.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver is supposed to stay functional until pwmchip_remove()
returns. So disable clocks only after that.
pwmchip_remove() always returns 0, so the return code can be ignored
which keeps ehrpwm_pwm_remove() a bit simpler and eventually allows to
make pwmchip_remove() return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver is supposed to stay functional until pwmchip_remove()
returns. So disable clocks only after that.
pwmchip_remove() always returns 0, so the return code can be ignored
which keeps rockchip_pwm_remove() a bit simpler and allows to eventually
make pwmchip_remove() return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver is supposed to stay functional until pwmchip_remove()
returns. So disable clocks and reset the hardware only after that.
The return value of pwmchip_remove doesn't need to be checked because
it returns zero anyhow and should be changed to return void eventually.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This fixes a race condition: After pwmchip_add() is called there might
already be a consumer and then modifying the hardware behind the
consumer's back is bad. So reset before calling pwmchip_add().
Note that reseting the hardware isn't the right thing to do if the PWM
is already running as it might e.g. disable (or even enable) a backlight
that is supposed to be on (or off).
Fixes: 4dce82c1e8 ("pwm: add pwm-mxs support")
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This fixes a race condition: After pwmchip_add() is called there might
already be a consumer and then modifying the hardware behind the
consumer's back is bad. So set the default before.
(Side-note: I don't know what this register setting actually does, if
this modifies the polarity there is an inconsistency because the
inversed polarity isn't considered if the PWM is already running during
.probe().)
Fixes: acfd92fdfb ("pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value")
Cc: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The assumption that lead to commit 5e5da1e9fb ("pwm: ab8500:
Explicitly allocate pwm chip base dynamically") was wrong: The
pwm-ab8500 devices are not directly instantiated from device tree, but
from the ab8500 mfd driver. So the pdev->id isn't -1, but a number
between 1 and 3. Now that pwmchip ids are always allocated dynamically,
this cannot easily be reverted.
Introduce a new member in the driver data struct that tracks the
hardware id and use this to calculate the register offset.
Side-note: Using chip->base to calculate the offset was never robust
because if there was already a PWM with id 1 at the time ab8500-pwm.1
was probed, the associated pwmchip would get assigned chip->base = 2 (or
something bigger).
Fixes: 5e5da1e9fb ("pwm: ab8500: Explicitly allocate pwm chip base dynamically")
Fixes: 6173f8f4ed ("pwm: Move AB8500 PWM driver to PWM framework")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This improves the driver's behavior in several ways:
- The lock is held for shorter periods and so a channel that is currently
waited for doesn't block disabling another channel.
- It's easier to understand because the procedure is split into more
semantic units and documentation is improved
- A channel is only set to pending when such an event is actually
scheduled in hardware (by writing the CUPD register).
- Also wait in .get_state() to report the last configured state instead
of (maybe) the previous one. This fixes the read back duty cycle and so
prevents a warning being emitted when PWM_DEBUG is on.
Tested on an AriettaG25.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As the last call to ep93xx_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.
Fixes: 6d45374af5 ("pwm: ep93xx: Implement .apply callback")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As the last call to berlin_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.
Fixes: 30dffb42fc ("pwm: berlin: Implement .apply() callback")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As the last call to ecap_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.
Fixes: 0ca7acd847 ("pwm: tiecap: Implement .apply() callback")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As the last call to spear_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.
Fixes: 98761ce4b9 ("pwm: spear: Implement .apply() callback")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As the last call to sprd_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.
Fixes: 8aae4b02e8 ("pwm: sprd: Add Spreadtrum PWM support")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The pointer pwm is being initialized with a value that is never read and
it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is a potential path in function ep93xx_pwm_apply where ret is
never assigned a value and it is checked for an error code. Fix this
by ensuring ret is zero'd in the success path to avoid this issue.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: f6ef94edf0f6 ("pwm: ep93xx: Unfold legacy callbacks into ep93xx_pwm_apply()")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch
to Common Clock Framework.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This just puts the implementation of ep93xx_pwm_disable(),
ep93xx_pwm_enable() and ep93xx_pwm_config() into their only caller.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Until pwmchip_remove() returns the PWM is supposed to work, so
pwmchip_remove() must be called before the clock is stopped.
The return value of pwmchip_remove doesn't need to be checked because
it returns zero anyhow and I plan to make it return void soon.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
vt8500_pwm_remove() is only called after vt8500_pwm_probe() returned
successfully. In this case driver data was set to a non-NULL value
and so chip can never be NULL.
While touching this code also put declaration and assignment in a single
line.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver is supposed to stay functional until pwmchip_remove()
returns. So the reset must be asserted only after that.
pwmchip_remove() always returns 0, so the return code can be ignored
which keeps the tegra_pwm_remove() a bit simpler.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no reason to enable the PWM clock just to assert the reset
control. (If the reset control depends on the clock this is a bug and
probably it doesn't because in .probe() the reset is deasserted without
the clock being enabled.)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <andriy.shevchenko@linux.intel.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: 8e0cb05b3b ("pwm: pwm-tiecap: PWM driver support for ECAP APWM")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM core uses device links (commit b2c200e3f2 ("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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: 9f4c8f9607 ("pwm: imx: Add ipg clock operation")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Thierry Reding <thierry.reding@gmail.com>
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 <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Just using the previous callbacks to implment a similar procedure as the
legacy handling in the core.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
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: 721b595744 ("pwm: visconti: Add Toshiba Visconti SoC PWM support")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the previous commit the latter function can do everything that the
former does. So simplify accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The two functions of_pwm_simple_xlate() and of_pwm_xlate_with_flags()
are quite similar. of_pwm_simple_xlate() only supports two-cell PWM
specifiers while of_pwm_xlate_with_flags() only supports PWM specifiers
with 3 or more cells. The latter can easily be modified to behave
identically to of_pwm_simple_xlate() for two-cell PWM specifiers. This
is implemented here and allows to drop of_pwm_simple_xlate() in the next
commit.
There is a small detail that is different now in the two-cell specifier
case in of_pwm_xlate_with_flags(): pwm->args.polarity is unconditionally
initialized to PWM_POLARITY_NORMAL in the latter. I didn't find a case
where this matters and doing that explicitly is the more robust
approach.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: fix up checkpatch warnings]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes adds support for the PWM controller found on Toshiba
Visconti SoCs and converts a couple of drivers to the atomic API.
There's also a bunch of cleanups and minor fixes across the board.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmCS5fUZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoe3FD/9vloMEaieCdiL7ImFSw44b
YsKwoyemT2utsAZd0/xckIogB0vU51m/Wx/Xvmlp8Xw1pn512Csi7sd/aD1Ryc6x
2J7HnA9rin/X0wFxspVrZ0OZCEP9d1v4GhPYI1tMQ4RKYxlAU3nC2wx1+W55j0mD
dircs7QXg963iYN0bhyl+YrniesfQ6wWPgTC8IRgpozS9cTAk5dKE7chNEhIbyal
pdtg3072oFIP3B2kVb9m2sluPSuvPivXLbUs527vhPaiKtfaOmwcZHON6LZk2+87
2fza/6qf061NVmmi9w8BqsFagrTFyQvEHAHoO4E5qlZUWHpzqfiMMxSWOPyVCMLf
jmJVBGxVNnB60B+O2+QQgHw8JoO99v84UEpvrhk1Mei1WWZfEfvBV6+jIAU08TwF
RLJgw2YFvcmtAZVjNw7hW1JwqMNIfNbM4Y4eWiPIP1qrP32nS85V4m9rHE19kMGh
Ww6gSMv7Wsl5COjQ/WnvTzodKemLuJ1dqmpeVdKJw8gluOnKQa0Uu6B/ArricoZI
tkODvQdaenjk4rBL9gi6bwN01ubjjDFW3AnBtDSSyrRxw2uGUNmx8N3WxnKiis7O
Vp6271hpriqzSomOvCdpc1Oy+iT0iHElioLSzrc4ODOLyHFBmT/LaXhVxEhTwxRy
BCyUw/G2AjsjxYzWRwa4zA==
=d0HN
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This adds support for the PWM controller found on Toshiba Visconti
SoCs and converts a couple of drivers to the atomic API.
There's also a bunch of cleanups and minor fixes across the board"
* tag 'pwm/for-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (35 commits)
pwm: Reword docs about pwm_apply_state()
pwm: atmel: Improve duty cycle calculation in .apply()
pwm: atmel: Fix duty cycle calculation in .get_state()
pwm: visconti: Add Toshiba Visconti SoC PWM support
dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
arm64: dts: rockchip: Remove clock-names from PWM nodes
ARM: dts: rockchip: Remove clock-names from PWM nodes
dt-bindings: pwm: rockchip: Add more compatible strings
dt-bindings: pwm: Convert pwm-rockchip.txt to YAML
pwm: mediatek: Remove unused function
pwm: pca9685: Improve runtime PM behavior
pwm: pca9685: Support hardware readout
pwm: pca9685: Switch to atomic API
pwm: lpss: Don't modify HW state in .remove callback
pwm: sti: Free resources only after pwmchip_remove()
pwm: sti: Don't modify HW state in .remove callback
pwm: lpc3200: Don't modify HW state in .remove callback
pwm: lpc18xx-sct: Free resources only after pwmchip_remove()
pwm: bcm-kona: Don't modify HW state in .remove callback
pwm: bcm2835: Free resources only after pwmchip_remove()
...
- Add support for Software Nodes to MFD Core
- Remove support for Device Properties from MFD Core
- Use standard APIs in MFD Core
- New Drivers
- Add support for ROHM BD9576MUF and BD9573MUF PMICs
- Add support for Netronix Embedded Controller, PWM and RTC
- Add support for Actions Semi ATC260x PMICs and OnKey
- New Device Support
- Add support for DG1 PCIe Graphics Card to Intel PMT
- Add support for ROHM BD71815 PMIC to ROHM BD71828
- Add support for Tolino Shine 2 HD to Netronix Embedded Controller
- Add support for AX10 BMC Secure Updates to Intel M10 BMC
- Removed Device Support
- Remove Arizona Extcon support from MFD
- Remove ST-E AB8500 Power Supply code from MFD
- Remove AB3100 altogether
- New Functionality
- Add support for SMBus and I2C modes to Dialog DA9063
- Switch to using Software Nodes in Intel (various)
- New/converted Device Tree bindings; rohm,bd71815-pmic, rohm,bd9576-pmic,
netronix,ntxec, actions,atc260x,
ricoh,rn5t618, qcom-pm8xxx
- Fix-ups
- Fix error handling/path; intel_pmt
- Simplify code; rohm-bd718x7, ab8500-core, intel-m10-bmc
- Trivial clean-ups (reordering, spelling); rohm-generic, rn5t618, max8997
- Use correct data-type; db8500-prcmu
- Remove superfluous code; lp87565, intel_quark_i2c_gpi, lpc_sch, twl
- Use generic APIs/defines; lm3533-core, intel_quark_i2c_gpio
- Regmap related fix-ups; intel-m10-bmc, sec-core
- Reorder resource freeing during remove; intel_quark_i2c_gpio
- Make table indexing more robust; intel_quark_i2c_gpio
- Fix reference imbalances; arizona-irq
- Staticify and (un)constify things; arizona-spi, stmpe, ene-kb3930,
intel-lpss-acpi, intel-lpss-pci,
atc260x-i2c, intel_quark_i2c_gpio
- Bug Fixes
- Fix incorrect (register) values; intel-m10-bmc
- Kconfig related fixes; ABX500_CORE
- Do not clear the Auto Reload Register; stm32-timers
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmCJIPEACgkQUa+KL4f8
d2FRZA//Xu9f8u2uLuIfuhxIjUUXOqIjRAFnkhKlgGZhKsY8BohjQ80Tj9yp6UKy
St6ABwACO0hJap4zL4FxPW9+HXTmqZvAibnvHnvZdYSQ3ai6x9h6kTNvhSNLeRQU
fuY7eN8kpAHHiHNKNJCsQLQMvcIyP7+0KAP6qir5GYsMjiXspWq7THUnfBi2JXC6
y60guDo9XrgmQTO+pB870UJrKLM/h+iiohNRGxLFlShKhFCgbTB/wyw6bFeKy1SB
0/6XuY6fOt1IQyBDuzw383Q2faMWO9U+es29bwvFxdqJDK0MHQXC47zBba2q94wL
/9i/HSoz9dRHnTJNYUKWsVcPv4T84w/Iq7scyDvE00ubehJ+oo/M7Au3M6Tt3M1/
6lBAwFYXiwhQnp9EP3nwPwgJF6JzX1IGuMOsUAqrVFOEMuIkZKbRdUlatUhqepJT
spV4/TOfztAhY/7BzEOZLnF8cFNjmL5sn42/UzSRW708V5SxuTNsS48KJ4l0c7Er
CZSTlR/T1rKkWqf7ejaS2TNqMCdYyB3vZW0quDxZTHTZHv9huNUvtbKPR7jmd+4p
mrMIik7EE4BzC5m8tBPnXXZl+Og0keeYv4LUDBuLDX1agrxYIErl4ITvQTqqMfX1
Jt14SIjSO56iu2ngQuvGWwegVK4/urO2kBJKUAH1QN1OocNaajQ=
=IJSL
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Core Framework:
- Add support for Software Nodes to MFD Core
- Remove support for Device Properties from MFD Core
- Use standard APIs in MFD Core
New Drivers:
- Add support for ROHM BD9576MUF and BD9573MUF PMICs
- Add support for Netronix Embedded Controller, PWM and RTC
- Add support for Actions Semi ATC260x PMICs and OnKey
New Device Support:
- Add support for DG1 PCIe Graphics Card to Intel PMT
- Add support for ROHM BD71815 PMIC to ROHM BD71828
- Add support for Tolino Shine 2 HD to Netronix Embedded Controller
- Add support for AX10 BMC Secure Updates to Intel M10 BMC
Removed Device Support:
- Remove Arizona Extcon support from MFD
- Remove ST-E AB8500 Power Supply code from MFD
- Remove AB3100 altogether
New Functionality:
- Add support for SMBus and I2C modes to Dialog DA9063
- Switch to using Software Nodes in Intel (various)
New/converted Device Tree bindings:
- rohm bd71815-pmic, rohm bd9576-pmic, netronix ntxec, actions
atc260x, ricoh rn5t618, qcom pm8xxx
- Fix-ups:
- Fix error handling/path; intel_pmt
- Simplify code; rohm-bd718x7, ab8500-core, intel-m10-bmc
- Trivial clean-ups (reordering, spelling); rohm-generic, rn5t618,
max8997
- Use correct data-type; db8500-prcmu
- Remove superfluous code; lp87565, intel_quark_i2c_gpi, lpc_sch, twl
- Use generic APIs/defines; lm3533-core, intel_quark_i2c_gpio
- Regmap related fix-ups; intel-m10-bmc, sec-core
- Reorder resource freeing during remove; intel_quark_i2c_gpio
- Make table indexing more robust; intel_quark_i2c_gpio
- Fix reference imbalances; arizona-irq
- Staticify and (un)constify things; arizona-spi, stmpe, ene-kb3930,
intel-lpss-acpi, intel-lpss-pci, atc260x-i2c, intel_quark_i2c_gpio
Bug Fixes:
- Fix incorrect (register) values; intel-m10-bmc
- Kconfig related fixes; ABX500_CORE
- Do not clear the Auto Reload Register; stm32-timers"
* tag 'mfd-next-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (84 commits)
mfd: intel-m10-bmc: Add support for MAX10 BMC Secure Updates
Revert "mfd: max8997: Add of_compatible to Extcon and Charger mfd_cell"
mfd: twl: Remove unused inline function twl4030charger_usb_en()
dt-bindings: mfd: Convert pm8xxx bindings to yaml
dt-bindings: mfd: Add compatible for pmk8350 rtc
i2c: designware: Get rid of legacy platform data
mfd: intel_quark_i2c_gpio: Convert I²C to use software nodes
mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000"
mfd: arizona: Fix rumtime PM imbalance on error
mfd: max8997: Replace 8998 with 8997
mfd: core: Use acpi_find_child_device() for child devices lookup
mfd: intel_quark_i2c_gpio: Don't play dirty trick with const
mfd: intel_quark_i2c_gpio: Enable MSI interrupt
mfd: intel_quark_i2c_gpio: Reuse BAR definitions for MFD cell indexing
mfd: ntxec: Support for EC in Tolino Shine 2 HD
mfd: stm32-timers: Avoid clearing auto reload register
mfd: intel_quark_i2c_gpio: Replace I²C speeds with descriptive definitions
mfd: intel_quark_i2c_gpio: Remove unused struct device member
mfd: intel_quark_i2c_gpio: Unregister resources in reversed order
mfd: Kconfig: ABX500_CORE should depend on ARCH_U8500
...
In the calculation of the register value determining the duty cycle the
requested period is used instead of the actually implemented period which
results in suboptimal settings.
The following example assumes an input clock of 133333333 Hz on one of
the SoCs with 16 bit period.
When the following state is to be applied:
.period = 414727681
.duty_cycle = 652806
the following register values used to be calculated:
PRES = 10
CPRD = 54000
CDTY = 53916
which yields an actual duty cycle of a bit more than 645120 ns.
The setting
PRES = 10
CPRD = 54000
CDTY = 53915
however yields a duty of 652800 ns which is between the current result
and the requested value and so is a better approximation.
The reason for this error is that for the calculation of CDTY the
requested period was used instead of the actually implemented one.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The CDTY register contains the number of inactive cycles. .apply() does
this correctly, however .get_state() got this wrong.
Fixes: 651b510a74 ("pwm: atmel: Implement .get_state()")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add driver for the PWM controller on Toshiba Visconti ARM SoC.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: fix up a couple of checkpatch warnings]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <clemens.gruber@pqgruber.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <clemens.gruber@pqgruber.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Before pwmchip_remove() returns the PWM is expected to be functional. So
remove the pwmchip before disabling the clocks.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
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>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Before pwmchip_remove() returns the PWM is expected to be functional. So
remove the pwmchip before disabling the clock.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Before pwmchip_remove() returns the PWM is expected to be functional. So
remove the pwmchip before disabling the clock.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Before pwmchip_remove() returns the PWM is expected to be functional. So
remove the pwmchip before disabling the clock.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Before pwmchip_remove() returns the PWM is expected to be functional. So
remove the pwmchip before disabling the clock.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
pwmchip_add() only calls pwmchip_add_with_polarity() and nothing else. All
other users of pwmchip_add_with_polarity() are gone. So drop
pwmchip_add_with_polarity() and move the code instead to pwmchip_add().
The initial assignment to pwm->state.polarity is dropped. In every correct
usage of the PWM API this value is overwritten later anyhow.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The only side effect of this change is that pwm->state.polarity is
initialized to PWM_POLARITY_NORMAL instead of PWM_POLARITY_INVERSED.
However all other members of pwm->state are uninitialized and consumers
are expected to provide the right polarity (either by setting it explicitly
or by using a helper like pwm_init_state() that overwrites .polarity
anyhow with a value independent of the initial value).
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The only side effect of this change is that pwm->state.polarity is
initialized to PWM_POLARITY_NORMAL instead of PWM_POLARITY_INVERSED.
However all other members of pwm->state are uninitialized and consumers
are expected to provide the right polarity (either by setting it explicitly
or by using a helper like pwm_init_state() that overwrites .polarity
anyhow with a value independent of the initial value).
The eventual goal is to remove pwmchip_add_with_polarity() and so simplify
the data flow in the PWM core.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver only supports normal polarity and so should refuse requests
for inversed polarity.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver only supports normal polarity and so should refuse requests
for inversed polarity.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Otherwise the PWM stops working before the PWM core and its consumers
are aware the device is going away.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is just pushing down the core's compat code down into the driver using
the legacy callback nearly unchanged. The call to .enable() was just
dropped from .config() because .apply() calls it unconditionally.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since commit 2b1c1a5d51 ("pwm: Use -EINVAL for unsupported polarity")
all drivers implementing the apply callback are unified to return
-EINVAL if an unsupported polarity is requested. Do the same in the
compat code for old-style drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since commit 5e5da1e9fb ("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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no need to split the dev_err() call in three lines.
Use a single line to improve readability.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Uwe Kleine-König
Colin Ian King
Alexander Sverdlin
Andy Shevchenko
Zou Wei
Clemens Gruber
Linus Torvalds
Nobuhiro Iwamatsu
Jiapeng Chong
Nicolas Saenz Julienne
Uwe Kleine-König
Fabio Estevam