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>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: NThierry 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>