When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.
When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:
base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.
This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).
Fixes: 684309e504 ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.
This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().
Note this effectively reverts commit 684309e504 ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.
Fixes: 684309e504 ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com
With enhanced error reporting from cros_ec_cmd_xfer_status() in place,
we can fully use it and no longer rely on EC error codes.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Since commit c5cd2b47b2 ("platform/chrome: cros_ec_proto: Report command
not supported") we can no longer assume that cros_ec_cmd_xfer_status()
reports -EPROTO for all errors returned by the EC itself. A follow-up
patch will change cros_ec_cmd_xfer_status() to report additional errors
reported by the EC as distinguished Linux error codes.
Handle this change by no longer assuming that only -EPROTO is used
to report all errors returned by the EC itself. Instead, support both
the old and the new error codes.
Add a comment describing cros_ec_num_pwms() to explain its functionality.
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The plat-samsung directory and mach-s5pv210 can be build
completely independently, so split the two Kconfig symbols
CONFIG_PLAT_SAMSUNG and CONFIG_ARCH_S5PV210.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200806182059.2431-18-krzk@kernel.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The majority of this batch is conversion of the PWM period and duty
cycle to 64-bit unsigned integers, which is required so that some types
of hardware can generate the full range of signals that they're capable
of. The remainder is mostly minor fixes and cleanups.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl82iq0ZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoTXSD/9h6v8w/9oC9xDxEO+6vTF3
XNMWBO3PxzjNpI02bxYVMckb8J6AsDFwB+fsMnRvHooFXqi+/5iQvxyt6b8rTIRA
ThOEd+PJnX9l8P9I/k/5RbdiYA51GtJomDc1f85yCs6UaMnTMRj9+S3E7rWPW+LZ
azKegtqQloJxMM8w+MBS3+3w1c4h80tfHphU4DbNDCTS0Pq2rXK2B0BJq+oFWXS+
GpTut7jzbQBpVm5+pF/3YwjQ1ODoHL+LJYtjdYdFk0HJtddsGIzR8xFAci//maZj
NtbE6tFFSz97z18QCvHBNDySV3/qVIy+Pr2g141yv0uhjvJ3zms4uveD3wmxFSbZ
0LWaGdCRUbffI1g5uCWjSEspWo+oEY3A6LQ2RVpmNL44T/rvgZuYKbJmFSnM3qr5
DzB0gx5ZlagXGO9W1u4aif+VBfJdF7JUGWazbyZ1O36bSPF83T7db8Shok10Yx+J
DsmWaxDMxVE8DFNUOaoDHXUq8L8gW8OFKeBttO3zUwCCxpIn9qunwDiFqvlkQHgI
xVqC5Yp1oMqq5enYlLGLqnCahYuUXgBW91uyEpeB4hzZMhU2CTgei0bzHdu5xDE4
5ZDks2EZ7CibJJ2EKwWgIF8iVkpepdXj0Wpy7HT6FStR2/kauT58h36bLzhjbh54
GtD3Z5TDtV8lrabOfmk6pA==
=v6MG
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"The majority of this batch is conversion of the PWM period and duty
cycle to 64-bit unsigned integers, which is required so that some
types of hardware can generate the full range of signals that they're
capable of.
The remainder is mostly minor fixes and cleanups"
* tag 'pwm/for-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: bcm-iproc: handle clk_get_rate() return
pwm: Replace HTTP links with HTTPS ones
pwm: omap-dmtimer: Repair pwm_omap_dmtimer_chip's broken kerneldoc header
pwm: mediatek: Provide missing kerneldoc description for 'soc' arg
pwm: bcm-kona: Remove impossible comparison when validating duty cycle
pwm: bcm-iproc: Remove impossible comparison when validating duty cycle
pwm: iqs620a: Use lowercase hexadecimal literals for consistency
pwm: Convert period and duty cycle to u64
clk: pwm: Use 64-bit division function
backlight: pwm_bl: Use 64-bit division function
pwm: sun4i: Use nsecs_to_jiffies to avoid a division
pwm: sifive: Use 64-bit division macro
pwm: iqs620a: Use 64-bit division
pwm: imx27: Use 64-bit division macro
pwm: imx-tpm: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
drm/i915: Use 64-bit division macro
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Argument descriptions must be prepended with a '@' to be understood
by the kerneldoc tooling/parsers/validators.
Fixes the following W=1 warning:
drivers/pwm/pwm-omap-dmtimer.c:70: warning: Function parameter or member 'dm_timer_pdev' not described in 'pwm_omap_dmtimer_chip'
Cc: Tony Lindgren <tony@atomide.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Grant Erickson <marathon96@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Kerneldoc syntax is used, but not complete.
Descriptions are required for all arguments.
Fixes the following W=1 build warning:
drivers/pwm/pwm-mediatek.c:57: warning: Function parameter or member 'soc' not described in 'pwm_mediatek_chip'
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: John Crispin <blogic@openwrt.org>
Cc: Zhi Mao <zhi.mao@mediatek.com>
Cc: linux-pwm@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
'dc' here is an unsigned long, thus checking for <0 will always
evaluate to false.
Fixes the following W=1 warning:
drivers/pwm/pwm-bcm-kona.c:141:35: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-pwm@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
'duty' here is an unsigned int, thus checking for <0 will always
evaluate to false.
Fixes the following W=1 warning:
drivers/pwm/pwm-bcm-iproc.c:147:12: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-pwm@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The unicore32 port is removed from the kernel.
There is no point to keep stale PWM driver for this architecture.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Other drivers use lowercase hexadecimal literals, so convert the IQS620a
driver to do the same for consistency.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also use the right format specifiers in debug prints in both core.c,
pwm-stm32-lp.c as well as video/fbdev/ssd1307fb.c.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using nsecs_to_jiffies() which
does away with the need for a division operation.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM framework is going to change the PWM period and duty cycles to
be 64-bit unsigned integers. To avoid build errors on platforms that do
not natively support 64-bit division, use explicity 64-bit division.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM framework is switching struct pwm_state.period's
datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULL to handle a 64-bit dividend.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The IS_ENABLED() use was missing the CONFIG_ prefix which would have
lead to skipping this code.
Fixes: 3ad1f3a332 ("pwm: Implement some checks for lowlevel drivers")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To not trigger the warnings provided by CONFIG_PWM_DEBUG
- use up-rounding in .get_state()
- don't divide by the result of a division
- don't use the rounded counter value for the period length to calculate
the counter value for the duty cycle
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The way state->enabled is computed is rather convoluted and hard to
read - both branches of the if() actually do the exact same thing. So
remove the if(), and further simplify "<boolean condition> ? true :
false" to "<boolean condition>".
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Even in failed case of pm_runtime_get_sync(), the usage_count is
incremented. In order to keep the usage_count with correct value call
appropriate pm_runtime_put().
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
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>
The PWM hardware in the JZ4725B works the same as in the JZ4740, but has
only six channels available.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM in Ingenic SoCs starts in inactive state until the internal
timer reaches the duty value, then becomes active until the timer
reaches the period value. In theory, we should then use (period - duty)
as the real duty value, as a high duty value would otherwise result in
the PWM pin being inactive most of the time.
This is the reason why the duty value was inverted in the driver until
now, but it still had the problem that it would not start with the
active part.
To address this remaining issue, the common trick is to invert the
duty, and invert the polarity when the PWM is enabled.
Since the duty was already inverted, and we invert it again, we now
program the hardware for the requested duty, and simply invert the
polarity when the PWM is enabled.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Calculating the hardware value for the duty from the hardware value of
the period resulted in a precision loss versus calculating it from the
clock rate directly.
(Also remove a cast that doesn't really need to be here)
Fixes: f6b8a57000 ("pwm: Add Ingenic JZ4740 support")
Cc: <stable@vger.kernel.org>
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Depending on MACH_INGENIC prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Before commit cfc4c189bc ("pwm: Read initial hardware state at request
time"), a driver's get_state callback would get called once per PWM from
pwmchip_add().
pwm-lpss' runtime-pm code was relying on this, getting a runtime-pm ref for
PWMs which are enabled at probe time from within its get_state callback,
before enabling runtime-pm.
The change to calling get_state at request time causes a number of
problems:
1. PWMs enabled at probe time may get runtime suspended before they are
requested, causing e.g. a LCD backlight controlled by the PWM to turn off.
2. When the request happens when the PWM has been runtime suspended, the
ctrl register will read all 1 / 0xffffffff, causing get_state to store
bogus values in the pwm_state.
3. get_state was using an async pm_runtime_get() call, because it assumed
that runtime-pm has not been enabled yet. If shortly after the request an
apply call is made, then the pwm_lpss_is_updating() check may trigger
because the resume triggered by the pm_runtime_get() call is not complete
yet, so the ctrl register still reads all 1 / 0xffffffff.
This commit fixes these issues by moving the initial pm_runtime_get() call
for PWMs which are enabled at probe time to the pwm_lpss_probe() function;
and by making get_state take a runtime-pm ref before reading the ctrl reg.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1828927
Fixes: cfc4c189bc ("pwm: Read initial hardware state at request time")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Allwinner A64 is capable of a direct clock output on PWM (see A64 User
Manual chapter 3.10). Add support for this in the sun4i PWM driver.
Signed-off-by: Peter Vasil <peter.vasil@gmail.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds support for the Azoteq IQS620A, capable of generating
a 1-kHz PWM output with duty cycle between ~0.4% and 100% (inclusive).
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.
Fixes: 3ad1f3a332 ("pwm: Implement some checks for lowlevel drivers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This driver allows pwms to be requested as gpios via gpiolib. Obviously,
it should not be allowed to request a GPIO when its corresponding PWM is
already requested (and vice versa). So it requires some exclusion code.
Given that the PWMm and GPIO cores are not synchronized with respect to
each other, this exclusion code will also require proper
synchronization.
Such a mechanism was in place, but was inadvertently removed by Uwe's
clean-up in commit e926b12c61 ("pwm: Clear chip_data in pwm_put()").
Upon revisiting the synchronization mechanism, we found that
theoretically, it could allow two threads to successfully request
conflicting PWMs/GPIOs.
Replace with a bitmap which tracks PWMs in-use, plus a mutex. As long as
PWM and GPIO's respective request/free functions modify the in-use
bitmap while holding the mutex, proper synchronization will be
guaranteed.
Reported-by: YueHaibing <yuehaibing@huawei.com>
Fixes: e926b12c61 ("pwm: Clear chip_data in pwm_put()")
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.org/lkml/2019/5/31/963
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[cg: Tested on an i.MX6Q board with two NXP PCA9685 chips]
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> # cg's rebase
Link: https://lore.kernel.org/lkml/20200330160238.GD2817345@ulmo/
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Fix the following gcc warning:
drivers/pwm/core.c:467:6: warning: symbol 'pwm_apply_state_debug' was
not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The variable fin_freq 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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The TCU channels 0 and 1 were previously reserved for system tasks, and
thus unavailable for PWM.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Mathieu Malaterre <malat@debian.org>
Tested-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The TCU registers are shared between a handful of drivers, accessing
them through the same regmap.
While this driver is devicetree-compatible, it is never (as of now)
probed from devicetree, so this change does not introduce a ABI problem
with current devicetree files.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Mathieu Malaterre <malat@debian.org>
Tested-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The previous algorithm hardcoded details about how the TCU clocks work.
The new algorithm will use clk_round_rate to find the perfect clock rate
for the PWM channel.
This code relies on the fact that clk_round_rate() will always round
down, which is not a valid assumption given by the clk API, but only
happens to be true with the clk drivers used for Ingenic SoCs.
Right now, there is no alternative as the clk API does not have a
round-down function (and won't have one for a while), but if it ever
comes to light, a round-down function should be used instead.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Mathieu Malaterre <malat@debian.org>
Tested-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The ingenic-timer "TCU" driver provides us with clocks, that can be
(un)gated, reparented or reclocked from devicetree, instead of having
these settings hardcoded in this driver.
The new code now uses a clk pointer per PWM (instead of a clk per
pwm-chip before). So the pointer is stored in per-pwm data now.
The calls to arch-specific timer code is replaced with standard
clock API calls to start and stop each channel's clock.
While this driver is devicetree-compatible, it is never (as of now)
probed from devicetree, so this change does not introduce a ABI problem
with current devicetree files.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Mathieu Malaterre <malat@debian.org>
Tested-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
'needs_delay' does now always evaluate to true, so remove all
occurrences.
Signed-off-by: Pascal Roeleven <dev@pascalroeleven.nl>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement .apply callback and drop the legacy callbacks(enable, disable,
config, set_polarity). In .apply() check for the current hardware status
before changing the PWM configuration.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Only the Timer control register(TCLR) cannot be updated when the timer
is running. Registers like Counter register (TCRR), loader register
(TLDR) and match register (TMAR) can be updated while the counter is
running. Since TCLR is not updated in pwm_omap_dmtimer_config(), do not
stop the timer for period/duty_cycle update.
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To configure DM timer in PWM mode the following needs to be set in
OMAP_TIMER_CTRL_REG using set_pwm callback:
- Set toggle mode on PORTIMERPWM output pin
- Set trigger on overflow and match on PORTIMERPWM output pin.
- Set auto reload
This is a one time configuration and needs to be set before the start of
the DM timer. But the current driver tries to set the same configuration
for every period/duty cycle update, which is not needed. So move the PWM
setup before enabling timer and do not update it in
pwm_omap_dmtimer_config().
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Update the description with a brief about how PWM is generated using
OMAP DM timer and add limitations for the PWM generations. Also add a
link to the reference manual.
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwm_omap_dmtimer.h is used only:
- to typedef struct omap_dm_timer to pwm_omap_dmtimer
- for macro PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE
Rest of the file is pretty mush unsed. So reuse omap_dm_timer
and OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE in pwm-omap-dmtimer.c
and delete the header file.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
During device probe, the message
TPU PWM -1 registered
is printed.
While the "-1" looks suspicious, it is perfectly normal for a device
instantiated from DT.
Remove the message, as there are no non-DT users left, and other drivers
don't print such messages either.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Runtime PM should be enabled before calling pwmchip_add(), as PWM users
can appear immediately after the PWM chip has been added.
Likewise, Runtime PM should always be disabled after the removal of the
PWM chip, even if the latter failed.
Fixes: 99b82abb0a ("pwm: Add Renesas TPU PWM driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Runtime PM should be enabled before calling pwmchip_add(), as PWM users
can appear immediately after the PWM chip has been added.
Likewise, Runtime PM should be disabled after the removal of the PWM
chip.
Fixes: ed6c1476bf ("pwm: Add support for R-Car PWM Timer")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
GPIO core recently added macro to uniformly specify direction of a GPIO
line, so use it.
Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The __maybe_unused attribute is preferred over CONFIG_PM to prevent
potential build time issues. This commit replaces CONFIG_PM with this
attribute.
Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
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>
Some of the PWM drivers can be compile tested to increase build
coverage.
The Meson PWM driver requires COMMON_CLK dependency.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com> # For Broadcoam
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # For Meson
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com> # For Atmel
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
duty_cycle was only set, never read.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is nothing in use from of_address.h, remove it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is nothing in use from of_device.h, remove it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is nothing in use from log2.h/of_address.h, remove them.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There are some expectations which the callbacks provided by lowlevel
drivers should fulfill. Implement checks that help driver authors to get
these semantics right. As these have some overhead the checks can be
disabled using a Kconfig setting.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Up to now the .probe() function didn't enable clocks and relied on the
core to call the .get_state() callback to have the clock running. The
latter enabled the needed clocks and kept them running if the PWM wass
enabled.
This only works correctly if the .get_state() callback is called exactly
once and this single call happens before unused clocks are disabled by
the clk core.
The former wasn't true for a short period while commit 01ccf903ed
("pwm: Let pwm_get_state() return the last implemented state") applied
and not reverted yet and might become wrong in the future.
The latter isn't true any more since commit cfc4c189bc ("pwm: Read
initial hardware state at request time") which results in a running PWM
being stopped at boot time if for example the consumer lives in a kernel
module that is only loaded after the clk core disabled unused clocks.
So ensure .probe() is left with the clocks on if the PWM is running and
.get_state() disables everything it enabled.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The .remove() callback is not supposed to modify hardware state. This is
in the responsibility of the PWM consumer.
After the PWM was disabled the clocks are off (apart from a bug that is
fixed in the next patch), so unbinding the driver either stops the PWM
(which it should not) or disables already disabled clocks yielding
warnings from the clk core.
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>
pwm_imx27_clk_prepare_enable() took a pointer to a struct pwm_chip just
to convert it to a struct pwm_imx27_chip pointer while all callers
already have the latter. Ditto for pwm_imx27_clk_disable_unprepare().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwm_imx27_apply() enables the clocks if the previous PWM state was
disabled. Given that the clocks are supposed to be left on iff the PWM
is running, the decision to disable the clocks at the end of the
function must not depend on the previous state.
Without this fix the enable count of the two affected clocks increases
by one whenever ->apply() changes from one disabled state to another.
Fixes: bd88d319ab ("pwm: imx27: Unconditionally write state to hardware")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The newer 2711 and 7211 chips have two PWM controllers and failure to
dynamically allocate the PWM base would prevent the second PWM
controller instance being probed for succeeding with an -EEXIST error
from alloc_pwms().
Fixes: e5a06dc5ac ("pwm: Add BCM2835 PWM driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
dm timer ops set_load() api allows to configure the load value and to
set the auto reload feature. But auto reload feature is independent of
load value and should be part of configuring pwm. This way pwm can be
disabled by disabling auto reload feature using set_pwm() so that the
current pwm cycle will be completed. Else pwm disabling causes the
cycle to be stopped abruptly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-7-lokeshvutla@ti.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/pwm/pwm-pca9685.c: In function ‘pca9685_pwm_gpio_free’:
drivers/pwm/pwm-pca9685.c:162:21: warning: variable ‘pwm’ set but not used [-Wunused-but-set-variable]
It is never used, and so can be removed. In that case, hold and release
the lock 'pca->lock' can be removed since nothing will be done between
them.
Fixes: e926b12c61 ("pwm: Clear chip_data in pwm_put()")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
GCC can't always determine that the duty, period and prescaler values
are initialized when returning from sun4i_pwm_calculate(), so help out a
little by initializing them to 0.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Don't use AOE (automatic output enable) by default. In case of break
events, PWM is automatically re-enabled on next PWM cycle otherwise.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The variable pval is only used in a single block in the function
sun4i_pwm_calculate(). So declare it in a more local scope to simplify
the function for humans and compilers.
While at it also simplify assignment to pval.
While the diffstat for this patch is negative for this patch I still
thing the advantage of having a narrower scope is beneficial.
In my compiler / .config setup (gcc 8.2.1, arm/imx_v6_v7_defconfig +
COMPILE_TEST + PWM_SUN4I) this change doesn't result in any binary
changes.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
BCM7211 is supported using ARCH_BRCMSTB and uses this PWM controller
driver, make it possible to build it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
For defer probe error, no need to output error message which
will cause confusion.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Fix inconsistent IS_ERR and PTR_ERR in sun4i_pwm_probe().
The proper pointers to be passed as arguments are pwm->clk and pwm->bus_clk.
This bug was detected with the help of Coccinelle.
Fixes: b8d74644f3 ("pwm: sun4i: Prefer "mod" clock to unnamed")
Fixes: 5b090b430d ("pwm: sun4i: Add an optional probe for bus clock")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwm_calculate() calls clk_get_rate() while holding a spin_lock().
This create an issue as clk_get_rate() may sleep.
Move pwm_calculate() out of this spin_lock().
Fixes: c32c5c50d4 ("pwm: sun4i: Switch to atomic PWM")
Reported-by: Alexander Finger <alex.mobigo@gmail.com>
Sugested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Alexander Finger <alex.mobigo@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The dependency on OMAP_DM_TIMER is only a runtime dependency. Also
OMAP_DM_TIMER cannot be enabled without ARCH_OMAP being enabled.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This was found by coccicheck:
drivers/pwm/pwm-omap-dmtimer.c:304:2-8: ERROR: missing put_device;
call of_find_device_by_node on line 255, but without a corresponding
object release within this function.
Reported-by: Markus Elfring <elfring@users.sourceforge.net>
Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Instead of doing error handling in the middle of ->probe(), move error
handling and freeing the reference to timer to the end.
This fixes a resource leak as dm_timer wasn't freed when allocating
*omap failed.
Implementation note: The put: label was never reached without a goto and
ret being unequal to 0, so the removed return statement is fine.
Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In the old code (e.g.) mutex_destroy() was called before
pwmchip_remove(). Between these two calls it is possible that a PWM
callback is used which tries to grab the mutex.
Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This allows to log all calls to the driver's lowlevel functions which
simplifies debugging in some cases.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When .apply() is called with state->duty_cycle = 0 the duty_ns parameter
to rcar_pwm_set_counter() is 0 which results in ph being 0 and
rcar_pwm_set_counter() returning -EINVAL.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwm_get_state has no side effects and the resulting pwm_state is unused.
So drop the call to pwm_get_state() and the local variable from
rcar_pwm_apply().
The call was introduced in commit 7f68ce8287 ("pwm: rcar: Add support
"atomic" API") and already then was useless.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This function reads back the configured parameters from the hardware. As
.apply() rounds down (mostly) I'm rounding up in .get_state() to achieve
that applying a state just read from hardware is a no-op.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This makes it a bit easier when instrumenting register access to only
have to add code in one place.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This documents the my findings while reading through the driver and the
reference manual.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The calculated values are the same with the modified algorithm. The only
difference is that the calculation is a bit more efficient.
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The maximal prescale value is 10 for all supported variants. So drop the
member in the variant description and introduce a global constant
instead.
This reduces the size of the variant descriptions and the .apply()
callback can be compiled a bit more effectively.
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Most Microchip (formerly Atmel) chips have publicly available manuals.
A comprehensive list is already contained in the documentation folder.
Reference this list in the header of the driver to allow reviewers to
find the relevant manuals.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the divisor is not a compile-time constant (unless gcc somehow
decided to unroll the loop PERIOD_CDIV_MAX times), this does a
somewhat expensive 32/32 division. Replace that with a right shift.
We still have a 64/32 division just below, but at least in that
case the divisor is compile-time constant.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If I'm reading of_pwm_xlate_with_flags() right, existing device trees
that set #pwm-cells = 2 will continue to work.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since we now have ->apply(), these are no longer relevant.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In preparation for supporting setting the polarity, switch the driver
to support the ->apply() method.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Now that sun4i PWM driver supports deasserting reset line and enabling
bus clock, support for H6 PWM can be added.
Note that while H6 PWM has two channels, only first one is wired to
output pin. Second channel is used as a clock source to companion AC200
chip which is bundled into same package.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
PWM core has an option to bypass whole logic and output unchanged source
clock as PWM output. This is achieved by enabling bypass bit.
Note that when bypass is enabled, no other setting has any meaning, not
even enable bit.
This mode of operation is needed to achieve high enough frequency to
serve as clock source for AC200 chip which is integrated into same
package as H6 SoC.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Bypass mode will require to be re-calculated when the pwm state
is changed.
Remove the condition so pwm_sun4i_calculate is always called.
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
H6 PWM core needs bus clock to be enabled in order to work.
Add an optional probe for it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
New device tree bindings called the source clock of the module
"mod" when several clocks are defined.
Try to get a clock called "mod" if nothing is found try to get
an unnamed clock.
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
H6 PWM core needs deasserted reset line in order to work.
Add an optional probe for it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The i.MX driver currently uses a shortcut and doesn't write all of the
state through to the hardware when the PWM is disabled. This causes an
inconsistent state to be read back by consumers with the result of them
malfunctioning.
Fix this by always writing the full state through to the hardware
registers so that the correct state can always be read back.
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Tested-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The hardware register containing the duty cycle value cannot be accessed
when the PWM is disabled. This causes the ->get_state() callback to read
back a duty cycle value of 0, which can confuse consumer drivers.
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Tested-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The ChromeOS embedded controller doesn't differentiate between disabled
and duty cycle being 0. In order not to potentially confuse consumers,
cache the duty cycle and return the cached value instead of the real
value when the PWM is disabled.
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Drivers that support reading the hardware state (using ->get_state())
may want to rely on per-PWM data to do so. Defer reading the hardware
state for the first time until the PWM has been requested and after
drivers have had a chance to allocate per-PWM data.
Conceptually this is also a more natural place to read the hardware
state because the PWM core doesn't need to know the hardware state of a
PWM unless there is a user for it. This also ensures that the state is
read everytime a user requests a PWM. If the PWM changes between users
for some reason, the PWM core will reload the state from hardware and
keep its copy of the state up-to-date.
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Various changes and minor fixes across a couple of drivers.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl3ovpUZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zof9HD/9cawfrzpRp/wi/zt7BP2zk
po/ttwso/9HsbhaEp8WyRBIeqTRh/D0BMT81UuaJZzus9qdcRycbwtoyKO1xnlWo
LKHrpD/PvhJGjLGqEIymQm34o7hsvdwVGKkd2nisl2tNe2CNljcBO7DnnajM6qWX
0YaU6EE+SnZ/ApN6R3vF9IJZ+z8TJm2KLYHVupRxh0BDLGtbufNlpY7nTtOi1ADW
ZaUTiVgEuJleGDwL+lNzdtWbzbBQGN/GnbpwutYJRsXuBNpYQNAS/WNOtZbi8BAv
rxHPc4WLrqTm9yLgCgYY5SpjBZNbdN/liE7R0Lu5d4C3NleraSiTIHW5T5xnxitY
PwShHszUIkKP4IadMLCbzlqRetcU6p3WNMivH7T6KHocTSCZDW0wmUs7YHrOLpfF
EK6fJruRgcHdpPmMgPm0PAdKXeDSjkaCBDHms47A6JDsLnNYG8Oo0AyT9GFGdqz5
Sd0yOZeuUo+HSboJ19bZShfv+bAILdFqyiHfbZqzTBsKTqzBxEZXZKfWvnAgUCPh
XisghxLlOtnUGD0Z2U22T0hTRNb7l/TCf8gRFL8X81qZnhxS9naXjdi5lvSuY+NA
6jw6N+GMwXUDmOYmN4HV9C39BNvUYzLoijYjUA/UPr3M2IKdX52hVhGo4B4gHVJB
0ylTmeN83Bf9fU7j3VkmHg==
=Sd9F
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"Various changes and minor fixes across a couple of drivers"
* tag 'pwm/for-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: stm32: Pass breakinput instead of its values
pwm: stm32: Remove clutter from ternary operator
pwm: stm32: Validate breakinput data from DT
pwm: Update comment on struct pwm_ops::apply
pwm: sun4i: Fix incorrect calculation of duty_cycle/period
pwm: stm32: Add power management support
pwm: stm32: Split breakinput apply routine to ease PM support
dt-bindings: pwm-stm32: Document pinctrl sleep state
pwm: sun4i: Drop redundant assignment to variable pval
dt-bindings: pwm: mediatek: Remove gratuitous compatible string for MT7629
The owner member of struct pwm_ops must be set to THIS_MODULE to
increase the reference count of the module such that the module cannot
be removed while its code is in use.
Fixes: daa5abc41c ("pwm: Add support for Broadcom iProc PWM controller")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Remove usage of the ternary operator to assign values for register
fields. Instead, parameterize the register and field offset macros
and pass the index to them.
This removes clutter and improves readability.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Both index and level can only be either 0 or 1 and the filter value is
limited to values between (and including) 0 and 15. Validate that the
device tree node contains values that are within these ranges.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since 5.4-rc1, pwm_apply_state calls ->get_state after ->apply
if available, and this revealed an issue with integer precision
when calculating duty_cycle and period for the currently set
state in ->get_state callback.
This issue manifested in broken backlight on several Allwinner
based devices.
Previously this worked, because ->apply updated the passed state
directly.
Fixes: deb9c462f4 ("pwm: sun4i: Don't update the state for the caller of pwm_apply_state")
Signed-off-by: Ondrej Jirman <megous@megous.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add suspend/resume PM sleep ops. When going to low power, enforce the PWM
channel isn't active. Let the PWM consumers disable it during their own
suspend sequence, see [1]. So, perform a check here, and handle the
pinctrl states. Also restore the break inputs upon resume, as registers
content may be lost when going to low power mode.
[1] https://lkml.org/lkml/2019/2/5/770
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Split breakinput routine that configures STM32 timers 'break' safety
feature upon probe, into two routines:
- stm32_pwm_apply_breakinputs() sets all the break inputs into registers.
- stm32_pwm_probe_breakinputs() probes the device tree break input settings
before calling stm32_pwm_apply_breakinputs()
This is a precursor patch to ease PM support. Registers content may get
lost during low power. So, break input settings applied upon probe need
to be restored upon resume (e.g. by calling stm32_pwm_apply_breakinputs()).
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Variable pval is being assigned a value that is never read. The
assignment is redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It turns out that commit 01ccf903ed ("pwm: Let pwm_get_state() return
the last implemented state") causes backlight failures on a number of
boards. The reason is that some of the drivers do not write the full
state through to the hardware registers, which means that ->get_state()
subsequently does not return the correct state. Consumers which rely on
pwm_get_state() returning the current state will therefore get confused
and subsequently try to program a bad state.
Before this change can be made, existing drivers need to be more
carefully audited and fixed to behave as the framework expects. Until
then, keep the original behaviour of returning the software state that
was applied rather than reading the state back from hardware.
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The TI PWMSS driver is a simple bus driver for providing power
power management for the PWM peripherals on TI AM33xx SoCs, namely
eCAP, eHRPWM and eQEP. The eQEP is a counter rather than a PWM, so
it does not make sense to have the bus driver in the PWM subsystem
since the PWMSS is not exclusive to PWM devices.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Besides one new driver being added for the PWM controller found in
various Spreadtrum SoCs, this series of changes brings a slew of, mostly
minor, fixes and cleanups for existing drivers, as well as some
enhancements to the core code.
Lastly, Uwe is added to the PWM subsystem entry of the MAINTAINERS file,
making official his role as a reviewer.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl2ON5UZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoVg2EAC2QP51EywsDVQd8ZFvXBZB
SL2RN9EWY0nHFnjGL2VSEOvsWWoE2HgrzXbWuiKDSkpRMTGtz/R1VznmBegZpVz/
eKP1ebFU+1EQ2A1GB4VLGslGVs0R7uvQap7KMRf+nD6qzstwWlz5nPP8E/4dipAX
fYZBU37sTvAXycVosqAOiGaJvwfbo0ExysCD0bWccp52O06osgbZwGDhShDRTQv0
wOLR/rPbYXbVMyETlO8gjHVGU/N6cAq0SDR2VGcXqIe3H86K3R7ec8TEhcLJy6R5
nLX9Wx+gMyiWJGrU+s5i682VUdzQeLE4sH9c47M8qqreM4ytXfdttMeg3hgmalra
eVm4uWtJ2+ZDRSl+yqJ8GfuSVGV4S9uQNlJ0OkAizmz+mU2WGeM1v8aOFlGokSi0
mxt+EZFdS7M0rZpWU0Fv01urxdhhVgsFXkD72xldV2vnIP6afhzGgKN3S6zbwzAQ
WOgTHgVmcenM4hRcEmV8n7nF6f8BIA5RSNx+jrrkRD4gwHwDAiEK7hWJTCDXisB9
J6HgChqztrNtnyZMOealHxEgTtJqRUVX69mo9NaUeYps2Qg4y1gStLC3b1YnJZcI
sTCrKhVjhFn1bNOe1UBSvcehIorL3mFV203TBgJJaMMhoJYE28XqYTNkGVDZ2bLP
DdyExtL1Dx7IxEwS7IGOwA==
=C9sW
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"Besides one new driver being added for the PWM controller found in
various Spreadtrum SoCs, this series of changes brings a slew of,
mostly minor, fixes and cleanups for existing drivers, as well as some
enhancements to the core code.
Lastly, Uwe is added to the PWM subsystem entry of the MAINTAINERS
file, making official his role as a reviewer"
* tag 'pwm/for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (34 commits)
MAINTAINERS: Add myself as reviewer for the PWM subsystem
MAINTAINERS: Add patchwork link for PWM entry
MAINTAINERS: Add a selection of PWM related keywords to the PWM entry
pwm: mediatek: Add MT7629 compatible string
dt-bindings: pwm: Update bindings for MT7629 SoC
pwm: mediatek: Update license and switch to SPDX tag
pwm: mediatek: Use pwm_mediatek as common prefix
pwm: mediatek: Allocate the clks array dynamically
pwm: mediatek: Remove the has_clks field
pwm: mediatek: Drop the check for of_device_get_match_data()
pwm: atmel: Consolidate driver data initialization
pwm: atmel: Remove unneeded check for match data
pwm: atmel: Remove platform_device_id and use only dt bindings
pwm: stm32-lp: Add check in case requested period cannot be achieved
pwm: Ensure pwm_apply_state() doesn't modify the state argument
pwm: fsl-ftm: Don't update the state for the caller of pwm_apply_state()
pwm: sun4i: Don't update the state for the caller of pwm_apply_state()
pwm: rockchip: Don't update the state for the caller of pwm_apply_state()
pwm: Let pwm_get_state() return the last implemented state
pwm: Introduce local struct pwm_chip in pwm_apply_state()
...
This adds pwm support for MT7629, and separate mt7629 compatible string
from mt7622
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add SPDX identifiers to pwm-mediatek.c. Update MODULE_LICENSE to
correctly reflect the GNU General Public License v2.0.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use pwm_mediatek as common prefix to match the filename. No functional
change intended.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Instead of using fixed size of arrays, allocate the memory for them
based on the number of PWMs specified for each SoC generation.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
We can use fixed clocks to repair mt7628 PWM during configure from
userspace. The SoC is legacy MIPS and has no complex clock tree. Because
we can get the clock frequency for period calculation from fixed clocks
specified in DT, we can remove the has_clock field, and directly use
devm_clk_get() and clk_get_rate().
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch drop the check for of_device_get_match_data. Due to the only
way call driver probe is compatible match. The data pointer which points
to the SoC specify data is directly set by driver, and it should not be
NULL in our case. We can safety remove the check for the result of
of_device_get_match_data().
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the driver is now exclusively DT, it only binds if it finds a
match in the of_device_id table. But in that case the associated data
can never be NULL, so drop the unnecessary check.
While at it, drop the extra local variable and store the pointer to
this per-SoC data in the driver data directly.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since commit 26202873bb ("avr32: remove support for AVR32
architecture") there is no more user of platform_device_id and we
should only use dt bindings
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
LPTimer can use a 32KHz clock for counting. It depends on clock tree
configuration. In such a case, PWM output frequency range is limited.
Although unlikely, nothing prevents user from requesting a PWM frequency
above counting clock (32KHz for instance):
- This causes (prd - 1) = 0xffff to be written in ARR register later in
the apply() routine.
This results in badly configured PWM period (and also duty_cycle).
Add a check to report an error is such a case.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It is surprising for a PWM consumer when the variable holding the
requested state is modified by pwm_apply_state(). Consider for example a
driver doing:
#define PERIOD 5000000
#define DUTY_LITTLE 10
...
struct pwm_state state = {
.period = PERIOD,
.duty_cycle = DUTY_LITTLE,
.polarity = PWM_POLARITY_NORMAL,
.enabled = true,
};
pwm_apply_state(mypwm, &state);
...
state.duty_cycle = PERIOD / 2;
pwm_apply_state(mypwm, &state);
For sure the second call to pwm_apply_state() should still have
state.period = PERIOD and not something the hardware driver chose for a
reason that doesn't necessarily apply to the second call.
So declare the state argument as a pointer to a const type and adapt all
drivers' .apply callbacks.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The pwm-fsl-ftm driver is one of only three PWM drivers which updates
the state for the caller of pwm_apply_state(). This might have
surprising results if the caller reuses the values expecting them to
still represent the same state.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The pwm-sun4i driver is one of only three PWM drivers which updates the
state for the caller of pwm_apply_state(). This might have surprising
results if the caller reuses the values expecting them to still
represent the same state.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The pwm-rockchip driver is one of only three PWM drivers which updates
the state for the caller of pwm_apply_state(). This might have
surprising results if the caller reuses the values expecting them to
still represent the same state.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When pwm_apply_state() is called the lowlevel driver usually has to
apply some rounding because the hardware doesn't support nanosecond
resolution. So let pwm_get_state() return the actually implemented state
instead of the last applied one if possible.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwm->chip is dereferenced several times in the pwm_apply_state()
function. Introducing a local variable for it helps keeping some lines a
bit shorter.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Don't rely on *state being zero initialized and PWM_POLARITY_NORMAL
being zero. So always assign .polarity.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This suppresses error messages in case the PWM clock isn't ready yet.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The range check for period_ns was written under assumption of a fixed
PWM clock. With clk-bcm2835 driver the PWM clock is a dynamic one.
So fix this by doing the range check on the period register value.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM config can be triggered via sysfs, so we better suppress the
error message in case of an invalid period to avoid kernel log spamming.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the rcar_pwm_apply() has already checked whether state->enabled
is set or not, this patch removes a redundant condition.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds the Spreadtrum PWM support, which provides maximum 4
channels.
Signed-off-by: Neo Hou <neo.hou@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add the compatible and the platform data to support PWM on the MT8516
SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.
// <smpl>
@@
expression ret;
struct platform_device *E;
@@
ret =
(
platform_get_irq(E, ...)
|
platform_get_irq_byname(E, ...)
);
if ( \( ret < 0 \| ret <= 0 \) )
{
(
-if (ret != -EPROBE_DEFER)
-{ ...
-dev_err(...);
-... }
|
...
-dev_err(...);
)
...
}
// </smpl>
While we're here, remove braces on if statements that only have one
statement (manually).
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The JZ4740 PWM implementation doesn't fulfill the (up to now
insufficiently documented) requirements of the PWM API. At least
document them in the driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use the new helper devm_platform_ioremap_resource() which wraps the
platform_get_resource() and devm_ioremap_resource() together, to
simplify the code.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is a bit of mess between cros-ec mfd includes and platform
includes. For example, we have a linux/mfd/cros_ec.h include that
exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
we have a linux/mfd/cros_ec_commands.h file that is non related to the
multifunction device (in the sense that is not exporting any function of
the mfd device). This causes crossed includes between mfd and
platform/chrome subsystems and makes the code difficult to read, apart
from creating 'curious' situations where a platform/chrome driver includes
a linux/mfd/cros_ec.h file just to get the exported functions that are
implemented in another platform/chrome driver.
In order to have a better separation on what the cros-ec multifunction
driver does and what the cros-ec core provides move and rework the
affected includes doing:
- Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h
- Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c
driver from include/linux/mfd/cros_ec.h to a new file
include/linux/platform_data/cros_ec_proto.h
- Update all the drivers with the new includes, so
- Drivers that only need to know about the protocol include
- linux/platform_data/cros_ec_proto.h
- linux/platform_data/cros_ec_commands.h
- Drivers that need to know about the cros-ec mfd device also include
- linux/mfd/cros_ec.h
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Series changes: 3
- Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp)
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Now, the ChromeOS EC core driver has nothing related to an MFD device, so
move that driver from the MFD subsystem to the platform/chrome subsystem.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Commit 4a6ef8e37c ("pwm: Add support referencing PWMs from ACPI")
made pwm_get unconditionally return the acpi_pwm_get return value if
the device passed to pwm_get has an ACPI fwnode.
But even if the passed in device has an ACPI fwnode, it does not
necessarily have the necessary ACPI package defining its pwm bindings,
especially since the binding / API of this ACPI package has only been
introduced very recently.
Up until now X86/ACPI devices which use a separate pwm controller for
controlling their LCD screen's backlight brightness have been relying
on the static lookup-list to get their pwm.
pwm_get unconditionally returning the acpi_pwm_get return value breaks
this, breaking backlight control on these devices.
This commit fixes this by making pwm_get fall back to the static
lookup-list if acpi_pwm_get returns -ENOENT.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96571
Reported-by: youling257@gmail.com
Fixes: 4a6ef8e37c ("pwm: Add support referencing PWMs from ACPI")
Cc: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes contains a new driver for SiFive SoCs as well as
enhancements to the core (device links are used to track dependencies
between PWM providers and consumers, support for PWM controllers via
ACPI, sysfs will now suspend/resume PWMs that it has claimed) and
various existing drivers.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl0V/lAZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoS+uD/0cJqcVhX1c2S/pHg1k4QFh
wREnEbxMqWghcsSZcO0gk0hoRyxMNBM3iOldaKc3b5LVtEJOv/R7W6RB+FMcvPKA
AtW/ydyfRZiqL9bIXs0hhaW4Fo0WCq6gZksDU5cOoq4KMHfkEp7D7U158ItsEtga
ufDigs8fv/Z6c5DaEfoJ10I+VCy/We2YnCdIVZuL/MElFHlUupzRpGZv6uMRQ4WI
z2/SEtHURoW103a3UrEmjqv0GeoHPrHwEP9kZTUuakyMxPmUtrSUJRybi79Cf27B
jLYql8bXSkTsV6rUBtTRNtqQjD3hdjcFYaEdOle8n52/pYFohycmVvB/3xvr9tDC
Wildg4Rniv4lcteB1hqB0M5km/szXGjPx5wozvmctwOia5sogG+8DWGp0fZO8Gsp
vaF+GbTrM4LV1AzGJW7icTRFQG7VFUcZAglNW4o82hcXN1j9GpQ/qSOY3vgBigx+
vyWrbCHBH2zjJNh1sSl68zi5q90T9IlXFfgR61kujbHYws+KrO3BJE2SW7qsLhsf
HJnMBBxpoxvusBS/kbsWsDCnoGi4UsCeKUbmbfY1OjpCNlpp+cHSk6b4134Fmi66
D8B+a4C1I/CNhcV72P+hAdrva4UXB6oJi4hZDE2/tEioXQB2wJO4AwWzjpifqzBY
nGxZVPV7TuXj2KwCXDQnvw==
=nseo
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set of changes contains a new driver for SiFive SoCs as well as
enhancements to the core (device links are used to track dependencies
between PWM providers and consumers, support for PWM controllers via
ACPI, sysfs will now suspend/resume PWMs that it has claimed) and
various existing drivers"
* tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits)
pwm: fsl-ftm: Make sure to unlock mutex on failure
pwm: fsl-ftm: Use write protection for prescaler & polarity
pwm: fsl-ftm: More relaxed permissions for updating period
pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWM
pwm: bcm2835: Improve precision of PWM
leds: pwm: Support ACPI via firmware-node framework
pwm: Add support referencing PWMs from ACPI
pwm: rcar: Remove suspend/resume support
pwm: sysfs: Add suspend/resume support
pwm: Add power management descriptions
pwm: meson: Add documentation to the driver
pwm: meson: Add support PWM_POLARITY_INVERSED when disabling
pwm: meson: Don't cache struct pwm_state internally
pwm: meson: Read the full hardware state in meson_pwm_get_state()
pwm: meson: Simplify the calculation of the pre-divider and count
pwm: meson: Move pwm_set_chip_data() to meson_pwm_request()
pwm: meson: Add the per-channel register offsets and bits in a struct
pwm: meson: Add the meson_pwm_channel data to struct meson_pwm
pwm: meson: Pass struct pwm_device to meson_pwm_calc()
pwm: meson: Don't duplicate the polarity internally
...
Upon failure to enable clocks while trying to enable the PWM, make sure
to unlock the mutex that was taken to avoid a deadlock during subsequent
operations.
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Modifying the prescaler or polarity value must be done with the
write protection disabled. Currently this is working by chance as
the write protection is in a disabled state by default.
This patch makes sure that we enable/disable the write protection
when needed.
Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
