With the previous commit there is no need for the lowlevel driver any
more to specify it it uses two or three cells. So simplify accordingly.
The only non-trival change affects the pwm-rockchip driver: It used to only
support three cells if the hardware supports polarity. Now the default
number depends on the device tree which has to match hardware anyhow
(and if it doesn't the error is just a bit delayed as a PWM handle with
an inverted setting is catched when pwm_apply_state() is called).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
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>
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>
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>
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>
This contains a couple of fixes and cleanups for the Meson and ACPI/LPSS
drivers as well as capture support for STM32. Note that given the cross-
subsystem changes, the STM32 patches were merged through the MFD and PWM
trees, both sharing an immutable branch.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlseQMIZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoZ+8D/9XLQhQqW+pbI28JB0Jwe22
StuPNymo4wdED9Ga1ZPsVePKouQWW9D+NFjp80zqH26M4c+B235OvUljRDPnwTMH
edJBUmGO2LMil8xtKYdF98WusLT33Q/k5alDmS11gEd/1h5xOH5kORc9pHuTIwhN
dq5hy5OZWHHhlvlI4tCbqLuPrj/ucNourBJaLsMTwsGjdROtaakpyBbDX6ytMZ3c
VIV78GFeszWhLfi/mkQlxQ6SzfEX8D+xfNRgYZkmklsJ+K7ztvK5qcnZQgv3yoTL
s9xaZJY/Ei5IIyUFK6hraWTgIBkyZ9LpEPQHnGdkp8R1WpskcNWMgQup7FUm7U2u
gwHiijZvj6hLjjxFS+bje2xoBTUB5KhCcC9COMUAktigm5mtLzXdoeVUQivqZerm
plISAMo9UQMeO+wYZCMY5E9lWrsCGYSYWno5aHxAu6SaSvYUDIcD49LM6JMkt9Ek
5VLirs6b53pBNKZHH2+t67GMz/8GkzlZl19sQfRhv3uYJHHn+3VuOY4wQsqBLIk8
PoMzzWuzUgvcb+pZBisGHk92DCEXR1/9mgbNBNHXm+uuQ+YvXjvltY5osaIV1aI4
eBskscme1YGYEBJbhJpKEON6UFpUc4QD9HNXfAHQ/vyf7IShUdNk7zDnKBm9O42e
SfX8AtcmV4KoVHi/Sw9DbQ==
=ZED5
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This contains a couple of fixes and cleanups for the Meson and
ACPI/LPSS drivers as well as capture support for STM32.
Note that given the cross- subsystem changes, the STM32 patches were
merged through the MFD and PWM trees, both sharing an immutable
branch"
* tag 'pwm/for-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: stm32: Fix build warning with CONFIG_DMA_ENGINE disabled
pwm: stm32: Enforce dependency on CONFIG_MFD_STM32_TIMERS
ACPI / LPSS: Add missing prv_offset setting for byt/cht PWM devices
pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume
dt-bindings: mfd: stm32-timers: Add support for dmas
pwm: simplify getting .drvdata
pwm: meson: Fix allocation of PWM channel array
Without dmaengine support, we get a harmless warning about an unused
function:
drivers/pwm/pwm-stm32.c:166:12: error: 'stm32_pwm_capture' defined but not used [-Werror=unused-function]
Changing the #ifdef to an IS_ENABLED() check shuts up that warning and
is slightly nicer to read.
Fixes: 53e38fe73f ("pwm: stm32: Add capture support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n
in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and
'raw_dty' may be used uninitialized in this function
[-Wmaybe-uninitialized]
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Using input prescaler, capture unit will trigger DMA once every
configurable /2, /4 or /8 events (rising edge). This helps improve
period (only) capture accuracy at high rates.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Currently, capture is based on timeout window to configure prescaler.
PWM capture framework provides 1s window at the time of writing.
There's place for improvement, after input signal has been captured once:
- Finer tune counter clock prescaler, by using 1st capture result (with
arbitrary margin).
- Do a 2nd capture, with scaled capture window.
This increases accuracy, especially at high rates.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add support for PMW input mode on pwm-stm32. STM32 timers support
period and duty cycle capture as long as they have at least two PWM
channels. One capture channel is used for period (rising-edge), one
for duty-cycle (falling-edge).
When there's only one channel available, only period can be captured.
Duty-cycle is simply zero'ed in such a case.
Capture requires exclusive access (e.g. no pwm output running at the
same time, to protect common prescaler).
Timer DMA burst mode (from MFD core) is being used, to take two
snapshots of capture registers (upon each period rising edge).
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
There may be a race, when configuring two PWM channels, with different
prescaler values, when there's no active channel yet.
Add mutex lock to avoid concurrent access on PWM apply state.
This is also precursor patch for PWM capture support.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
dev is never assigned or used. Remove it.
Fixes: 7edf736920 ("pwm: Add driver for STM32 plaftorm")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add SPDX identifier to make it easier to determine the license of the
file.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This driver adds support for PWM driver on STM32 platform.
The SoC have multiple instances of the hardware IP and each
of them could have small differences: number of channels,
complementary output, auto reload register size...
version 9:
- fix commit message header
- remove one space MODULE_ALIAS
version 8:
- fix comments done by Thierry on version 7
version 6:
- change st,breakinput parameter to make it usuable for stm32f7 too.
version 4:
- detect at probe time hardware capabilities
- fix comments done on v2 and v3
- use PWM atomic ops
version 2:
- only keep one comptatible
- use DT parameters to discover hardware block configuration
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
