IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The value of NSEC_PER_SEC << PWM_DUTY_WIDTH doesn't fix within a 32 bit
integer causing a build warning/error (and the value truncated):
drivers/pwm/pwm-tegra.c: In function ‘tegra_pwm_config’:
drivers/pwm/pwm-tegra.c:148:53: error: result of ‘1000000000 << 8’ requires 39 bits to represent, but ‘long int’ only has 32 bits [-Werror=shift-overflow=]
148 | required_clk_rate = DIV_ROUND_UP_ULL(NSEC_PER_SEC << PWM_DUTY_WIDTH,
| ^~
Explicitly cast to a u64 to ensure the correct result.
Fixes: cfcb68817fb3 ("pwm: tegra: Improve required rate calculation")
Signed-off-by: Steven Price <steven.price@arm.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
When dynamically scaling the PWM clock, the function
dev_pm_opp_set_rate() may set the PWM clock to a rate that is lower than
what is required. The clock rate requested when calling
dev_pm_opp_set_rate() is the minimum clock rate that is needed to drive
the PWM to achieve the required period. Hence, if the actual clock
rate is less than the requested clock rate, then the required period
cannot be achieved and configuring the PWM fails. Fix this by
calling clk_round_rate() to check if the clock rate that will be provided
is sufficient and if not, double the required clock rate to ensure the
required period can be attained.
Fixes: 8c193f4714 ("pwm: tegra: Optimize period calculation")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
For the case where dev_pm_opp_set_rate() is called to set the PWM clock
rate, the requested rate is calculated as ...
required_clk_rate = (NSEC_PER_SEC / period_ns) << PWM_DUTY_WIDTH;
The above calculation may lead to rounding errors because the
NSEC_PER_SEC is divided by 'period_ns' before applying the
PWM_DUTY_WIDTH multiplication factor. For example, if the period is
45334ns, the above calculation yields a rate of 5646848Hz instead of
5646976Hz. Fix this by applying the multiplication factor before
dividing and using the DIV_ROUND_UP macro which yields the expected
result of 5646976Hz.
Fixes: 1d7796bdb6 ("pwm: tegra: Support dynamic clock frequency configuration")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-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 pushed a variant of pwm_apply_legacy() into the driver that was
slightly simplified because the driver doesn't provide a .set_polarity()
callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Dividing by the result of a division looses precision because the result is
rounded twice. E.g. with clk_rate = 48000000 and period = 32760033 the
following numbers result:
rate = pc->clk_rate >> PWM_DUTY_WIDTH = 187500
hz = DIV_ROUND_CLOSEST_ULL(100ULL * NSEC_PER_SEC, period_ns) = 3052
rate = DIV_ROUND_CLOSEST_ULL(100ULL * rate, hz) = 6144
The exact result would be 6142.5061875 and (apart from rounding) this is
found by using a single division. As a side effect is also a tad
cheaper to calculate.
Also using clk_rate >> PWM_DUTY_WIDTH looses precision. Consider for
example clk_rate = 47999999 and period = 106667:
mul_u64_u64_div_u64(pc->clk_rate >> PWM_DUTY_WIDTH, period_ns,
NSEC_PER_SEC) = 19
mul_u64_u64_div_u64(pc->clk_rate, period_ns,
NSEC_PER_SEC << PWM_DUTY_WIDTH) = 20
(The exact result is 20.000062083332033.)
With this optimizations also switch from round-closest to round-down for
the period calculation. Given that the calculations were non-optimal for
quite some time now with variations in both directions which nobody
reported as a problem, this is the opportunity to align the driver's
behavior to the requirements of new drivers. This has several upsides:
- Implementation is easier as there are no round-nearest variants of
mul_u64_u64_div_u64().
- Requests for too small periods are now consistently refused. This was
kind of arbitrary before, where period_ns < min_period_ns was
refused, but in some cases min_period_ns isn't actually implementable
and then values between min_period_ns and the actual minimum were
rounded up to the actual minimum.
Note that the duty_cycle calculation isn't using the usual round-down
approach yet.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Status quo is that variables of type struct tegra_pwm_chip * are named
"pwm", "chip" or "pc". The two formers are all not optimal because
usually only struct pwm_device * variables are named "pwm" and "chip" is
usually used for variabled of type struct pwm_chip *.
So consistently use the same and non-conflicting name "pc".
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM on Tegra belongs to the core power domain and we're going to
enable GENPD support for the core domain. Now PWM must be resumed using
runtime PM API in order to initialize the PWM power state. The PWM clock
rate must be changed using OPP API that will reconfigure the power domain
performance state in accordance to the rate. Add runtime PM and OPP
support to the PWM driver.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.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>
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>
Added support for dynamic clock freq configuration in PWM kernel driver.
Earlier the PWM driver used to cache boot time clock rate by PWM clock
parent during probe. Hence dynamically changing PWM frequency was not
possible for all the possible ranges. With this change, dynamic
calculation is enabled and it is able to set the requested period from
sysfs knob provided the value is supported by clock source.
Changes mainly have 2 parts:
- Tegra186 and later chips [1]
- Tegra210 and prior chips [2]
For [1] - Changes implemented to set pwm period dynamically and also
checks added to allow only if requested period(ns) is below or
equals to higher range.
For [2] - Only checks if the requested period(ns) is below or equals to
higher range defined by max clock limit. The limitation in
Tegra210 or prior chips are due to the reason of having only
one PWM controller supporting multiple channels. But later
chips have multiple PWM controller instances each having
single channel support.
Signed-off-by: Sandipan Patra <spatra@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Tegra194 has multiple PWM controllers with each having only one output.
Also the maxmimum frequency is higher than earlier SoCs.
Add support for Tegra194 and specify the number of PWM outputs and
maximum supported frequency using device tree match data.
Signed-off-by: Sandipan Patra <spatra@nvidia.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Based on 2 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 as published by
the free software foundation either version 2 of the license or at
your option any later version 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 write to the free software foundation inc
51 franklin street fifth floor boston ma 02110 1301 usa
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option [no]_[pad]_[ctrl] any later version 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 write to the free
software foundation inc 51 franklin street fifth floor boston ma
02110 1301 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 176 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com>
Reviewed-by: Steve Winslow <swinslow@gmail.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190519154040.652910950@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's common to follow a device tree ID table by the MODULE_DEVICE_TABLE
immediately, without an extra blank line between.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-pwm@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM hardware IP is taped-out with different maximum frequency
on different SoCs.
From HW team:
Before Tegra186, it is 48 MHz.
In Tegra186, it is 102 MHz.
Add support to limit the clock source frequency to the maximum IP
supported frequency. Provide these values via SoC chipdata.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It is required to know the PWM clock source frequency to calculate the
PWM period.
In driver, the clock source frequency of the PWM does not get change
and, hence, get the clock source frequency in driver init. Get this
values later for period calculation from pwm_config().
This will help in avoiding the clock call for getting clock rate in the
pwm_config() each time.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
For very short periods, the result of the division might overflow the
unsigned long hz variable (on 32-bit architectures). Avoid that by
making it an unsigned long long. While at it, also remove an unneeded
local variable whose only purpose is to store a temporary computation.
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In some of NVIDIA Tegra's platform, PWM controller is used to
control the PWM controlled regulators. PWM signal is connected to
the VID pin of the regulator where duty cycle of PWM signal decide
the voltage level of the regulator output.
When system enters suspend, some PWM client/slave regulator devices
require the PWM output to be tristated.
Add support to configure the pin state via pinctrl frameworks in
suspend and active state of the system.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The rate of the PWM calculated as follows:
hz = NSEC_PER_SEC / period_ns;
rate = (rate + (hz / 2)) / hz;
This has the precision loss in lower PWM rate.
Change this to have more precision as:
hz = DIV_ROUND_CLOSEST_ULL(NSEC_PER_SEC * 100, period_ns);
rate = DIV_ROUND_CLOSEST(rate * 100, hz)
Example:
1. period_ns = 16672000, PWM clock rate is 200 KHz.
Based on old formula
hz = NSEC_PER_SEC / period_ns
= 1000000000ul/16672000
= 59 (59.98)
rate = (200K + 59/2)/59 = 3390
Based on new method:
hz = 5998
rate = DIV_ROUND_CLOSE(200000*100, 5998) = 3334
If we measure the PWM signal rate, we will get more accurate
period with rate value of 3334 instead of 3390.
2. period_ns = 16803898, PWM clock rate is 200 KHz.
Based on old formula:
hz = 59, rate = 3390
Based on new formula:
hz = 5951, rate = 3360
The PWM signal rate of 3360 is more near to requested period
than 3333.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use macro DIV_ROUND_CLOSEST_ULL() for 64-bit division to closest one
instead of implementing the same locally. This increase readability.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Tegra186 has multiple PWM controllers with only one output instead of
one controller with four outputs in earlier SoC generations.
Add support for Tegra186 and detect the number of PWM outputs using
device tree match data.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
duty_ns * (1 << PWM_DUTY_WIDTH) could overflow in integer calculation
when the PWM rate is low. Hence do all calculation on unsigned long long
to avoid overflow.
Signed-off-by: Hyong Bin Kim <hyongbink@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To get 100 % duty cycle (always high), pulse width needs to be set to
256.
Signed-off-by: Victor(Weiguo) Pan <wpan@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add reset control of the PWM controller to reset it before
accessing the PWM register.
Signed-off-by: Rohith Seelaboyina <rseelaboyina@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The former is much longer to type and is ambiguous because the value
stored in the field is not the (physical) base address of the memory-
mapped I/O registers, but the virtual address of those registers as
mapped through the MMU.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This macro is used to initialize the ->npwm field of the PWM chip. Use a
literal instead and make all other places rely on ->npwm.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Some PWM drivers are testing the PWMF_ENABLED flag. Create a helper
function to hide the logic behind enabled test. This will allow us to
smoothly move from the current approach to an atomic PWM update
approach.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Instead of using the literal value for the number of nanoseconds per
second, use the macro instead to increase readability.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 <thierry.reding@gmail.com>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
A few drivers already annotate this properly. Make the same change for
all other OF supporting drivers.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
A new driver has been added to support the PWM mode of the timer counter
blocks found on Atmel AT91 SoCs. The VT8500 driver now supports changing
the PWM signal polarity and the TI drivers (EHRPWM and ECAP) gained
suspend and resume functionality.
User drivers can now query the core for whether access to a PWM device
will sleep (if the PWM chip is on a slow bus such as I2C or SPI).
The pwm-backlight driver now handles the backlight BL_CORE_FBBLANK state
in addition to the FB layer's blanking states.
To round things off, a few fixes and cleanups are also included.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRKxfbAAoJEN0jrNd/PrOhcwEP/0plVf30QDMhcan1GR3l+jmK
3Q/cCNIWEZ75mRu+FtVYKUOduxkCOHR6LM4C2ScGnnpsS/X5oitc45FrblIwQaEI
UeWVxDqI+pEp+rCdYVCND4lih60FJU0Cct0zZL2db4D4idF+8FRChhzwzSXhajnj
ZZqz782Y2ig3YTLHtVGT1pp61DKxdu1Gz4U+fxo4G1/fnkquCYDzbCQovcmPSnnF
gYB8hfxgT9JIt2cHrK6eKCHBF/4GToU+x5zDV2Ub15C2K/UQ+qgw82yl8MNd/ZS5
rFA06iW3icnJRRc8u6hu9WVjNVNTBrUqUlFhctNB01d5jF4R6uR6aEvovT9xe8NW
Wa5v5WrjnL6SWpZVwb/3kwwJmkeU9zKESQt5KUw3VKnT8yr2BfxcH1gJIiuW6wK7
uYqknAvt2rwMEGzaKZJmQH682wNMxpJirs8hG9VjJc/v7AOnk6586HbRupAq8wWZ
qK4n1Fto9RCg+b6e/hDId7+mN1GEcA5B8BOotPQ6ud+cinDZBKSbCSHhQG2LQ++F
m81BbL82H2R2ICRoYNA74/bKq5OVOFFqHLHg5bUrG7ikdNbYOTK/4dF9qSS7DnT3
Bi6WnKpOtfpWbHBnDunP2vBFo3f+gXmbLJdgarxk7mneV8wp0GY6TYI1awWn0hI9
82JP3yiK5kW2JZv92o0H
=Fcxi
-----END PGP SIGNATURE-----
Merge tag 'for-3.9-rc1' of git://gitorious.org/linux-pwm/linux-pwm
Pull PWM changes from Thierry Reding:
"A new driver has been added to support the PWM mode of the timer
counter blocks found on Atmel AT91 SoCs. The VT8500 driver now
supports changing the PWM signal polarity and the TI drivers (EHRPWM
and ECAP) gained suspend and resume functionality.
User drivers can now query the core for whether access to a PWM device
will sleep (if the PWM chip is on a slow bus such as I2C or SPI).
The pwm-backlight driver now handles the backlight BL_CORE_FBBLANK
state in addition to the FB layer's blanking states.
To round things off, a few fixes and cleanups are also included"
* tag 'for-3.9-rc1' of git://gitorious.org/linux-pwm/linux-pwm:
pwm: twl: Use to_twl() instead of container_of()
pwm: tegra: assume CONFIG_OF
pwm_backlight: Validate dft_brightness in main probe function
pwm: Export pwm_{set,get}_chip_data()
pwm: Make Kconfig entries more consistent
pwm: Add can_sleep property to drivers
pwm: Add pwm_can_sleep() as exported API to users
pwm-backlight: handle BL_CORE_FBBLANK state
pwm: pwm-tiecap: Low power sleep support
pwm: pwm-tiehrpwm: Low power sleep support
pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
pwm: vt8500: Add polarity support
pwm: vt8500: Register write busy test performed incorrectly
pwm: atmel: add Timer Counter Block PWM driver
Tegra only supports, and always enables, device tree. Remove all ifdefs
for DT support from the driver.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The implementation in devm_request_and_ioremap() already shows error message,
so no need to show dev_err again if devm_request_and_ioremap() fails.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Philip, Avinash <avinashphilip@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Also return proper error in tegra_pwm_remove() if pwmchip_remove()
fails.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Add auxdata to instantiate the PWFM controller from a device tree,
include the corresponding nodes in the dtsi files for Tegra 20 and
Tegra 30 and add binding documentation.
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
This commit adds a generic PWM framework driver for the PWFM controller
found on NVIDIA Tegra SoCs. The driver is based on code from the
Chromium kernel tree and was originally written by Gary King (NVIDIA)
and later modified by Simon Que (Chromium).
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
