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>

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>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Implement the ->get_state() function to expose initial state.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NThierry 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NThierry 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: NYendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
[thierry.reding@gmail.com: bunch of coding style fixes, cleanups]
Signed-off-by: NThierry 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NThierry 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NThierry 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: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NThierry 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: NDan O'Donovan <dan@emutex.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NThierry 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: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NThierry 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: NFranklin S Cooper Jr <fcooper@ti.com>
[thierry.reding@gmail.com: rewrite slightly for readability]
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NArnd 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: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTony 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NThierry 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: NLee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: make capture data unsigned int for symmetry]
Signed-off-by: NThierry 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: NRyo Kodama <ryo.kodama.vz@renesas.com>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: 39100cee ("pwm: Switch to the atomic API")
Signed-off-by: NThierry 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: 5ec803ed ("pwm: Add core infrastructure to allow atomic updates")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: use more spaces in debugfs output]
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>