i.MX PWM module's ipg_clk_s is for PWM register access, on most of i.MX
SoCs, this ipg_clk_s is from system ipg clock or perclk which is always
enabled, but on i.MX7D, the ipg_clk_s is from PWM1_CLK_ROOT which is
controlled by CCGR132, that means the CCGR132 MUST be enabled first
before accessing PWM registers on i.MX7D. This patch adds ipg clock
operation to make sure register access successfully on i.MX7D and it
fixes Linux kernel boot up hang during PWM driver probe.
Fixes: 4a23e6ee9f ("ARM: dts: imx7d-sdb: Restore pwm backlight support")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit e39c0df1be ("pwm: Introduce the pwm_args concept") has
changed the variable for the period for clps711x-pwm driver, so now
pwm_get/set_period() works with pwm->state.period variable instead
of pwm->args.period.
This patch changes the period variable in other places where it is used.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The Cygnus architecture uses a Kona PWM. This is already present in the
device tree but can't be built actually. Hence, allow the Kona PWM to
be built for the Cygnus architecture.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the get_state() function and set the initial state to reflect
real state of the hardware. This allows to keep the PWM running if it was
enabled in bootloader. It is very similar to the GPIO behavior. GPIO pin
set as output in bootloader keep the same setting in Linux unless it is
reconfigured.
If we find the PWM block enabled we need to prepare and enable its source
clock otherwise the clock will be disabled late in the boot as unused.
That will leave the PWM in enabled state but with disabled clock. That has
a side effect that the PWM output is left at its current level at which
the clock was disabled. It is totally non-deterministic and it may be LOW
or HIGH.
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use existing macros to define register fields instead of manually shifting
the bit masks. Also define some more register bits.
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Regarding the .request case: The consumer might be interested in taking
over the configured state from the boot loader. So the initially
configured state should be retained.
For the free case the PWM consumer is responsible for disabling the PWM
before calling pwm_put() and there are three subcases to consider:
a) The PWM is already off. Then there is no gain in disabling the PWM
once more.
b) The PWM is still running and there is a good reason for that. (Not
sure this is a valid case, I cannot imagine such a good reason.)
Then it is counterproductive to disable the PWM.
c) The PWM is still running because the consumer failed to disable the
PWM. Then the consumer needs fixing and there is little incentive to
paper over the problem in the backend driver.
This aligns the lpc18xx-sct driver to the other PWM drivers that also
don't reconfigure the hardware in .request and .free.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
According to the datasheet the update bit must be set if the on-time-div
or the base-unit changes.
Now that we properly order device resume on Cherry Trail so that the GFX0
_PS0 method no longer exits with an error, we end up with a sequence of
events where we are writing the same values twice in a row.
First the _PS0 method restores the duty cycle of 0% the GPU driver set
on suspend and then the GPU driver first updates just the enabled bit in
the pwm_state from 0 to 1, causing us to write the same values again,
before restoring the pre-suspend duty-cycle in a separate pwm_apply call.
When writing the update bit the second time, without changing any of
the values the update bit clears immediately / instantly, instead of
staying 1 for a while as usual. After this the next setting of the update
bit seems to be ignored, causing the restoring of the pre-suspend
duty-cycle to not get applied. This makes the backlight come up with
a 0% dutycycle after suspend/resume.
Any further brightness changes after this do work.
This commit moves the setting of the update bit into pwm_lpss_prepare()
and only sets the bit if we have actually changed any of the values.
This avoids the setting of the update bit the second time we configure
the PWM to 0% dutycycle, this fixes the backlight coming up with 0%
duty-cycle after a suspend/resume.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
On Cherry Trail devices under Windows the PWM controller used for the
backlight is considered part of the GPU even though it is part of the LPSS
block and thus is an entirely different independent hardware unit.
Because of this on Cherry Trail the GPU's (GFX0 ACPI node) _PS3 and _PS0
methods save and restore the PWM controller registers.
If userspace blanks the screen before suspending, such as e.g. GNOME
does, then the PWM controller will be runtime-suspended when the suspend
starts. This causes the GFX0 _PS? methods to save a value of 0xffffffff
for the PWM control register and to restore this value on resume.
0xffffffff is not a valid value for the register and writing this causes
problems such as e.g. a flickering backlight.
This commit adds a prepare method to the dev_pm_ops and makes it return 0
on Cherry Trail devices forcing a runtime-resume before other device's
suspend methods run. This fixes the reading and writing back of 0xffffffff.
Since we now always runtime-resume the device on suspend, it will be
resumed on resume too and we no longer need to check for the GFX0 _PS0
method having resumed it underneath us, so this commit removes the now no
longer necessary complete dev_pm_op.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
K3 devices have the same ECAP IP as OMAP SoCs. Enable driver to be built
for K3 devices. Also, drop reference to AM33xx in help text, as IP is
found on multiple TI SoCs.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch sends a uevent (KOBJ_CHANGE) on the pwmchipN device,
everytime a pwmX channel has been exported/unexported via sysfs. This
allows udev to implement rules on such events, like:
SUBSYSTEM=="pwm*", PROGRAM="/bin/sh -c '\
chown -R root:gpio /sys/class/pwm && chmod -R 770 /sys/class/pwm;\
chown -R root:gpio
/sys/devices/platform/soc/*.pwm/pwm/pwmchip* && chmod -R 770
/sys/devices/platform/soc/*.pwm/pwm/pwmchip*\
'"
This is a replacement patch for commit 7e5d1fd75c ("pwm: Set class for
exported channels in sysfs"), see [1].
basic testing:
$ udevadm monitor --environment &
$ echo 0 > /sys/class/pwm/pwmchip0/export
KERNEL[197.321736] change /devices/.../pwm/pwmchip0 (pwm)
ACTION=change
DEVPATH=/devices/.../pwm/pwmchip0
EXPORT=pwm0
SEQNUM=2045
SUBSYSTEM=pwm
[1] https://lkml.org/lkml/2018/9/25/713
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Tested-by: Gottfried Haider <gottfried.haider@gmail.com>
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This reverts commit 7e5d1fd75c ("pwm: Set
class for exported channels in sysfs") as it causes regression with
multiple pwm chip[1], when exporting a pwm channel (echo X > export):
- ABI (Documentation/ABI/testing/sysfs-class-pwm) states pwmX should be
created in /sys/class/pwm/pwmchipN/pwmX
- Reverted patch causes new entry to be also created directly in
/sys/class/pwm/pwmX
- 1st time, exporting pwmX will create an entry in /sys/class/pwm/pwmX
- class attributes are added under pwmX folder, such as export, unexport
npwm, symlinks. This is wrong as it belongs to pwmchipN. It may cause
bad behavior and report wrong values.
- when another export happens on another pwmchip, it can't be created
(e.g. -EEXIST). This is causing the issue with multiple pwmchip.
Example on stm32 (stm32429i-eval) platform:
$ ls /sys/class/pwm
pwmchip0 pwmchip4
$ cd /sys/class/pwm/pwmchip0/
$ echo 0 > export
$ ls /sys/class/pwm
pwm0 pwmchip0 pwmchip4
$ cd /sys/class/pwm/pwmchip4/
$ echo 0 > export
sysfs: cannot create duplicate filename '/class/pwm/pwm0'
...Exception stack follows...
This is also seen on other platform [2]
[1] https://lkml.org/lkml/2018/9/25/713
[2] https://lkml.org/lkml/2018/9/25/447
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Tested-by: Gottfried Haider <gottfried.haider@gmail.com>
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add a get_state callback so that the initial state correctly reflects
the actual hardware state.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
For each pwm output which gets enabled through pwm_lpss_apply(), we do a
pm_runtime_get_sync().
This commit adds pm_runtime_put() calls to pwm_lpss_remove() to balance
these when the driver gets removed with some of the outputs still enabled.
Fixes: f080be27d7 ("pwm: lpss: Add support for runtime PM")
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The _PS0 method for the integrated graphics on some Cherry Trail devices
(observed on a HP Pavilion X2 10-p0XX) turns on the PWM chip (puts it in
D0), causing an inconsistency between the state the pm-core thinks it is
in (left runtime suspended as it was before the suspend/resume) and the
state it actually is in.
Interestingly enough this is done on a device where the pwm controller is
not used for the backlight at all, since it uses an eDP panel. On devices
where the PWM is used this is not a problem since we will resume it
ourselves anyways.
This inconsistency causes us to never suspend the pwm controller again,
which causes the device to not be able to reach S0ix states when suspended.
This commit adds a resume-complete handler, which when we think the device
is still run-time suspended checks the actual power-state and if necessary
updates the rpm-core's internal state.
This fixes the Pavilion X2 10-p0XX not reaching S0ix states when suspended.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Move struct pwm_lpss_chip definition from pwm-lpss.c to pwm-lpss.h,
so that the pci/platform drivers can access the info member
(struct pwm_lpss_boardinfo *).
This is a preparation patch for adding platform specific quirks, which
the drivers need access to, to pwm_lpss_boardinfo.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The second PWM controller on Cherry Trail devices uses a separate ACPI
HID: "80862289", add this so that the driver will properly bind to the
second PWM controller.
The second PWM controller is usually not used, the main thing gained by
this is properly putting the PWM controller in D3 on suspend.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It's common to follow a device tree ID table by the MODULE_DEVICE_TABLE
immediately, without an extra blank line between.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for MT7628. The SoC is legacy MIPS and hence has no complex
clock tree. This patch add an extra flag to the SoC specific data
indicating, that no clocks are present.
Signed-off-by: John Crispin <john@phrozen.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Current clock name looks like this:
/soc/bus@ffd00000/pwm@1b000#mux0
This is bad because CCF uses the clock to create a directory in clk debugfs.
With such name, the directory creation (silently) fails and the debugfs
entry end up being created at the debugfs root.
With this change, the clock name will now be:
ffd1b000.pwm#mux0
This matches the clock naming scheme used in the ethernet and mmc driver.
It also fixes the problem with debugfs.
Fixes: 36af66a790 ("pwm: Convert to using %pOF instead of full_name")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
LPTimer has only one pwm channel (npwm = 1). Remove useless for loop
in remove routine.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If a pwm-omap-dmtimer is probed before the dmtimer it uses, the platform
data won't be set yet.
Fixes: ac30751df9 ("ARM: OMAP: pdata-quirks: Remove unused timer pdata")
Cc: <stable@vger.kernel.org> # 4.17+
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Ladislav Michl <ladis@linux-mips.org>
Tested-by: Andreas Kemnade <andreas@kemnade.info>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Enabled the support for the new SoC i.MX8QM by adding the compatible
string of "fsl,imx8qm-ftm-pwm" and its per-compatible data with setting
"has_enable_bits" to "true".
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
On the i.MX8x SoC family, an additional PWM enable bit is added for each
PWM channel in the register FTM_SC[23:16]. It supports 8 channels. Bit
16 is for channel 0, and bit 23 is for channel 7. As the IP version
information can not be obtained via any of the FTM registers, a property
of "has_enable_bits" is added via per-compatible data structure.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current driver assumes that the ftm_sys clock works as one of the
clock sources for the IP block as well as the IP interface clock. This
assumption does not apply any more on the latest i.MX8x SoC family. On
i.MX8x SoCs, a dedicated IP interface clock is introduced and it must be
enabled before accessing any FTM registers. Moreover, the clock can not
be used as the source clock for the FTM IP block. This patch introduces
the ipg_clk as the dedicated IP interface clock and by default it is the
same as the ftm_sys clock if not specified.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwm-tiehrpwm driver disables PWM output by putting it in low output
state via active AQCSFRC register in ehrpwm_pwm_disable(). But, the
AQCSFRC shadow register is not updated. Therefore, when shadow AQCSFRC
register is re-enabled in ehrpwm_pwm_enable() (say to enable second PWM
output), previous settings are lost as shadow register value is loaded
into active register. This results in things like PWMA getting enabled
automatically, when PWMB is enabled and vice versa. Fix this by
updating AQCSFRC shadow register as well during ehrpwm_pwm_disable().
Fixes: 19891b20e7 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As per AM335x TRM SPRUH73P "15.2.2.11 ePWM Behavior During Emulation",
TBCTL[15:14] only have effect during emulation suspend events (IOW,
to stop PWM when debugging using a debugger). These bits have no effect
on PWM output during normal running of system. Hence, remove code
accessing these bits as they have no role in enabling/disabling PWMs.
Fixes: 19891b20e7 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The Berlin PWM driver is currently broken on at least BG2CD. The
symptoms manifest as a very non-linear and erratic mapping from the duty
cycle configured in software to the duty cycle produced by hardware.
The cause of the bug is software's configuration of the prescaler, and
in particular its usage of the six prescaler values between the minimum
value of 1 and the maximum value of 4096. As it turns out, these six
values do not actually slow down the PWM clock; rather, they emulate
slowing down the clock by internally multiplying the value of TCNT.
This would be a fine trick, if not for the fact that the internal,
scaled TCNT value has no extra bits beyond the 16 already exposed to
software in the register. What this means is that, for a prescaler of 4,
the software must ensure that the top two bits of TCNT are not set,
because hardware will chop them off; for a prescaler of 8, the top three
bits must not be set, and so forth. Software does not currently ensure
this, resulting in a TCNT several orders of magnitude lower than
intended any time one of those six prescalers are selected.
Because hardware chops off the high bits in its internal shift, the
middle six prescalers don't actually allow *anything* that the first
doesn't. In fact, they are strictly worse than the first, since the
internal shift of TCNT prevents software from setting the low bits,
decreasing the resolution, without providing any extra high bits.
By skipping the useless prescalers entirely, this patch both fixes the
driver's behavior and increases its performance (since, when the 4096
prescaler is selected, it now does only a single shift rather than the
seven successive divisions it did before).
Tested on BG2CD.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
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>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAlr8BJYACgkQUa+KL4f8
d2FBPg//Wz+BKkZTTBqFK5AIXg3TaTDh3WPsvMMVuYALd4IWdW/uUBlUjGcOVg3E
kq4QNBJaGCrb9Sk+V5a9Rfu9uoA3KEj83O4zKaLn5++gjvNOR5JO96Ml70J1k3Wv
c+B4tTVpk/MWmSqsQFgzCm1V8KYBXuPag3OcTNB8qb3cbXIy3mieAtp7UUvtH4YG
+ewDvxkWKCS07259ojuEz6xIGZm6kGHIfCSlM0H+ub5nT5noBn3i0jdB3lmL116A
PX0lkwxldP8ZxOp0yI6TMoKfNMKdNu2aOlR+0gE6ni/YH/v2nG/llmXxVIXtGMuB
6xeA1PiT3jnd2OhmQJEW5lex8MVPL8wKcr/KecxHPWrD/i+7IcKTelbtRgMalD9H
rL8OLVEUqEv8aEtWV9joC4peFOikMUHueWfJis6J9p5svID3/xpyT1iRhMUiTJNl
eJL0VrVMWGgevVceTened5rk13QY9olfTeiN/0cM1f0A7jrKJozAIhjtc/o6X6SZ
SHvd2x8pGVCQVHwx5eUkcRamCtr9HzbN1qRzZx8G11zxhiBQjjkfV6bVDGcSJO/s
R38laF4PaYphQs2EwBbKwP0p8b4VflrpwYRgY9bIXatL4pOKlkWdJCq9lJHJHe4E
mm0RtP08Fi0pXfV0KCRseAn4naU4L3h+x0HhWluUU+k1jCNRFh0=
=e4zs
-----END PGP SIGNATURE-----
Merge tag 'ib-mfd-pwm-v4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into for-next
Immutable branch between MFD and PWM due for the v4.18 merge window (v2)
When compile-testing the PWM driver without also enabling the
stm32_timers MFD, we run into a link error:
drivers/pwm/pwm-stm32.o: In function `stm32_pwm_raw_capture.isra.6':
pwm-stm32.c:(.text+0xcb0): undefined reference to `stm32_timers_dma_burst_read'
We don't need the '|| COMPILE_TEST' here, since stm32_timers itself
can be built with CONFIG_COMPILE_TEST on all architectures, so we do
get the coverage through allmodconfig and randconfig builds even
when we make it a hard dependency.
Fixes: 7edf736920 ("pwm: Add driver for STM32 plaftorm")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
On some devices the contents of the ctrl register get lost over a
suspend/resume and the PWM comes back up disabled after the resume.
This is seen on some Bay Trail devices with the PWM in ACPI enumerated
mode, so it shows up as a platform device instead of a PCI device.
If we still think it is enabled and then try to change the duty-cycle
after this, we end up with a "PWM_SW_UPDATE was not cleared" error and
the PWM is stuck in that state from then on.
This commit adds suspend and resume pm callbacks to the pwm-lpss-platform
code, which save/restore the ctrl register over a suspend/resume, fixing
this.
Note that:
1) There is no need to do this over a runtime suspend, since we
only runtime suspend when disabled and then we properly set the enable
bit and reprogram the timings when we re-enable the PWM.
2) This may be happening on more systems then we realize, but has been
covered up sofar by a bug in the acpi-lpss.c code which was save/restoring
the regular device registers instead of the lpss private registers due to
lpss_device_desc.prv_offset not being set. This is fixed by a later patch
in this series.
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>
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>
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Using the pwm-meson driver on the 32-bit SoCs causes memory corruption.
The result are some hard-to-explain errors, for example
devm_clk_register() crashes with a NULL dereference somewhere deep in
the common clock framework code. In some cases the kernel even refused
to boot when any of the PWM controllers were enabled on Meson8b.
The root cause is an incorrect memory size in the devm_kcalloc() call in
meson_pwm_probe(). The code allocates an array of meson_pwm_channel
structs, but the size given is the size of the meson_pwm struct (which
seems like a small copy-and-paste error, as meson_pwm is allocated a few
lines above).
Even with this typo the code seemed to work fine on the 64-bit GX SoCs
(maybe due to the structs having the same size in the compiled result,
but I haven't checked this further).
Fixes: 211ed63075 ("pwm: Add support for Meson PWM Controller")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes adds support for more generations of the RCar
controller as well as runtime PM support. The JZ4740 driver gains
support for device tree and can now be used on all Ingenic SoCs.
Rounding things off is a random assortment of fixes and cleanups
all across the board.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlrPJeAZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoUQvEACaAkXPs3rvvHVF7pDo7SMV
3WMJu1oOiZ7Gy0VAooRyhwI/rNBeF4PYuHuxa2+NeuWX8MBN41dRWAp8Am4kMnOE
Lxp259qQTNGdGQTnSXP/sbYTKzAqF/3G0XtkhGejS3AzYSnhk6sIGcCevS4MD8bV
I/jSigPO4ByizyEJsnAkZPUw5js2CsE2xSnGKRsITZBK7yDi/cwB2cOLm0+psCKu
qYTlOHTc3myRKYESw5rmzB+cRyLGMkaq9SQzLZ8E2PP7zIY1QbrmzufQ1ovbpffl
065dS8+m1ecRMXUfFCLnHZPk/S5W6xZMskVJ0GIKC3xBPefbpCkkcA9A/gXkwH4y
FJ4lCROnB8gE3ITGkqzmZNBt3PKySIubEv1mCzdHVx3j4IEmF/M1Xc4wxz9qD+tD
ay+h1Vv1RbQlYlMqcOkxBpZd6sUnDIlIvIJ35IYUvD80Ap24DIU05NR1xsq6DMaD
c0N13an4gyK1t2O0YRcdmhHhIgwwaGhka5+8+r2hCqSVf/uzgyn26vzyqttrHuVc
CNYeMObuotr72LVHzXHkr4I/h+c7KE1B8RYKLZvUQuIdOvSb7Z9n32n1dBRILDH8
ppb+Y4azLDvAF4SAt5lZhYsMmB8vuCp4TA5LKwBEsylwTwOL9ghL7luYAOF4UroH
qigluQk3Sf5GF1jrp9hTew==
=JiRM
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.17-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 adds support for more generations of the RCar
controller as well as runtime PM support. The JZ4740 driver gains
support for device tree and can now be used on all Ingenic SoCs.
Rounding things off is a random assortment of fixes and cleanups all
across the board"
* tag 'pwm/for-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (29 commits)
pwm: rcar: Add suspend/resume support
pwm: rcar: Use PM Runtime to control module clock
dt-bindings: pwm: rcar: Add bindings for R-Car M3N support
pwm: rcar: Fix a condition to prevent mismatch value setting to duty
pwm: sysfs: Use put_device() instead of kfree()
dt-bindings: pwm: sunxi: Add new compatible strings
pwm: sun4i: Simplify controller mapping
pwm: sun4i: Drop unused .has_rdy member
pwm: sun4i: Properly check current state
pwm: Remove depends on AVR32
pwm: stm32: LPTimer: Use 3 cells ->of_xlate()
dt-bindings: pwm-stm32-lp: Add #pwm-cells
pwm: stm32: Protect common prescaler for all channels
pwm: stm32: Remove unused struct device
pwm: mediatek: Improve precision in rate calculation
pwm: mediatek: Remove redundant MODULE_ALIAS entries
pwm: mediatek: Fix up PWM4 and PWM5 malfunction on MT7623
pwm: jz4740: Enable for all Ingenic SoCs
pwm: jz4740: Add support for devicetree
pwm: jz4740: Implement ->set_polarity()
...
This release brings up a new platform based on the old ARM9 core: the
Nuvoton NPCM is used as a baseboard management controller, competing
with the better known ASpeed AST2xx series.
Another important change is the addition of ARMv7-A based chips
in mach-stm32. The older parts in this platform are ARMv7-M based
microcontrollers, now they are expanding to general-purpose workloads.
The other changes are the usual defconfig updates to enable additional
drivers, lesser bugfixes. The largest updates as often are the ongoing
OMAP cleanups, but we also have a number of changes for the older
PXA and davinci platforms this time.
For the Renesas shmobile/r-car platform, some new infrastructure
is needed to make the watchdog work correctly.
Supporting Multiprocessing on Allwinner A80 required a significant
amount of new code, but is not doing anything unexpected.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJaxibSAAoJEGCrR//JCVInPwcP/2ZdLMXXXaJBM+rCRPhT+vR1
FsKqcTCC5RHbVcKW+N54nmlsqofy2GadlmyfOdrFXtbf+Sm2dRNsDrHDOhvoPp37
fwBd0wGw0PLjNE8SEPp/ldtFe11Dbg0WGBzJ4PAPJgt1W4hvW8//VzVW1XsiRrVc
9SlZ66DwR95UQ5pwy+dfE8f9A/WW4XaMq0UHQ3/deQ/Te/64b/C6CJtT3W73WAlR
83UHgkwq3WvI+hhvg4QX9H0Q6dcK2JLUWsAB0xnZP8Q8t30NdDpl61uZL0A4Mh9Y
38lPhUjPUyUpsGrOttmMEQNzbAk4m/nzQxByYYmhkx3x+mlhjdA9KNavxDYVxXN2
1tzz62wst8pLePqVt2UsFqsaruJGMuTIooOdc5iCjG1c2N2kQGdBsuOvLjYu9kV6
XPTfvvAYkMo9rC0MbdPuobG+h/WrYHuc9SD2Mnt+kNaw1yJL08fWENjSuwP7kheb
2A5jdAFNrGqgcrWMsQOw8eYYC7z7WojkLq0kHrBbwIlVD7KIZurv2fm/iVo4+xPH
Gig5HuehMUtVYAf+Q1KWFlqS01fXMErt2pDGI5f1mNumXCB5kdWoSKbU8lOg03f8
ZqBHlfly+QDMOx0qfkxFX+phHPWHTOC+45yHK2Xq+n9urXmQbzYZxTzq5zCu6jcm
4yH0jaykoHODGNLIt50f
=HD9V
-----END PGP SIGNATURE-----
Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC platform updates from Arnd Bergmann:
"This release brings up a new platform based on the old ARM9 core: the
Nuvoton NPCM is used as a baseboard management controller, competing
with the better known ASpeed AST2xx series.
Another important change is the addition of ARMv7-A based chips in
mach-stm32. The older parts in this platform are ARMv7-M based
microcontrollers, now they are expanding to general-purpose workloads.
The other changes are the usual defconfig updates to enable additional
drivers, lesser bugfixes. The largest updates as often are the ongoing
OMAP cleanups, but we also have a number of changes for the older PXA
and davinci platforms this time.
For the Renesas shmobile/r-car platform, some new infrastructure is
needed to make the watchdog work correctly.
Supporting Multiprocessing on Allwinner A80 required a significant
amount of new code, but is not doing anything unexpected"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (179 commits)
arm: npcm: modify configuration for the NPCM7xx BMC.
MAINTAINERS: update entry for ARM/berlin
ARM: omap2: fix am43xx build without L2X0
ARM: davinci: da8xx: simplify CFGCHIP regmap_config
ARM: davinci: da8xx: fix oops in USB PHY driver due to stack allocated platform_data
ARM: multi_v7_defconfig: add NXP FlexCAN IP support
ARM: multi_v7_defconfig: enable thermal driver for i.MX devices
ARM: multi_v7_defconfig: add RN5T618 PMIC family support
ARM: multi_v7_defconfig: add NXP graphics drivers
ARM: multi_v7_defconfig: add GPMI NAND controller support
ARM: multi_v7_defconfig: add OCOTP driver for NXP SoCs
ARM: multi_v7_defconfig: configure I2C driver built-in
arm64: defconfig: add CONFIG_UNIPHIER_THERMAL and CONFIG_SNI_AVE
ARM: imx: fix imx6sll-only build
ARM: imx: select ARM_CPU_SUSPEND for CPU_IDLE as well
ARM: mxs_defconfig: Re-sync defconfig
ARM: imx_v4_v5_defconfig: Use the generic fsl-asoc-card driver
ARM: imx_v4_v5_defconfig: Re-sync defconfig
arm64: defconfig: enable stmmac ethernet to defconfig
ARM: EXYNOS: Simplify code in coupled CPU idle hot path
...
Runtime PM API (pm_runtime_get_sync/pm_runtime_put) should be used
to control module clock instead of clk_prepare_enable and
clk_disable_unprepare.
Signed-off-by: Hien Dang <hien.dang.eb@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Anson Huang