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: NJiancheng Xue <xuejiancheng@hisilicon.com>
Signed-off-by: NJian Yuan <yuanjian12@hisilicon.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry 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: 0733424c ("pwm: Unexport children before chip removal")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NThierry 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: NJavier Martinez Canillas <javier@osg.samsung.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

The driver uses the spin_lock but does not initialize it. Fix it.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NThierry 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: NArnd Bergmann <arnd@arndb.de>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

This includes fixing some Coding Style issues and re-ordering and/or
simplifying a little code.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: applied some bikeshedding>
Signed-off-by: NThierry 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: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

This is in preparation for subsequent patches that add support for PWM
capture to this driver.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NOlliver Schinagl <oliver@schinagl.nl>
Reviewed-by: NAriel D'Alessandro <ariel@vanguardiasur.com.ar>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

H3 PWM controller has same register layout as sun4i driver, so it works
by adding H3 specific data.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: linux-pwm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NMilo Kim <woogyom.kim@gmail.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry 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: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NThierry 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: NSeung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NThierry 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: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NThierry 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: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NThierry 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: NWeiqing 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: NThierry Reding <thierry.reding@gmail.com>

This patch adds suspend-to-RAM support to the Berlin PWM driver.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NThierry 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: NDavid Hsu <davidhsu@google.com>
Fixes: 76abbdde ("pwm: Add sysfs interface")
Signed-off-by: NThierry 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: NPaul Kocialkowski <contact@paulk.fr>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Use of_device_get_match_data() instead of an open-coded variant.
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Avoid an overly long line by moving a comment around, and remove a use
of else-after-return.
Signed-off-by: NThierry 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: NGuillermo Rodriguez <guille.rodriguez@gmail.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Replace ARCH_RCAR_GEN{1,2} with ARCH_RENESAS in order to support R-Car Gen3.
Signed-off-by: NRyo Kodama <ryo.kodama.vz@renesas.com>
Signed-off-by: NHarunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NThierry 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: NLaxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NThierry 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: NHyong Bin Kim <hyongbink@nvidia.com>
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

To get 100 % duty cycle (always high), pulse width needs to be set to
256.
Signed-off-by: NVictor(Weiguo) Pan <wpan@nvidia.com>
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Add reset control of the PWM controller to reset it before
accessing the PWM register.
Signed-off-by: NRohith Seelaboyina <rseelaboyina@nvidia.com>
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NThierry 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: NThierry Reding <thierry.reding@gmail.com>

Use single spaces to separate data type from field names in structure
definitions.
Signed-off-by: NThierry 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: NThierry Reding <thierry.reding@gmail.com>

The PWM_PIN_LEVEL bit is leave unset by the kernel PWM driver.

Prior to commit 08ee77b5,
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.pdfSigned-off-by: NSylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: NThierry 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: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Implement the ->apply() function to add support for atomic update.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>