When ->probe() fails the driver core takes care of unsetting the driver
data.
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 only called when probe returned successfully.
In this case the driver data cannot be NULL.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This callback was introduced in commit 62099abf67 ("pwm: Add debugfs
interface") in 2012 and up to now there is not a single user. So drop
this unused code.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: remove kerneldoc for ->dbg_show()]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Given that struct pwm_state is sparse (at least on some platforms),
variables of this type might represent the same state because all fields
are pairwise identical but still memcmp() returns a difference because
some of the unused bits are different.
To prevent surprises compare member by member instead of the whole
occupied memory.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
This patch fixes an issue that is possible to set mismatch value to duty
for R-Car PWM if we input the following commands:
# cd /sys/class/pwm/<pwmchip>/
# echo 0 > export
# cd pwm0
# echo 30 > period
# echo 30 > duty_cycle
# echo 0 > duty_cycle
# cat duty_cycle
0
# echo 1 > enable
--> Then, the actual duty_cycle is 30, not 0.
So, this patch adds a condition into rcar_pwm_config() to fix this
issue.
Signed-off-by: Ryo Kodama <ryo.kodama.vz@renesas.com>
[shimoda: revise the commit log and add Fixes and Cc tags]
Fixes: ed6c1476bf ("pwm: Add support for R-Car PWM Timer")
Cc: Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Never directly free @dev after calling device_register(), even if it
returned an error! Always use put_device() to give up the reference
initialized.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
At the moment we assign our supported compatible strings to a respective
instance of our sun4i_pwm_data structure, even though some of them
are the same.
To avoid further clutter, split out the three different combinations of
features we have at the moment and name them accordingly.
This should make it more obvious which compatible string to use for new
SoCs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit a054c4d684 ("pwm: sun4i: Drop legacy callbacks") dropped the
only user of the .has_rdy member in our sun4i_pwm_data struct.
Consequently we don't need to store this anymore for the various SoCs,
which paves the way for further simplifications.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Correctly extract the prescaler value from CTRL_REG before comparing it
to PWM_PRESCAL_MASK.
Also, check that both PWM_CLK_GATING and PWM_EN to ensure the PWM is
enabled instead of relying on only one of those.
Fixes: 93e0dfb2c5 ("pwm: sun4i: Improve hardware read out")
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
AVR32 is gone, so no more need to depend on it.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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 a way that turning resolution from in nanosecond into in picosecond
to improve noticeably almost 4.5% precision.
It's necessary to hold the new resolution with type u64 and thus related
operations on u64 are applied instead in those rate calculations.
And the patch has a dependency on [1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2018-March/012225.html
Cc: stable@vger.kernel.org
Fixes: caf065f8fd ("pwm: Add MediaTek PWM support")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
MODULE_ALIAS exports information to allow the module to be auto-loaded at
boot for the drivers registered using legacy platform registration.
However, currently the driver is always used by DT-only platform,
MODULE_ALIAS is redundant and should be removed properly.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to
control PWM4 or PWM5 are distinct from the other PWMs, whose wrong
programming on PWM hardware causes waveform cannot be output as expected.
Thus, the patch adds the extra condition for fixing up the weird case to
let PWM4 or PWM5 able to work on MT7623.
v1 -> v2: use pwm45_fixup naming instead of pwm45_quirk
v2 -> v3: add more tags for Reviewed-by, Fixes, and Cc stable
Cc: stable@vger.kernel.org
Fixes: caf065f8fd ("pwm: Add MediaTek PWM support")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Zhi Mao <zhi.mao@mediatek.com>
Cc: John Crispin <john@phrozen.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This driver works perfectly with all the versions of the SoCs from
Ingenic that are supported upstream.
This makes the driver usable on JZ4740, JZ4770 and JZ4780 SoCs.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for probing the pwm-jz4740 directly from devicetree.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This permits clients of this driver to specify the polarity to use for
their PWM channel.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
On the JZ4750 and later SoCs, channel 1 and 2 operate in a different
way (TCU2 mode) as the other channels. If a TCU2 mode counter is
stopped before its PWM functionality is disabled, the output is not
guaranteed to return to the initial level.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
On a imx6q-cubox-i board, which has an LED driven by PWM, when the system
goes into suspend the PWM block is disabled by default, then the PWM pin
goes to logic level zero and turn on the LED during suspend, which is not
really the behaviour we want to see.
By keeping the PWM enabled during suspend via STOPEN bit, the pwm-leds
driver sets the brightness to zero in suspend and then the LED is
turned off as expected.
So always set the STOPEN to fix the PWM behaviour in suspend.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
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>
The blackfin architecture is getting removed, so this driver is now
obsolete as well.
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Aaron Wu <aaron.wu@analog.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A lot of Kconfig symbols have architecture specific dependencies.
In those cases that depend on architectures we have already removed,
they can be omitted.
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For PWM controller in the Meson-AXG SoC, the EE domain and AO domain
have different clock sources. This patch tries to describe them in the
DT compatible data.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Notifications for devices without bus or class set get dropped by
dev_uevent_filter(). Adding the class to the exported child matches
what the GPIO subsystem is doing.
With this change exporting a channel triggers a udev event, which
gives userspace a chance to fixup permissions and makes it possible
for non-root users to make use of the PWM subsystem.
Signed-off-by: Gottfried Haider <gottfried.haider@gmail.com>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: H Hartley Sweeten <hsweeten@visionengravers.com>
CC: linux-pwm@vger.kernel.org
CC: linux-arm-kernel@lists.infradead.org
CC: linux-rpi-kernel@lists.infradead.org
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The changes for this release include power management improvements for
the pwm-img driver, support for the backup mode on pwm-atmel-tcb as well
as support for more hardware with the R-Car and Mediatek drivers.
To round things off there's a bit of cleanup for sunxi and stm32-lp.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAloVVScZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoYitD/9e9MWl5VW4Bz6FHfh1uKNB
cwdgTHj4JE/7LA/p2hP7Zzs5xx1Blyf3TDjr2LFB/C6tWVRfve8TN6y4L3Md6Rv/
gdV2Sy9Hg02kMCiLyPihpFKx4aMoiiB3g0nygG5pC/etX6PB+mmH4XocnjpuHOGf
s1f2JULEm2C1nfYqzmhGBTiiwSOAPMfPdhvGvS2ydrW5HoCYJ+tK3hnWXBJjYUyk
R5zHr7blqT5f7FzA9Rx+5UY5vQlISwUfvdi/EHT7ighgF/dggaBWKuK+R0sCEhq1
AdyrgEEJsXeh9XcCdfKveEJKu8I6zROYeBfrxeZr2Kzl2mTx6a3U0vviI0hLZSPh
IrLyo3MnIVcTuZyII07jjM9KePnOYuDjjMc9qDP5QrNJHZI66Qf0f3wzg1QIIW5D
+3LXFnlWH59fHwvb80vpSVgI0S9T76W2tLqQfM/pKdOiwYs+A10cQvTwvUHMTerl
zHJ4DdEugLoZzJaZto29ilP7DygMjmDkFPh4z9f92d94JskXFfsEU3oSclggMXFy
2xzAm5bNwLibBgwThXUVmP/rR3AFQXDGvjPPK1DIhQxjJb6gjgQNLOvPfgN+kx65
kjc20jEpJxpnXk7y6kecLEEdxO/o/GdysfGfdk/BlOsBMV/BmVX0igpaal9fOqQp
34P+xRbpnmuKU4E8TpT43w==
=HLrm
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"The changes for this release include power management improvements for
the pwm-img driver, support for the backup mode on pwm-atmel-tcb as
well as support for more hardware with the R-Car and Mediatek drivers.
To round things off there's a bit of cleanup for sunxi and stm32-lp"
* tag 'pwm/for-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: stm32-lp: Remove pwm_is_enabled() check before calling pwm_disable()
pwm: mediatek: Add MT2712/MT7622 support
pwm: sunxi: Use of_device_get_match_data()
pwm: atmel-tcb: Support backup mode
dt-bindings: pwm: Add R-Car D3 device tree bindings
pwm: img: Add runtime PM
pwm: img: Add suspend / resume handling
The same checking is done by the implementation of pwm_disable().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for MT2712 and MT7622. Due to register offset address of
pwm7 for MT2712 is not fixed 0x40, add mtk_pwm_reg_offset array for PWM
register offset.
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The usage of of_device_get_match_data reduce the code size a bit.
Furthermore, it prevents an improbable dereference when
of_match_device() returns NULL.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Save and restore registers for the PWM on suspend and resume, which
makes hibernation and backup modes possible.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add runtime PM to disable the clocks when the h/w is not in use.
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The power may be disabled during suspend, so implement suspend and
resume callbacks to save and restore register state.
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
[thierry.reding@gmail.com: guard using PM_SLEEP instead of PM]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The changes for this release include a new driver for the PWM controller
found on SoCs of the ZTX ZX family. Support for an old SH-Mobile SoC has
been dropped and the Rockchip and MediaTek drivers gain support for more
generations.
Other than that there are a bunch of coding style fixes, minor bug fixes
and cleanup as well as documentation patches.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlm2fWoZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zofXuD/0WP6F9ZMx3FDpc02PJe7KA
H634eZXRxjRBMyJ+fWqBf+VZ9uKyA8Qh+lKzve57vzBah8cnp2fRS6MtNxCqhq9T
kiu9ocsbncF01HuAqBCVZM/TwbPIa8QtDGQ7HlmQ+brdWdXyntjilWmoW+DQuoDT
hsC/AL+Ih0t9LH8zrtv5wtB92+920M9NUe35up3hrc1qQgHCs+1VwRQ0PUlhlkwF
xQVop+t6rAtVVHx+mEw3tBQ913Ciy2sJY/BuGkXzTCj1P3i8HrPWE/laVXrn9Kbe
taTeewCr1IZSnyFY4/0+JPz2/a/kFIa36N0uQop0WGcrKV9cp1Hdjuhqa4joKgdk
rPrNJ3YQ4ji6U/vsy0FYuWPXfQI8sK7i56oJiRVAOIH0OaI6CTx1nDpRr/eXvqSd
fVf/zwUIVdzutREqYHVU8WwfYJO//U1zWymsJsfD1hZu/2hSZryjemhIjrmi66gh
RF+8Q9qrV1KGeLFIEAvRpnZ48yM/NKQxKqf9cBUfQmvELpu3b0ujx1eYmGefPqvu
1jIQbQ96sZI39geF+qt+FE994v7VZnYiMyhWhtpR8inkw9tfcYs+oGr70Jz+SgFf
0xV/M0aC7KWsOD7Avh3vqMH+j3tUf3zfK1/a0Jsr3PYLCDlw2WEnaWr5b3mv4YQA
Ta4B6NVjFz41LD9rZV+68A==
=GUps
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"The changes for this release include a new driver for the PWM
controller found on SoCs of the ZTX ZX family. Support for an old
SH-Mobile SoC has been dropped and the Rockchip and MediaTek drivers
gain support for more generations.
Other than that there are a bunch of coding style fixes, minor bug
fixes and cleanup as well as documentation patches"
* tag 'pwm/for-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (32 commits)
pwm: pwm-samsung: fix suspend/resume support
pwm: samsung: Remove redundant checks from pwm_samsung_config()
pwm: mediatek: Disable clock on PWM configuration failure
dt-bindings: pwm: Add MT2712/MT7622 information
pwm: mediatek: Fix clock control issue
pwm: mediatek: Fix PWM source clock selection
pwm: mediatek: Fix Kconfig description
pwm: tegra: Explicitly request exclusive reset control
pwm: hibvt: Explicitly request exclusive reset control
pwm: tiehrpwm: Set driver data before runtime PM enable
pwm: tiehrpwm: Miscellaneous coding style fixups
pwm: tiecap: Set driver data before runtime PM enable
pwm: tiecap: Miscellaneous coding style fixups
dt-bindings: pwm: tiecap: Add TI 66AK2G SoC specific compatible
pwm: tiehrpwm: fix clock imbalance in probe error path
pwm: tiehrpwm: Fix runtime PM imbalance at unbind
pwm: Kconfig: Enable pwm-tiecap to be built for Keystone
pwm: Add ZTE ZX PWM device driver
dt-bindings: pwm: Add bindings doc for ZTE ZX PWM controller
pwm: bcm2835: Support for polarity setting via DT
...
Add support for single PWM channel on Low-Power Timer, that can be
found on some STM32 platforms.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Fix suspend/resume support:
- add disabled_mask to struct samsung_pwm_chip to track PWM
disabled state information in pwm_samsung_{disable,enable}()
- rename pwm_samsung_config() to __pwm_samsung_config() and
add extra force_period parameter to be used during resume
(to force tin_ns and tcnt recalculation)
- add pwm_samsung_config() wrapper for preserving old behavior
- properly restore PWM configuration in pwm_samsung_resume()
- remove no longer needed pwm_samsung_suspend()
- update Copyrights
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If the requested period_ns and duty_ns values are identical to the last
programmed ones pwm_samsung_config() returns early and skips the
hardware configuration. The same checks are now done by the PWM core so
the driver specific ones can be removed.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Make sure to disable the PWM clock if the PWM cannot be configured due
to the clock divider exceeding the maximum value.
While at it, replace the hardcoded maximum clock divider with a defined
constant to improve code readability.
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In order to save some power, do not prepare the top and main clocks
during mtk_pwm_probe(). Instead, prepare the clocks only when necessary
and also make sure to enable the clocks to match the semantics of the
common clock framework.
While at it, don't explicitly disable all PWM channels in ->remove()
because all users should have done that already.
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In original code, the PWM output frequency is not correct when set
bit<3>=1 to PWMCON register.
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Fix a copy/paste error that sneaked into the Kconfig description of the
Mediatek PWM driver.
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-pwm@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Runtime PM callbacks can be run right after runtime PM is enabled, so
make sure to set the driver data before that. This is unlikely to ever
happen with the current driver, but it doesn't hurt to follow best
practices anyway.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
I noticed most of these while reviewing another patch and thought I'd
fix them while at it. These are mostly changes to make variable types
more strict and whitespace fixups.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Runtime PM callbacks can be run right after runtime PM is enabled, so
make sure to set the driver data before that. This is unlikely to ever
happen with the current driver, but it doesn't hurt to follow best
practices anyway.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
I noticed most of these while reviewing another patch and thought I'd
fix them while at it. These are mostly changes to make variable types
more strict and whitespace fixups.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Make sure to unprepare the clock before returning on late probe errors.
Fixes: b388f15fd1 ("pwm: pwm-tiehrpwm: Use clk_enable/disable instead clk_prepare/unprepare.")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Remove unbalanced RPM put at driver unbind which resulted in a negative
usage count.
Fixes: 19891b20e7 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
66AK2G SoC has ECAP subsystem that is used as pwm-backlight provider for
display. Hence, enable pwm-tiecap driver to be built for Keystone
architecture.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It adds PWM device driver for ZTE ZX family SoCs. The PWM controller
supports 4 devices with polarity configuration.
The driver has been tested with pwm-regulator support to scale core
voltage via cpufreq.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This adds support for the third (optional) pwm cell to specify the
polarity, which is needed by display backlights for example.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The rk3328 SoC supports atomic update, we could lock the configuration
of period and duty at first, after unlock is configured, the period and
duty are effective at the same time.
If the polarity, period and duty need to be configured together,
the way for atomic update is "configure lock and old polarity" ->
"configure period and duty" -> "configure unlock and new polarity".
Signed-off-by: David Wu <david.wu@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Just use the same PWM ops for each IP, and get rid of the ops in struct
rockchip_pwm_data, but still define the three different instances of the
struct to use common interface for each IP.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It is usually possible to configure the polarity, cycle and duty all at
once, so that the polarity and cycle and duty are applied atomically.
Move it from rockchip_pwm_set_enable() into rockchip_pwm_config(), as
well as prepare for the next atomic update commit.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Drop the custom hook of pwm_enable() and implement pwm_apply_v1() and
pwm_apply_v2() instead.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It seems the rockchip_pwm_config() always returns the result 0, so
remove the judge.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
New PWM module provides two individual clocks for APB clock and function
clock.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Remove support for the SH7372 (SH-Mobile AP4) from the renesas-tpu
driver.
Commit edf4100906 ("ARM: shmobile: sh7372 dtsi: Remove Legacy
file") removed this SoC from the kernel in v4.1.
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Undo preparation of a clock source if vt8500_pwm_probe() is not
successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The function
static void pca9685_set_sleep_mode(struct pca9685 *pca, int sleep)
takes the chip in and out of sleep mode, depending on the value of
sleep, which is interpreted as a boolean.
To clarify that 'int sleep' is a boolean and not a sleep delay,
change the function interface to:
static void pca9685_set_sleep_mode(struct pca9685 *pca, bool enable)
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: linux-pwm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This release cycle's changes include mostly updates and cleanups to
existing drivers along with a few cleanups to the core, documentation
and device tree bindings.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAllnboQZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zocCFD/9kUnHzwyM3epnGQruCwgLI
xwcZmk2vAImbLoMN0NwtLpKyxIxehDCjvgsRxAm5ggE7Whs2Wzs1tzdML863umdl
DcfF46T+zHlUXNZMgES+Znp787G6Bqnjj35PNVqNneptukmrZakPMQ4nZkL0UidD
dZnXs/KhK97G4ys00+uVSfS/x6Ck1oD9XUtJttSGx4f7wIhWcsiwUpJvi772jcG+
bVmVkbJsOnui4UdvUs1uCb5yOppzOJqwsuNCAyX9a3NKR6u3/RtETjo4DQHhqXrv
mXoHEIZkljDOgni2Zu/kcUDjooQ/GJVLjwku2iq1UGmJTu6FOJKqSLBKGQzyCXs+
BN0JM7pwEwwGKFzKbNn/ZxpJD06Hk0ABWcjeObIgsZaUOGmUdiDzwpFmLtKK22TC
9zNEODo+OjuaNYKADa4RHZrDbujiPMCL9ezonO3Xb1AS9UQfR8wXsVFqR44EofQA
0x+q+yIS5GVMab6s/jN51G/RVW2Ao+SdT+0/F8QF8N3YlCFsFCwt+X96383oDPAj
STiHxqIRzEkn44Ua9CFg9utTrQeUVtNB3tw0wnD+zgsMFH1YRzcU2p714viqN8tQ
N0yJUi+VwHXxnfNiVZNdrgidRH7ETWXyJY/OFRt2BCq9VuZ8V3E/Dr41pgFxZ0e6
WP7awOH/n25e4L09CjRtng==
=ioFX
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This release cycle's changes include mostly updates and cleanups to
existing drivers along with a few cleanups to the core, documentation
and device tree bindings"
* tag 'pwm/for-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: cros-ec: Fix transposed param settings
pwm: meson: Improve PWM calculation precision
dt-bindings: pwm: meson: Add compatible for gxbb ao PWMs
pwm: meson: Add compatible for the gxbb ao PWMs
pwm: sun4i: Drop legacy callbacks
pwm: sun4i: Switch to atomic PWM
pwm: sun4i: Improve hardware read out
pwm: hibvt: Constify hibvt_pwm_ops
pwm: Silently error out on EPROBE_DEFER
pwm: Standardize document format
pwm: bfin: Remove unneeded error message
dt-bindings: pwm: Update STM32 timers clock names
dt-bindings: pwm: Add R-Car M3-W device tree bindings
pwm: tegra: Set maximum pwm clock source per SoC tapeout
The __cros_ec_pwm_get_duty() routine was transposing the insize and
outsize fields when calling cros_ec_cmd_xfer_status().
The original code worked without error due to size of the two particular
parameter blocks passed to cros_ec_cmd_xfer_status(), so this change is
not fixing an actual runtime problem, just correcting the calling usage.
Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When using input clocks with high rates, such as clk81 (166MHz), the
fin_ns = NSEC_PER_SEC / fin_freq can introduce a significant error.
Ex: fin_freq = 166666667, NSEC_PER_SEC = 1000000000
fin_ns = 5,9999999
which is, of course, rounded down to 5. This introduces an error of ~20%
on the period requested from the PWM.
This patch uses ps instead of ns (and 64 bit integers) to perform the
calculation. This should give a good enough precision.
Fixes: 211ed63075 ("pwm: Add support for Meson PWM Controller")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
squash! pwm: meson: Improve pwm calculation precision
On the gxbb (and gxl) family, the PWMs of the AO domain require a
specific compatible because the possible input clocks are different
from the EE PWMs input clocks.
Since the number of possible input clocks is also different, the
'num_parents' field is added to all the Meson PWM data.
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Switch the driver to atomic PWM. This makes it easier to wait a proper
amount of time when changing the duty cycle before disabling the channel
(main use case is switching the duty cycle to 0 before disabling).
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement .get_state instead of only reading the polarity at probe time.
This allows to get the proper state, period and duty cycle.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In of_pwm_get(), if we fail to get the PWM chip due to probe deferal, we
shouldn't print an error message. Just be silent in this case.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM hardware IP is taped-out with different maximum frequency
on different SoCs.
From HW team:
Before Tegra186, it is 48 MHz.
In Tegra186, it is 102 MHz.
Add support to limit the clock source frequency to the maximum IP
supported frequency. Provide these values via SoC chipdata.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on
the pins being properly configured before the driver probes.
One inherent problem of this new approach is that the pinctrl framework
does not allow us to configure each pin on demand, when the various PWM
channels are requested or released. For instance, the PWM channels can
be configured from sysfs, which would require all PWM pins to be configured
properly beforehand for the PWM function, eventually causing conflicts
with other platform or board drivers.
The proper solution here would be to modify the pwm-jz4740 driver to
handle only one PWM channel, and create an instance of this driver
for each one of the 8 PWM channels. Then, it could use the pinctrl
framework to dynamically configure the PWM pin it controls.
Until this can be done, the only jz4740 board supported upstream
(Qi lb60) can configure all of its connected PWM pins in PWM function
mode, since those are not used by other drivers nor by GPIOs on the
board.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It is required to know the PWM clock source frequency to calculate the
PWM period.
In driver, the clock source frequency of the PWM does not get change
and, hence, get the clock source frequency in driver init. Get this
values later for period calculation from pwm_config().
This will help in avoiding the clock call for getting clock rate in the
pwm_config() each time.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
GPIO-only driver operation never clears the SLEEP bit, which can cause
the GPIOs to become unusable.
Example:
1. user requests first PWM -> driver clears SLEEP bit
2. user frees last PWM -> driver sets SLEEP bit
3. user requests GPIO
4. user switches GPIO on -> output does not turn on
because SLEEP bit is set
Prevent this behaviour by letting the runtime PM framework control the
SLEEP bit. This will put the chip to SLEEP if no PWMs/GPIOs are exported
or in use.
Fixes: bccec89f0a ("Allow any of the 16 PWMs to be used as a GPIO")
Reported-by: Sven Van Asbroeck <TheSven73@googlemail.com>
Signed-off-by: Sven Van Asbroeck <TheSven73@googlemail.com>
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
drivers/pwm/pwm-mediatek.c:210:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: John Crispin <john@phrozen.org>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
For very short periods, the result of the division might overflow the
unsigned long hz variable (on 32-bit architectures). Avoid that by
making it an unsigned long long. While at it, also remove an unneeded
local variable whose only purpose is to store a temporary computation.
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In some of NVIDIA Tegra's platform, PWM controller is used to
control the PWM controlled regulators. PWM signal is connected to
the VID pin of the regulator where duty cycle of PWM signal decide
the voltage level of the regulator output.
When system enters suspend, some PWM client/slave regulator devices
require the PWM output to be tristated.
Add support to configure the pin state via pinctrl frameworks in
suspend and active state of the system.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The rate of the PWM calculated as follows:
hz = NSEC_PER_SEC / period_ns;
rate = (rate + (hz / 2)) / hz;
This has the precision loss in lower PWM rate.
Change this to have more precision as:
hz = DIV_ROUND_CLOSEST_ULL(NSEC_PER_SEC * 100, period_ns);
rate = DIV_ROUND_CLOSEST(rate * 100, hz)
Example:
1. period_ns = 16672000, PWM clock rate is 200 KHz.
Based on old formula
hz = NSEC_PER_SEC / period_ns
= 1000000000ul/16672000
= 59 (59.98)
rate = (200K + 59/2)/59 = 3390
Based on new method:
hz = 5998
rate = DIV_ROUND_CLOSE(200000*100, 5998) = 3334
If we measure the PWM signal rate, we will get more accurate
period with rate value of 3334 instead of 3390.
2. period_ns = 16803898, PWM clock rate is 200 KHz.
Based on old formula:
hz = 59, rate = 3390
Based on new formula:
hz = 5951, rate = 3360
The PWM signal rate of 3360 is more near to requested period
than 3333.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use macro DIV_ROUND_CLOSEST_ULL() for 64-bit division to closest one
instead of implementing the same locally. This increase readability.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds support for the PWM core found on current ARM base SoCs
made by MediaTek. This IP core supports 5 channels and has 2 operational
modes. There is the old mode, which is a classical PWM and the new mode
which allows the user to define bitmasks that get clocked out on the
pins. As the subsystem currently only supports PWM cores with the "old"
mode, we can safely ignore the "new" mode for now.
Signed-off-by: John Crispin <john@phrozen.org>
[thierry.reding@gmail.com: minor cleanups]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
sama5d2 can use the same atmel_pwm_data as sama5d3.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The currently Atmel PWM controllers supported by this driver could
change period or duty factor without channel disable, for regular
channels (sama5d3 support this by using period or duty factor update
registers, sam9rl support this by writing channel update register and
select the corresponding update: period or duty factor). The chip
doesn't support run time changings of signal polarity. To take advantage
of atomic PWM framework and let controller works without glitches, in
this patch only the duty factor could be changed without disabling PWM
channel. For period and signal polarity the atomic PWM is simulated by
disabling + enabling the right PWM channel.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the suspend/resume hooks to make sure the PWM device is
restored to a correct state after a suspend.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->apply() hook and drop the ->enable(), ->disable,
->set_polarity and ->config() ones.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If the PWM was not enabled at U-Boot loader, PWM could not work for
clock always disabled at PWM driver. The PWM clock is enabled at
beginning of pwm_apply(), but disabled at end of pwm_apply().
If the PWM was enabled at U-Boot loader, PWM clock is always enabled
unless closed by ATF. The pwm-backlight might turn off the power at
early suspend, should disable PWM clock for saving power consume.
It is important to provide opportunity to enable/disable clock at PWM
driver, the PWM consumer should ensure correct order to call PWM enable
and disable, and PWM driver ensure state of PWM clock synchronized with
PWM enabled state.
Fixes: 2bf1c98aa5 ("pwm: rockchip: Add support for atomic update")
Cc: stable@vger.kernel.org
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
At least on cherrytrail, the update bit will never go low when the
enabled bit is not set.
This causes the backlight on my cube iwork8 air tablet to never turn on
again after being turned off because in the pwm_lpss_apply enable path
pwm_lpss_update will fail causing an error exit and the enable-bit to
never get set. Any following pwm_lpss_apply calls will fail the
pwm_lpss_is_updating check.
Since the docs say that the update bit should be set before the
enable-bit, split pwm_lpss_update into setting the update-bit and
pwm_lpss_wait_for_update, and move the pwm_lpss_wait_for_update call
in the enable path to after setting the enable-bit.
Fixes: 10d56a4 ("pwm: lpss: Avoid reconfiguring while UPDATE bit...")
Cc: Ilkka Koskinen <ilkka.koskinen@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
As a preparation for special treatment for Broxton we split Tangier
configuration.
Fixes: b89b4b7a3d ("pwm: lpss: pci: Enable PWM module on Intel Edison")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set contains mostly fixes to existing drivers as well as cleanup of
code that's not been in active use for a while.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAli1+XgZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoX8LD/4l8MeOgKo+uWsfX7tY1kQ/
gWitT/g+jCl3kXYtmcDTaLbEnNr0b5tGahmYC7rnCLhoq6Sp1VXjm6LChuoIUrMF
r53IlUEEgHhClfCK/vqrp/kZoFndmtLZN2V6K8gpM730nNLYAwH6FhGmUFYp47Sm
Xfdl5PwuSVDNnrBehjXPuAqUpFTp8lzrZsRkFrbX5a6TJ7hjn0TwNdovdGa6pV7k
0LXKBfSGTRS2BxDmAFqXItC2USG7v3WRCDc4jCtykNLyQKU1yCA+AYwgR9+1jj8o
1I07gjbZ+Fp8hzcQw/88MdodtS1xGV75WquhYLYWTgbneEWAcRVM47wklvL5gm7O
70lIAvOveSFGjFoWnB9YACkOoZIxDINLhWwBD0Ytfpu/gaj3VsP/WrdMu6dk5kWq
va4XHCS+dObT3o4fRkxQsQJVhAJmg4000Mupg4DOgaigd1PmFLFjBsmHua4+Ssf5
c+y+SVAg8+c3jqA9mHxPJAJesJ41fXBQCB1Xy8pDOe8iK9fBiZjkq2ssiDerN0kI
Sc4+hZHaGRhJqZUItvKJvNhdvrPkzQsRjrZgVLW/bDEXek3SXEmBAFsuZnr6w4BZ
TVVxTNzg+h4obJZEay/P6oWO6KDfF/RyTK0CUHj/ORHxbqUViiwlSJkTVgp7Etd6
mJj0xObBIwUGnSYvqGcShA==
=J9q4
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set contains mostly fixes to existing drivers as well as cleanup
of code that's not been in active use for a while"
* tag 'pwm/for-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (27 commits)
acpi: lpss: call pwm_add_table() for BSW PWM device
pwm: Try to load modules during pwm_get()
pwm: Don't hold pwm_lookup_lock longer than necessary
pwm: Make the PWM_POLARITY flag in DTB optional
pwm: Print error messages with pr_err() instead of pr_debug()
pwm: imx: Add polarity inversion support to i.MX's PWMv2
pwm: imx: doc: Update imx-pwm.txt documentation entry
pwm: imx: Remove redundant i.MX PWMv2 code
pwm: imx: Provide atomic PWM support for i.MX PWMv2
pwm: imx: Move PWMv2 wait for fifo slot code to a separate function
pwm: imx: Move PWMv2 software reset code to a separate function
pwm: imx: Rewrite v1 code to facilitate switch to atomic PWM
pwm: imx: Add separate set of PWM ops for v1 and v2
pwm: imx: Remove ipg clock and enable per clock when required
pwm: lpss: Add Intel Gemini Lake PCI ID
pwm: lpss: Do not export board infos for different PWM types
pwm: lpss: Avoid reconfiguring while UPDATE bit is still enabled
pwm: lpss: Switch to new atomic API
pwm: lpss: Allow duty cycle to be 0
pwm: lpss: Avoid potential overflow of base_unit
...
Add a module name string to the pwm_lookup struct and if specified try
to load the module using request_module() if pwmchip_find_by_name() is
unable to find the PWM chip.
This is a last resort to work around drivers that can't - and can't be
made to - deal with deferred probe.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[thierry.reding@gmail.com: rename new macro, reword commit message]
[thierry.reding@gmail.com: add comment explaining use-case]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no need to hold pwm_lookup_lock after we're done with looping
over pwm_lookup_list, so release it earlier.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Change the PWM chip driver registration so that a chip driver that
supports polarity inversion can still be used with DTBs that don't
provide the polarity flag as part of the specifier.
This is done to provide polarity inversion support for the pwm-imx
driver without having to modify all existing DTS files.
Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Suggested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Make the messages that are printed in case of fatal errors actually
visible to the user without having to recompile the driver with
debugging enabled.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
With this patch the polarity settings for i.MX's PWMv2 is now supported
on top of atomic PWM setting
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The code providing functionality surpassed by the atomic PWM is not
needed anymore and hence can be removed.
Suggested-by: Stefan Agner <stefan@agner.ch>
Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The code, which waits for fifo slot, has been extracted from
imx_pwm_config_v2 function and moved to new one - imx_pwm_wait_fifo_slot().
This change reduces the overall size of imx_pwm_config_v2() and prepares
it for atomic PWM operation.
Suggested-by: Stefan Agner <stefan@agner.ch>
Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The software reset code has been extracted from imx_pwm_config_v2 function
and moved to new one - imx_pwm_sw_reset().
This change reduces the overall size of imx_pwm_config_v2() and prepares
it for atomic PWM operation.
Suggested-by: Stefan Agner <stefan@agner.ch>
Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The code has been rewritten to remove "generic" calls to
imx_pwm_{enable|disable|config}.
Such approach would facilitate switch to atomic PWM (a.k.a ->apply())
implementation.
Suggested-by: Stefan Agner <stefan@agner.ch>
Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch provides separate set of PWM operations utilized by i.MX's
v1 and v2 of the PWM hardware.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The use of the ipg clock was introduced with commit 7b27c160c6 ("pwm:
i.MX: fix clock lookup"). In the commit message it was claimed that the
ipg clock is enabled for register accesses. This is true for the
->config() callback, but not for the ->set_enable() callback. Given that
the ipg clock is not consistently enabled for all register accesses we
can assume that either it is not required at all or that the current
code does not work. Remove the ipg clock code for now so that it's no
longer in the way of refactoring the driver.
On the other hand, the i.MX 7 IP requires the peripheral clock to be
enabled before accessing its registers. Since ->config() can be called
when the PWM is disabled (in which case, the peripheral clock is also
disabled), we need to surround the imx->config() with
clk_prepare_enable(per_clk)/clk_disable_unprepare(per_clk) calls.
Note that the driver was working fine for the i.MX 7 IP so far because
the ipg and peripheral clock use the same hardware clock gate, which
guaranteed peripheral clock activation even when ->config() was called
when the PWM was disabled.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Intel Gemini Lake PWM is pretty much same as used in Intel Broxton. Add
this new PCI ID to the list of supported devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM LPSS probe drivers just pass a pointer to the exported board
info structures to pwm_lpss_probe() based on device PCI or ACPI ID.
In order to remove the knowledge of specific devices from library part of
the driver and reduce noise in exported namespace just duplicate the
board info structures and stop exporting them.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
PWM Configuration register has SW_UPDATE bit that is set when a new
configuration is written to the register. The bit is automatically
cleared at the start of the next output cycle by the IP block.
If one writes a new configuration to the register while it still has
the bit enabled, PWM may freeze. That is, while one can still write
to the register, it won't have an effect. Thus, we try to sleep long
enough that the bit gets cleared and make sure the bit is not
enabled while we update the configuration.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Richard Griffiths <richard.a.griffiths@intel.com>
Signed-off-by: Ilkka Koskinen <ilkka.koskinen@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Instead of doing things separately, which is not so reliable on some platforms,
switch the driver to use new atomic API, i.e. ->apply() callback.
The change has been tested on Intel platforms such as Broxton, BayTrail, and
Merrifield.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
A duty cycle is represented by values [0..<period>] which reflects [0%..100%].
0% of the duty cycle means always off (logical "0") on output. Allow this in
the driver.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The resolution of base_unit is derived from base_unit_bits and thus must be
equal to (2^base_unit_bits - 1). Otherwise frequency and therefore base_unit
might potentially overflow.
Prevent the above by substracting 1 in all cases where base_unit_bits or
derivative is used.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.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>
When first implementing support for changing the output frequency, an
optimization was added to continue the PWM after changing the prescaler
without having to reprogram the ON and OFF registers for the duty cycle,
in case the duty cycle stayed the same. This was flawed, because we
compared the absolute value of the duty cycle in nanoseconds instead of
the ratio to the period.
Fix the problem by removing the shortcut.
Fixes: 01ec847200 ("pwm-pca9685: Support changing the output frequency")
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Declare pwm_ops structures as const as they are only stored in the ops
field of a pwm_chip structure. This field is of type const struct pwm_ops
*, so pwm_ops structures having this property can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct pwm_ops i@p={...};
@ok1@
identifier r1.i;
position p;
struct pxa_pwm_chip pwm;
struct bfin_pwm_chip bwm;
struct vt8500_chip vp;
struct imx_chip icp;
@@
(
pwm.chip.ops=&i@p
|
bwm.chip.ops=&i@p
|
vp.chip.ops=&i@p
|
icp.chip.ops=&i@p
)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct pwm_ops i;
File size details:
text data bss dec hex filename
1646 328 0 1974 7b6 drivers/pwm/pwm-imx.o
1742 224 0 1966 7ae drivers/pwm/pwm-imx.o
1941 296 0 2237 8bd drivers/pwm/pwm-pxa.o
2037 192 0 2229 8b5 drivers/pwm/pwm-pxa.o
1946 296 0 2242 8c2 drivers/pwm/pwm-vt8500.o
2050 192 0 2242 8c2 drivers/pwm/pwm-vt8500.o
The drivers/pwm/pwm-bfin.o file did not compile.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add dependency on COMMON_CLK and allow COMPILE_TEST for broader compile
coverage. Default to Y for IPROC SoCs. This allows the driver to simply
be enabled by selecting PWM.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
[thierry.reding@gmail.com: reword commit message]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PCA9685 controller has full on/off bit for each PWM channel. Setting
this bit bypasses the PWM control and the line works just as it would be a
GPIO. Furthermore in Intel Galileo it is actually used as GPIO output for
discreet muxes on the board.
This patch adds GPIO output only support for the driver so that we can
control the muxes on Galileo using standard GPIO interfaces available in
the kernel. GPIO and PWM functionality is exclusive so only one can be
active at a time on a single PWM channel.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
All PWM devices have been marked as "might sleep" since v4.5, there is
no longer a need to differentiate on a per-chip basis.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is a very tiny pull request, with just a new driver for HiSilicon
BVT SoCs and a cleanup for the Amlogic Meson driver.
There are other patches on the list, but my timing was really bad this
time and I ended up not having the time to look at them in enough detail
to be comfortable merging them.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlhSc4MZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoeVaD/sEvL+BP0IagagRpxsUKifH
9EYcr/d4986vk1tW3HdbiydLWqbW3ud2n2CK1Quo6ZMpTp14SUa0OMgeHnBuJ4wl
XNwkXldCHnFe0Hk2fMEIXYYsQAY8TslceUswTFzt7vWvRUwDmbF/oTmCT3fjMlBJ
6u9aUX6Wq+EiD7cqpl9/a33vpMhwXANJq29LSac40HoPThga71ZgIIknIHjBGBAa
Ji5cWa8DLSQFsVvWOd6cmna8z6C8lhWFghKRyRT/F0ssvQy6pHYHisRvt6ujACYQ
X8aqfXz6tu/iLUI7r9N7edQ5MDGAY+kwooM9QKERb3tba91zcwojsBhoTJavQidB
9bPp9Khq++erInrWPo78qsgvd2PGda73AZbgBjH5mcCPjtKC0yYn6wYQh5VcP1Sc
pDxdZpJUqwjFPuLHrfYnd+/ui9dJLrP8WhXt7C6WqpCyTHCVe1GJxHARrga3OM2P
sOH4Get75Iwj2CCMTLp3hnezKsKt6TYCFa1T9of0yIz7fPMRk71EDVGUOLcXP8Nu
6oJK/34vKhfjAmRMbrirJyAMU94ihFHiHWj0zeivwuCU2Oh1Dt6sfhHRvc3IZfzB
0lXR0ERF/XFc2cOckIkW4eu0UGfAr9mvd3ADYCD/eF/HMZJKxt6+5+KoMUdw4WZ7
wPjYPUaAadHoVVkVF+Qtpg==
=WHNA
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This is a very tiny pull request, with just a new driver for HiSilicon
BVT SoCs and a cleanup for the Amlogic Meson driver.
There are other patches on the list, but my timing was really bad this
time and I ended up not having the time to look at them in enough
detail to be comfortable merging them"
* tag 'pwm/for-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: Add PWM driver for HiSilicon BVT SOCs
pwm: meson: Remove unneeded platform MODULE_ALIAS
Add PWM driver for the PWM controller found on HiSilicon BVT SoCs such
as Hi3519V100, Hi3516CV300, etc. The PWM controller is primarily in
charge of controlling the P-Iris lens.
Reviewed-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
Signed-off-by: Jian Yuan <yuanjian12@hisilicon.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Make sure to drop the reference to the parent device taken by
class_find_device() after "unexporting" any children when deregistering
a PWM chip.
Fixes: 0733424c9b ("pwm: Unexport children before chip removal")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The Amlogic Meson is a DT-only platform, which means the devices are
registered via OF and not using the legacy platform devices support.
So there's no need to have a MODULE_ALIAS("platform:meson-pwm") since
the reported uevent MODALIAS to user-space will always be the OF one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver uses the spin_lock but does not initialize it. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When building with -Wmaybe-uninitialized, we get a couple of harmless
warnings about three functions in this new driver that don't look
safe to the compiler:
drivers/pwm/pwm-meson.c: In function 'meson_pwm_get_state':
drivers/pwm/pwm-meson.c:355:26: error: 'mask' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c: In function 'meson_pwm_disable':
drivers/pwm/pwm-meson.c:263:13: error: 'enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c: In function 'meson_pwm_apply':
drivers/pwm/pwm-meson.c:231:13: error: 'clk_shift' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c:231:36: error: 'enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c:231:24: error: 'clk_enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Specifically, if we have a device with an ID other than 0 or 1,
this would result in undefined behavior. This is currently not
possible, but the compiler cannot be expected to know this.
This patch adds a 'default' clause to let the compiler know
what to do instead, which shuts up the warning and makes the
code slightly more resiliant in case it gets extended to other
identifiers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This includes fixing some Coding Style issues and re-ordering and/or
simplifying a little code.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: applied some bikeshedding>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Setting up the STI PWM IP as capture only, with zero PWM output devices
is a perfectly valid configuration. It is no longer okay to assume that
there must be at least 1 PWM output device. In this patch we make the
default number of PWM output devices zero and only configure channels
explicitly requested.
Reported-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Once a PWM capture has been initiated, the capture call enables a rising
edge detection interrupt, then waits. Once each of the 3 phase changes
have been recorded the thread then wakes. The remaining part of the call
carries out the relevant calculations and returns a structure filled out
with the capture data.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Here we're requesting the PWM capture IRQ and supplying the handler that
will be called in the event of an interrupt to handle it.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Each PWM capture device is allocated a structure to hold its own state.
During a capture the device may be partaking in one of 3 phases. Initial
(rising) phase change, a subsequent (falling) phase change indicating
end of the duty-cycle phase and finally a final (rising) phase change
indicating the end of the period. The timer value snapshot each event is
held in a variable of the same name, and the phase number (0, 1, 2) is
contained in the index variable. Other device specific information, such
as GPIO pin, the IRQ wait queue and locking is also contained in the
structure. This patch initialises this structure for each of the
available devices.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
ST's PWM IP is supplied by 2 different clocks. One for PWM output and
the other for capture. This patch provides clock handling for the
latter.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is in preparation for subsequent patches that add support for PWM
capture to this driver.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In the original code the clock rate was only obtained during
initialisation; however, the rate may change between then and
its use. This patch ensures the correct rate is acquired just
before use.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Exciting functionality is on the way to this device. But
before we can add it, we need to do some basic housekeeping
so the additions can be added cleanly.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is to bring the terminology used in the STi PWM driver more
into line with the PWM subsystem.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The lpc-18xx driver currently manipulates the pwm_device struct directly
rather than using the pwm_set_chip_data() function. While the current
method may save a clock cycle or two, using the explicit function call
makes it more obvious that data is set to the local chip data pointer.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Reviewed-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for the PWM controller found in the Amlogic SoCs. This
driver supports the Meson8b and GXBB SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
From pwm_samsung_calc_tin(), there is routine to find the lowest divider
possible to generate lower frequency than requested one. But it is
always possible to generate requested frequency with large enough
modulation bits except on s3c24xx, so this patch fixes to use lowest div
for the case. This patch removes following UBSAN warning:
UBSAN: Undefined behaviour in drivers/pwm/pwm-samsung.c:197:13
shift exponent 32 is too large for 32-bit type 'long unsigned int'
[...]
[<c0670248>] (ubsan_epilogue) from [<c06707b4>] (__ubsan_handle_shift_out_of_bounds+0xd8/0x120)
[<c06707b4>] (__ubsan_handle_shift_out_of_bounds) from [<c0694b28>] (pwm_samsung_config+0x508/0x6a4)
[<c0694b28>] (pwm_samsung_config) from [<c069286c>] (pwm_apply_state+0x174/0x40c)
[<c069286c>] (pwm_apply_state) from [<c0b2e070>] (pwm_fan_probe+0xc8/0x488)
[<c0b2e070>] (pwm_fan_probe) from [<c07ba8b0>] (platform_drv_probe+0x70/0x150)
[...]
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Remove all pm_runtime_get_sync() and pm_runtime_put_sync() call as well
as the dummy pm_ops from the pwm-tipwmss driver. No registers are being
modified. The runtime PM still needs to be enabled, so that the runtime
PM framework can take care of enabling/disabling the PWMSS clock when
submodules of PWMSS (ECAP or EHRPWM) call runtime PM APIs. With this
change PWMSS clock goes to idle when none of the submodules are in use.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
While the particular usage in question is likely safe (struct
cros_ec_command is 32-bit aligned, followed by <= 32-bit fields), it's
been suggested this is not a great pattern to follow for the general
case -- for example, if we follow a 'struct cros_ec_command' (which is
32-bit- but not 64-bit-aligned) with a struct that starts with a 64-bit
type (e.g., u64), the compiler may add padding.
Let's add __packed, to inform the compiler of our true intention -- to
have no padding between these struct elements -- and to future proof for
any refactorings that might occur.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use the mtk_pwm_data struction to define different registers
and add MT2701 specific register operations, such as MT2701
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select manual mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Weiqing Kong <weiqing.kong@mediatek.com>
[thierry.reding@gmail.com: use of_device_get_match_data()]
[thierry.reding@gmail.com: parameterize more consistently]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds suspend-to-RAM support to the Berlin PWM driver.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current TWL6030 code for the TWL PWM driver does not reliably disable the
PWM output, as tested with LEDs. The previous commit to that driver introduced
that regression.
However, it does make sense to disable the PWM clock after resetting the PWM,
but for some obscure reason, doing it all at once simply doesn't work.
The TWL6030 datasheet mentions that PWMs have to be disabled in two distinct
steps. However, clearing the clock enable bit in a second step (after issuing a
reset first) does not work.
The only approach that works is the one that was in place before the previous
commit to the driver. It consists in enabling the PWM clock after issuing a
reset. This is what TI kernel trees and production code seem to be using.
However, adding an extra step to disable the PWM clock seems to work reliably,
despite looking quite odd.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom iProc,
STMPE and ChromeOS EC controllers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQI2BAABCAAgBQJXpLFKGRx0aGllcnJ5LnJlZGluZ0BnbWFpbC5jb20ACgkQ3SOs
138+s6E2Nw/9FggtgYlVQRS5lzwTKxQI/5HMlOfdyH84S76fUS8uAxvEsZvyHXZ7
NiwCJMkmMqPHMlrfuXacs4nueKz3jvy8csaffH5T2yHf0ZPGmkxBsdX97rvQp3z/
WTUXX8vo8fiEPQSXQOUzIYk10s7CBO2094uL8FBqfYeSySY3Ti35SpmZSQKVd1LS
A1rR/qRgNbIlhI7+L5CotdrNMkHXqHZIHDyXO1dWBDVL+3MU3IPpB//J/WjU/OMs
5MHEtTr7943s8LQYhM1p5PFDn8ehe31L1quSswmMTLuepPrTUjD31476VYW8p8gg
lzOv5JF5b8Rkw0B+4vDC0z/OPZA47tg8DfiS9Sa1SrCGxslOH7pvI7m9dV89FOc2
/hA1n048jBhIrHPylXZ+hUPKNM0WTwFrHVxROgtEb6/wtYskgOFGQrYKpD4FtH+j
zqXxvCRMX4ZLLXy2QO4GAW3dv51pLjiM2yxVWtM1lWFWiKKvRoqHiFcnmCJJwQ4T
NXUPnyt+G/GCtpVHlMtHW9YszJ650ECt+H8I1EhuGLkpOXncCPdmw34oR1wSmMi3
+1yjCvZV8bNJLt2GQDpoFEUc1dqY6g/SLqm9sz+W69QYA0oDt9JpFK+RFw118282
EX24GT9+PYe0kMt1WWopjHeFZ+6HhsG/ODwOUOaG/8kp6qZLB4EKP9k=
=TdEI
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.8-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 improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom
iProc, STMPE and ChromeOS EC controllers"
* tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range
regulator: pwm: Support extra continuous mode cases
pwm: Add ChromeOS EC PWM driver
dt-bindings: pwm: Add binding for ChromeOS EC PWM
mfd: cros_ec: Add EC_PWM function definitions
mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper
pwm: atmel: Use of_device_get_match_data()
pwm: atmel: Fix checkpatch warnings
pwm: atmel: Fix disabling of PWM channels
dt-bindings: pwm: Add R-Car H3 device tree bindings
pwm: rcar: Use ARCH_RENESAS
pwm: tegra: Add support for Tegra186
dt-bindings: pwm: tegra: Add compatible string for Tegra186
pwm: tegra: Avoid overflow when calculating duty cycle
pwm: tegra: Allow 100 % duty cycle
pwm: tegra: Add support for reset control
pwm: tegra: Rename mmio_base to regs
pwm: tegra: Remove useless padding
pwm: tegra: Drop NUM_PWM macro
pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value
...
Driver updates for ARM SoCs.
A slew of changes this release cycle. The reset driver tree, that we merge
through arm-soc for historical reasons, is also sizable this time around.
Among the changes:
- clps711x: Treewide changes to compatible strings, merged here for simplicity.
- Qualcomm: SCM firmware driver cleanups, move to platform driver
- ux500: Major cleanups, removal of old mach-specific infrastructure.
- Atmel external bus memory driver
- Move of brcmstb platform to the rest of bcm
- PMC driver updates for tegra, various fixes and improvements
- Samsung platform driver updates to support 64-bit Exynos platforms
- Reset controller cleanups moving to devm_reset_controller_register() APIs
- Reset controller driver for Amlogic Meson
- Reset controller driver for Hisilicon hi6220
- ARM SCPI power domain support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXnm1XAAoJEIwa5zzehBx35lcP/ApuQarIXeZCQZtjlUBV9McW
o3o7FhKFHePmEPeoYCvVeK5D8NykTkQv3WpnCknoxPJzxGJF7jbPWQJcVnXfKOXD
kTcyIK15WL2HHtSE3lYyLfyUPz8AbJyRt0l0cxgcg6jvo+uzlWooNz1y78rLIYzg
UwRssj7OiHv4dsyYRHZIsjnB8gMWw8rYMk154gP2xy6MnNXXzzOVVnOiVqxSZBm+
EgIIcROMOqkkHuFlClMYKluIgrmgz1Ypjf+FuAg7dqXZd+TGRrmGXeI7SkGThfLu
nyvY3N18NViNu7xOUkI9zg7+ifyYM8Si9ylalSICSJdIAxZfiwFqFaLJvVWKU1rY
rBOBjKckQI0/X9WYusFNFHcijhIFV8/FgGAnVRRMPdvlCss7Zp03C9mR4AEhmKMX
rLG49x81hU1C+LftC59ml3iB8dhZrrRkbxNHjLFHVGWNrKMrmJKa8JhXGRAoNM+u
LRauiuJZatqvLfISNvpfcoW2EashVoU3f+uC8ymT3QCyME3wZm0t7T4tllxhMfBl
sOgJqNkTKDmPLofwm/dASiLML7ZF1WePScrFyOACnj9K4mUD+OaCnowtWoQPu0eI
aNmT84oosJ2S9F/iUDPtFHXdzQ+1QPPfSiQ9FXMoauciVq/2F+pqq68yYgqoxFOG
vmkmG2YM4Wyq43u0BONR
=O8+y
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver updates from Olof Johansson:
"Driver updates for ARM SoCs.
A slew of changes this release cycle. The reset driver tree, that we
merge through arm-soc for historical reasons, is also sizable this
time around.
Among the changes:
- clps711x: Treewide changes to compatible strings, merged here for simplicity.
- Qualcomm: SCM firmware driver cleanups, move to platform driver
- ux500: Major cleanups, removal of old mach-specific infrastructure.
- Atmel external bus memory driver
- Move of brcmstb platform to the rest of bcm
- PMC driver updates for tegra, various fixes and improvements
- Samsung platform driver updates to support 64-bit Exynos platforms
- Reset controller cleanups moving to devm_reset_controller_register() APIs
- Reset controller driver for Amlogic Meson
- Reset controller driver for Hisilicon hi6220
- ARM SCPI power domain support"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (100 commits)
ARM: ux500: consolidate base platform files
ARM: ux500: move soc_id driver to drivers/soc
ARM: ux500: call ux500_setup_id later
ARM: ux500: consolidate soc_device code in id.c
ARM: ux500: remove cpu_is_u* helpers
ARM: ux500: use CLK_OF_DECLARE()
ARM: ux500: move l2x0 init to .init_irq
mfd: db8500 stop passing around platform data
ASoC: ab8500-codec: remove platform data based probe
ARM: ux500: move ab8500_regulator_plat_data into driver
ARM: ux500: remove unused regulator data
soc: raspberrypi-power: add CONFIG_OF dependency
firmware: scpi: add CONFIG_OF dependency
video: clps711x-fb: Changing the compatibility string to match with the smallest supported chip
input: clps711x-keypad: Changing the compatibility string to match with the smallest supported chip
pwm: clps711x: Changing the compatibility string to match with the smallest supported chip
serial: clps711x: Changing the compatibility string to match with the smallest supported chip
irqchip: clps711x: Changing the compatibility string to match with the smallest supported chip
clocksource: clps711x: Changing the compatibility string to match with the smallest supported chip
clk: clps711x: Changing the compatibility string to match with the smallest supported chip
...
Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.
This driver supports only device tree at the moment, because that
provides a very flexible way of describing the relationship between PWMs
and their consumer devices (e.g., backlight). On a non-DT system, we'll
probably want to use the non-GENERIC addressing (i.e., we'll need to
make special device instances that will use EC_PWM_TYPE_KB_LIGHT or
EC_PWM_TYPE_DISPLAY_LIGHT), as well as the relatively inflexible
pwm_lookup infrastructure for matching devices. Defer that work for now.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When disabling a PWM channel, the PWM clock was being stopped
immediately after writing to PWM_DIS. As a result, the disabling
of the PWM channel did not complete properly, and the PWM output
might be left at the wrong level.
Fix this by waiting for the channel to be effectively disabled
(by checking the PWM_SR register) before disabling the clock.
Signed-off-by: Guillermo Rodriguez <guille.rodriguez@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Tegra186 has multiple PWM controllers with only one output instead of
one controller with four outputs in earlier SoC generations.
Add support for Tegra186 and detect the number of PWM outputs using
device tree match data.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
duty_ns * (1 << PWM_DUTY_WIDTH) could overflow in integer calculation
when the PWM rate is low. Hence do all calculation on unsigned long long
to avoid overflow.
Signed-off-by: Hyong Bin Kim <hyongbink@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To get 100 % duty cycle (always high), pulse width needs to be set to
256.
Signed-off-by: Victor(Weiguo) Pan <wpan@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add reset control of the PWM controller to reset it before
accessing the PWM register.
Signed-off-by: Rohith Seelaboyina <rseelaboyina@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The former is much longer to type and is ambiguous because the value
stored in the field is not the (physical) base address of the memory-
mapped I/O registers, but the virtual address of those registers as
mapped through the MMU.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This macro is used to initialize the ->npwm field of the PWM chip. Use a
literal instead and make all other places rely on ->npwm.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM_PIN_LEVEL bit is leave unset by the kernel PWM driver.
Prior to commit 08ee77b5a5,
the PWM_PIN_LEVEL bit was always clear when the PWM was disable
and a 0 logic level was apply to the output.
According to the LPC32x0 User Manual [1],
the default value for bit 30 (PWM_PIN_LEVEL) is 0.
This change initialize the pin level to 0 (default value) and
update the register value accordingly.
[1] http://www.nxp.com/documents/user_manual/UM10326.pdf
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This adds a driver for the PWM block found in chips of the STMPE 24xx
series of multi-purpose I2C expanders. (I think STMPE means ST
Microelectronics Multi-Purpose Expander.) This PWM was designed in
accordance with Nokia specifications and is kind of weird and usually
just switched between max and zero duty cycle. However it is indeed a
PWM so it needs to live in the PWM subsystem.
This PWM is mostly used for white LED backlight.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->apply() function to add support for atomic update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current logic will disable the PWM clk even if the PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if the PWM is enabled to avoid any glitches.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->get_state() function to expose initial state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current implementation always round down the duty and period values,
while it would be better to round them to the closest integer.
These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several times the
'pwm_get_state() / modify / pwm_apply_state()' sequence.
Say you have an expected period of 3.333 us and a clk rate of
112.666667 MHz -- the clock frequency doesn't divide evenly, so the
period (stashed in nanoseconds) shrinks when we convert to the register
value and back, as follows:
pwm_apply_state(): register = period * 112666667 / 1000000000;
pwm_get_state(): period = register * 1000000000 / 112666667;
or in other words:
period = period * 112666667 / 1000000000 * 1000000000 / 112666667;
which yields a sequence like:
3333 -> 3328
3328 -> 3319
3319 -> 3310
3310 -> 3301
3301 -> 3292
3292 -> ... (etc) ...
With this patch, we'd see instead:
period = div_round_closest(period * 112666667, 1000000000) *
1000000000 / 112666667;
which yields a stable sequence:
3333 -> 3337
3337 -> 3337
3337 -> ... (etc) ...
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for the PWM controller present in Broadcom's iProc family of
SoCs. It has been tested on the Northstar+ bcm958625HR board.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
[thierry.reding@gmail.com: bunch of coding style fixes, cleanups]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no need to check each time if the clk_rate defined or not when we call
pwm_lpss_config(). Move the check to ->probe() instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Intel Edison has 4 PWM channels on the die with the same IP as in
Broxton. Enable it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If duty_ns is large enough multiplying it by 255 overflows and results
wrong duty cycle value being programmed. For example with 10ms duty when
period is 20ms (50%) we get
255 * 10000000 / 20000000 = -87
because 255 * 10000000 overlows int. Whereas correct value should be
255 * 10000000 / 20000000 = 127
Fix this by using unsigned long long as type for on_time_div and changing
integer literals to use proper type annotation.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The base_unit calculation applies an offset of 0x2 which adds
significant error for lower frequencies and doesn't appear to be
warranted - rounding the division result gives a correct value.
Also, the upper limit check for base_unit is off-by-one; the upper
nibble of base_unit is invalid if >=128 according to the Table 88
in the Z8000 Processor Series Datasheet Volume 1 (Rev. 2).
Verified on UP Board (Cherry Trail) and Minnowboard Max (Bay Trail).
Signed-off-by: Dan O'Donovan <dan@emutex.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.
Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When using the old eCAP and ePWM bindings for AM335x and AM437x the clock
can be retrieved from the PWMSS parent. Newer bindings will insure that
this clock is provided via device tree.
Therefore, update this driver to support the newer and older bindings. In
the case of the older binding being used give a warning.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
[thierry.reding@gmail.com: rewrite slightly for readability]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
booting.
This driver has been unusable with multiarch because of the hardware
timer access. With the recent PWM changes, we can finally fix the
driver for multiarch and device tree support. And naturally there
is no rush for these for the -rc cycle, these can wait for the
merge window.
The PWM changes have been acked by Thierry. For the media changes
I did not get an ack from Mauro but he was Cc'd in the discussion
and these changes do not conflict with other media changes.
After this series we can drop the remaining omap3 legacy booting
board files finally.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXe1v2AAoJEBvUPslcq6VzLvsQALIWLcgyqUKNgPV6EOxAsxeO
azvjPPZgI0oTl5+voS6dzSg5mXhQt3rVlaXxJXxCdxYgOf67zYjugrJqf5Sm4stF
BEtzPGLRTwR8miJbHNB8eGfcBGU3q+hx19dT+U7EAsPQqItlFfxVTh5ZzS0TOZc2
9bQGO6MYIWNEk6V0TRxNUfRt+4fQN17zRdIpKL8NCJOsoBn9ZpztB76GeHUnd34t
pYeaMFPdVUqBCQOmE9EA3dmOB7q37JgtsM312zpn72OgzpTTttza1Vo6HAh7dTWM
Pmphin+H54zmsrB3wvI0h4G2WmuZjNNEHBTbLV4fgTjDer4o84RHJUGOgQmmPnni
q9nyuV0y1gudk8ihlq7hxnickPS+NCSk8aQgAfspY+8rhxYWstJdJ66gUl+bUPlQ
qaOvNACaEMVuRdeqnuTLm/mhQdVLz5VuUzSZkAWosVVuCVY9ONLt/t/Mxbylqf9P
CfKiDBEUp+DQ8Ly4L0odD7n4fOWOq6XOx3RR6C4IJqkLyb6VL5O8POKNsHuMvb1q
ptWyN1aWHrdYvd4PD0QB6hakY+C2P9BSAMb0t9ZscAX1nGvkGY27TRzHD8rkhHZD
WKy5J4gzr8VDLnQom9MwoXcoqrWKTGY5QCqw1hdUrqNlVnRJTu2jYc5NrYxOK0mD
TUC5drgK5e2mjmgUv95q
=frvc
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.8/ir-rx51-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers
Merge "omap ir-rx51 driver fixes for multiarch for v4.8 merge window"
from Tony Lindgren:
Fix a long time regression for ir-rx51 driver for n900 device tree
booting.
This driver has been unusable with multiarch because of the hardware
timer access. With the recent PWM changes, we can finally fix the
driver for multiarch and device tree support. And naturally there
is no rush for these for the -rc cycle, these can wait for the
merge window.
The PWM changes have been acked by Thierry. For the media changes
I did not get an ack from Mauro but he was Cc'd in the discussion
and these changes do not conflict with other media changes.
After this series we can drop the remaining omap3 legacy booting
board files finally.
* tag 'omap-for-v4.8/ir-rx51-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ir-rx51: use hrtimer instead of dmtimer
ir-rx51: add DT support to driver
ir-rx51: use PWM framework instead of OMAP dmtimer
pwm: omap-dmtimer: Allow for setting dmtimer clock source
ir-rx51: Fix build after multiarch changes broke it
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
OMAP GP timers can have different input clocks that allow different PWM
frequencies. However, there is no other way of setting the clock source but
through clocks or clock-names properties of the timer itself. This limits
PWM functionality to only the frequencies allowed by the particular clock
source. Allowing setting the clock source by PWM rather than by timer
allows different PWMs to have different ranges by not hard-wiring the clock
source to the timer.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The PWM device exposed by the HLCDC IP is configured with an inverted
polarity by default. Registering the PWM chip with the normal polarity
was not a problem before commit 42e8992c58d4 ("pwm: Add core
infrastructure to allow atomic updates") because the ->set_polarity()
hook was called no matter the current polarity state, but this is no longer
the case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Allow a user to read PWM capture results from sysfs. To start a capture
and read the result, simply read the file:
$ cat $PWMCHIP/capture
The output format is "<period> <duty cycle>".
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Supply a PWM capture callback op in order to pass back information
obtained by running analysis on a PWM signal. This would normally (at
least during testing) be called from the sysfs routines with a view to
printing out PWM capture data which has been encoded into a string.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: make capture data unsigned int for symmetry]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds to check the return value from pwm_apply_state()
used in enable_store(). The error of enable_store() doesn't work
if the return value doesn't received.
Signed-off-by: Ryo Kodama <ryo.kodama.vz@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: 39100ceea7 ("pwm: Switch to the atomic API")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
It seems like in the process of refactoring pwm_config() to utilize the
newly-introduced pwm_apply_state() API, some args/bounds checking was
dropped.
In particular, I noted that we are now allowing invalid period
selections, e.g.:
# echo 1 > /sys/class/pwm/pwmchip0/export
# cat /sys/class/pwm/pwmchip0/pwm1/period
100
# echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
[... driver may or may not reject the value, or trigger some logic bug ...]
It's better to see:
# echo 1 > /sys/class/pwm/pwmchip0/export
# cat /sys/class/pwm/pwmchip0/pwm1/period
100
# echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
-bash: echo: write error: Invalid argument
This patch reintroduces some bounds checks in both pwm_config() (for its
signed parameters; we don't want to convert negative values into large
unsigned values) and in pwm_apply_state() (which fix the above described
behavior, as well as other potential API misuses).
Fixes: 5ec803edcb ("pwm: Add core infrastructure to allow atomic updates")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes introduces an atomic API to the PWM subsystem. This
is influenced by the DRM atomic API that was introduced a while back,
though it is obviously a lot simpler. The fundamental idea remains the
same, though: drivers provide a single callback to implement the atomic
configuration of a PWM channel.
As a side-effect the PWM subsystem gains the ability for initial state
retrieval, so that the logical state mirrors that of the hardware. Many
use-cases don't care about this, but for others it is essential.
These new features require changes in all users, which these patches
take care of. The core is transitioned to use the atomic callback if
available and provides a fallback mechanism for other drivers.
Changes to transition users and drivers to the atomic API are postponed
to v4.8.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXRcVWAAoJEN0jrNd/PrOhO3EP/RDuuco1fROml1ElCjcnWWfv
3dPyKEJhZktMmRNd/V0zMUJiOwr77wlbX4oQ5HajMHNYFQ65jfihbbylhSDepnxg
mjKV/yo18rzYZt9fv8huwvlwMOlLrJ9wQn4Gkbr5tzke6nITp52DTNH5y/anPQIk
B7neA1TerodAbE9FWjYuBZIltkmYZDqdm//RCHXVyYym8VuotE+jf+nrMXI78FoL
lgG64z/2OaGI+NZJQcpWftuz9nnenpa3sSLrvpitWEb/dAsXroMW/f08uVuOW87v
0xk7N7zmEkef7izVOWiPOK/MxIdc8hI4A5JftzMJ7nbgJvwG78dJiOxgFhrJYx0z
7zrYfjvvzjW0dpjZUvO37T/V5Rfxrk9sM7qUHJmN0+1oEkkCo1/c75JWTU2AmT4l
qkJdOGhgv7LumIiwbEyxc/5Jyh1akKOUX2svO0+0dptLRX2UpN3yeKIYinG1dAuT
86+/uuM6CL5gc+jVZ3GLNWfzHUu2RFVX0r0pzywq53pK5gMEs5WyxoIb5mHb8liA
sHsrZ3wbGGn95yZo8CwkzXIUsUH7qKYK+UVWA6OVBoTq4AOBZtII1AqvUttl25qL
xuKpj70xaBhK7VGqzDYQ68lqBaRySh+yzL/QsmnPEyx59mW81ytMrsn1Kmnuae2l
bzUsnWrpHc6530fRggTD
=sxT9
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.7-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 introduces an atomic API to the PWM subsystem.
This is influenced by the DRM atomic API that was introduced a while
back, though it is obviously a lot simpler. The fundamental idea
remains the same, though: drivers provide a single callback to
implement the atomic configuration of a PWM channel.
As a side-effect the PWM subsystem gains the ability for initial state
retrieval, so that the logical state mirrors that of the hardware.
Many use-cases don't care about this, but for others it is essential.
These new features require changes in all users, which these patches
take care of. The core is transitioned to use the atomic callback if
available and provides a fallback mechanism for other drivers.
Changes to transition users and drivers to the atomic API are
postponed to v4.8"
* tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (30 commits)
pwm: Add information about polarity, duty cycle and period to debugfs
pwm: Switch to the atomic API
pwm: Update documentation
pwm: Add core infrastructure to allow atomic updates
pwm: Add hardware readout infrastructure
pwm: Move the enabled/disabled info into pwm_state
pwm: Introduce the pwm_state concept
pwm: Keep PWM state in sync with hardware state
ARM: Explicitly apply PWM config extracted from pwm_args
drm: i915: Explicitly apply PWM config extracted from pwm_args
input: misc: pwm-beeper: Explicitly apply PWM config extracted from pwm_args
input: misc: max8997: Explicitly apply PWM config extracted from pwm_args
backlight: lm3630a: explicitly apply PWM config extracted from pwm_args
backlight: lp855x: Explicitly apply PWM config extracted from pwm_args
backlight: lp8788: Explicitly apply PWM config extracted from pwm_args
backlight: pwm_bl: Use pwm_get_args() where appropriate
fbdev: ssd1307fb: Use pwm_get_args() where appropriate
regulator: pwm: Use pwm_get_args() where appropriate
leds: pwm: Use pwm_get_args() where appropriate
input: misc: max77693: Use pwm_get_args() where appropriate
...
The PWM states make it possible to also output the polarity, duty cycle
and period information in the debugfs summary output. This simplifies
gathering information about PWMs without needing to walk through the
sysfs attributes of every PWM.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: use more spaces in debugfs output]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic updates. This method is preferred over the ->enable(),
->disable() and ->config() methods if available.
Add the pwm_apply_state() function to the PWM user API.
Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.
pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.
pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Prepare the transition to PWM atomic update by moving the enabled and
disabled state into the pwm_state struct. This way we can easily update
the whole PWM state by copying the new state in the ->state field.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM state, represented by its period, duty_cycle and polarity is
currently directly stored in the PWM device. Declare a pwm_state
structure embedding those field so that we can later use this struct
to atomically update all the PWM parameters at once.
All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Before the introduction of pwm_args, the core was resetting the PWM
period and polarity states to the reference values (those provided
through the DT, a PWM lookup table or hardcoded in the driver).
Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in pwm_get()
and of_pwm_get().
We can also get rid of the pwm_set_period() call in pwm_apply_args(),
because PWM users are now directly using pargs->period instead of
pwm_get_period(). By doing that we avoid messing with the current PWM
period.
The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
field. Doing that will ease adaptation of the PWM framework to support
atomic update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
