summaryrefslogtreecommitdiffstats
path: root/drivers/pwm (follow)
Commit message (Collapse)AuthorAgeFilesLines
* pwm: Fix device reference leakJohan Hovold2016-11-291-0/+2
| | | | | | | | | | 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: 0733424c9ba9 ("pwm: Unexport children before chip removal") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* pwm: meson: Add missing spin_lock_init()Axel Lin2016-10-211-0/+1
| | | | | | | | 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>
* Merge branch 'for-4.9/drivers' into for-nextThierry Reding2016-09-0812-141/+1127
|\
| * pwm: meson: Handle unknown ID valuesArnd Bergmann2016-09-081-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Take the opportunity to conduct a little house keepingLee Jones2016-09-081-72/+81
| | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: It's now valid for number of PWM channels to be zeroLee Jones2016-09-081-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Add PWM capture callbackLee Jones2016-09-081-0/+88
| | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Add support for PWM capture interruptsLee Jones2016-09-081-1/+91
| | | | | | | | | | | | | | | | 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>
| * pwm: sti: Initialise PWM capture device dataLee Jones2016-09-081-7/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Supply PWM Capture clock handlingLee Jones2016-09-081-0/+25
| | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Supply PWM capture register addresses and bit locationsLee Jones2016-09-081-0/+25
| | | | | | | | | | | | | | | | 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>
| * pwm: sti: Only request clock rate when neededLee Jones2016-09-081-8/+8
| | | | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Reorganise register names in preparation for new functionalityLee Jones2016-09-081-35/+41
| | | | | | | | | | | | | | | | | | 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>
| * pwm: sti: Rename channel => deviceLee Jones2016-09-081-16/+16
| | | | | | | | | | | | | | | | 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>
| * pwm: lpc-18xx: use pwm_set_chip_dataoliver@schinagl.nl2016-09-081-4/+8
| | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: sunxi: Add H3 supportMilo Kim2016-09-081-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Milo Kim <woogyom.kim@gmail.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
| * pwm: Add support for Meson PWM ControllerNeil Armstrong2016-09-083-0/+530
| | | | | | | | | | | | | | | | | | | | 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>
| * pwm: samsung: Fix to use lowest div for large enough modulation bitsSeung-Woo Kim2016-09-061-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: pwm-tipwmss: Remove all runtime PM gets/putsJyri Sarha2016-09-061-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: cros-ec: Add __packed to prevent paddingBrian Norris2016-09-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: Add MediaTek MT2701 display PWM driver supportWeiqing Kong2016-09-061-15/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pwm: berlin: Add suspend/resume supportJisheng Zhang2016-09-061-0/+84
| | | | | | | | | | | | | | 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>
| * pwm: twl: Reliably disable TWL6030 PWMsPaul Kocialkowski2016-09-051-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | pwm: Unexport children before chip removalDavid Hsu2016-09-052-0/+20
|/ | | | | | | | | | 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: 76abbdde2d95 ("pwm: Add sysfs interface") Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* Merge tag 'pwm/for-4.8-rc1' of ↵Linus Torvalds2016-08-0617-234/+1169
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * Merge branch 'for-4.8/drivers' into for-nextThierry Reding2016-07-2515-234/+1125
| |\
| | * pwm: Add ChromeOS EC PWM driverBrian Norris2016-07-253-0/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: atmel: Use of_device_get_match_data()Thierry Reding2016-07-111-9/+2
| | | | | | | | | | | | | | | | | | Use of_device_get_match_data() instead of an open-coded variant. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
| | * pwm: atmel: Fix checkpatch warningsThierry Reding2016-07-111-6/+7
| | | | | | | | | | | | | | | | | | | | | Avoid an overly long line by moving a comment around, and remove a use of else-after-return. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
| | * pwm: atmel: Fix disabling of PWM channelsGuillermo Rodriguez2016-07-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: rcar: Use ARCH_RENESASRyo Kodama2016-07-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace ARCH_RCAR_GEN{1,2} with ARCH_RENESAS in order to support R-Car Gen3. Signed-off-by: Ryo Kodama <ryo.kodama.vz@renesas.com> Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
| | * pwm: tegra: Add support for Tegra186Laxman Dewangan2016-07-111-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: tegra: Avoid overflow when calculating duty cycleHyong Bin Kim2016-07-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: tegra: Allow 100 % duty cycleVictor(Weiguo) Pan2016-07-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: tegra: Add support for reset controlRohith Seelaboyina2016-07-111-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: tegra: Rename mmio_base to regsThierry Reding2016-07-111-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: tegra: Remove useless paddingThierry Reding2016-07-111-4/+4
| | | | | | | | | | | | | | | | | | | | | Use single spaces to separate data type from field names in structure definitions. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
| | * pwm: tegra: Drop NUM_PWM macroThierry Reding2016-07-111-5/+3
| | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default valueSylvain Lemieux2016-07-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PWM_PIN_LEVEL bit is leave unset by the kernel PWM driver. Prior to commit 08ee77b5a5de27ad63c92262ebcb4efe0da93b58, 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>
| | * pwm: Add a driver for the STMPE PWMLinus Walleij2016-07-113-0/+327
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: rockchip: Add support for atomic updateBoris Brezillon2016-07-111-41/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: rockchip: Avoid glitches on already running PWMsBoris Brezillon2016-07-111-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: rockchip: Add support for hardware readoutBoris Brezillon2016-07-111-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: rockchip: Fix period and duty cycle approximationBoris Brezillon2016-07-111-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: Add support for Broadcom iProc PWM controllerYendapally Reddy Dhananjaya Reddy2016-07-113-0/+288
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: lpss: Move clk_rate check to ->probe()Andy Shevchenko2016-07-111-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: lpss: pci: Enable PWM module on Intel EdisonAndy Shevchenko2016-07-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: lpss: Prevent on_time_div overflow on lower frequenciesMika Westerberg2016-07-111-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: lpss: Fix base_unit calculation for PWM frequencyDan O'Donovan2016-07-111-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * pwm: pwm-ti*: Remove support for local clock gatingCooper Jr., Franklin2016-07-114-145/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 13:37:10 +0100