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>
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_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>
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>
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>