summaryrefslogtreecommitdiff
path: root/drivers/pwm
AgeCommit message (Collapse)Author
2020-02-07Merge tag 'v4.14.164' into 4.14-2.3.x-imxMarcel Ziswiler
This is the 4.14.164 stable release Conflicts: arch/arm/Kconfig.debug arch/arm/boot/dts/imx7s.dtsi arch/arm/mach-imx/cpuidle-imx6q.c arch/arm/mach-imx/cpuidle-imx6sx.c arch/arm64/kernel/cpu_errata.c arch/arm64/kvm/hyp/tlb.c drivers/crypto/caam/caamalg.c drivers/crypto/mxs-dcp.c drivers/dma/imx-sdma.c drivers/gpio/gpio-vf610.c drivers/gpu/drm/bridge/adv7511/adv7511_drv.c drivers/input/keyboard/imx_keypad.c drivers/input/keyboard/snvs_pwrkey.c drivers/mmc/core/block.c drivers/mmc/core/queue.h drivers/mmc/host/sdhci-esdhc-imx.c drivers/net/can/flexcan.c drivers/net/can/rx-offload.c drivers/net/ethernet/freescale/fec_main.c drivers/net/wireless/ath/ath10k/pci.c drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c drivers/pci/dwc/pci-imx6.c drivers/spi/spi-fsl-lpspi.c drivers/usb/dwc3/gadget.c include/net/tcp.h sound/soc/fsl/Kconfig sound/soc/fsl/fsl_esai.c
2019-12-05pwm: Clear chip_data in pwm_put()Uwe Kleine-König
commit e926b12c611c2095c7976e2ed31753ad6eb5ff1a upstream. After a PWM is disposed by its user the per chip data becomes invalid. Clear the data in common code instead of the device drivers to get consistent behaviour. Before this patch only three of nine drivers cleaned up here. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-05pwm: clps711x: Fix period calculationAlexander Shiyan
[ Upstream commit b0f17570b8203c22f139459c86cfbaa0311313ed ] Commit e39c0df1be5a ("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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-05pwm: bcm-iproc: Prevent unloading the driver module while in useUwe Kleine-König
[ Upstream commit 24906a41eecb73d51974ade0847c21e429beec60 ] The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-01pwm: lpss: Only set update bit if we are actually changing the settingsHans de Goede
[ Upstream commit 2153bbc12f77fb2203276befc0f0dddbfb023bb1 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-11pwm: stm32-lp: Add check in case requested period cannot be achievedFabrice Gasnier
[ Upstream commit c91e3234c6035baf5a79763cb4fcd5d23ce75c2b ] LPTimer can use a 32KHz clock for counting. It depends on clock tree configuration. In such a case, PWM output frequency range is limited. Although unlikely, nothing prevents user from requesting a PWM frequency above counting clock (32KHz for instance): - This causes (prd - 1) = 0xffff to be written in ARR register later in the apply() routine. This results in badly configured PWM period (and also duty_cycle). Add a check to report an error is such a case. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-15pwm: Fix deadlock warning when removing PWM devicePhong Hoang
[ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ] This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled. This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind [ 87.659974] ====================================================== [ 87.666149] WARNING: possible circular locking dependency detected [ 87.672327] 5.0.0 #7 Not tainted [ 87.675549] ------------------------------------------------------ [ 87.681723] bash/2986 is trying to acquire lock: [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0 [ 87.694528] [ 87.694528] but task is already holding lock: [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.707405] [ 87.707405] which lock already depends on the new lock. [ 87.707405] [ 87.715574] [ 87.715574] the existing dependency chain (in reverse order) is: [ 87.723048] [ 87.723048] -> #1 (pwm_lock){+.+.}: [ 87.728017] __mutex_lock+0x70/0x7e4 [ 87.732108] mutex_lock_nested+0x1c/0x24 [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74 [ 87.741940] pwm_request_from_chip+0x20/0x40 [ 87.746725] export_store+0x6c/0x1f4 [ 87.750820] dev_attr_store+0x18/0x28 [ 87.754998] sysfs_kf_write+0x54/0x64 [ 87.759175] kernfs_fop_write+0xe4/0x1e8 [ 87.763615] __vfs_write+0x40/0x184 [ 87.767619] vfs_write+0xa8/0x19c [ 87.771448] ksys_write+0x58/0xbc [ 87.775278] __arm64_sys_write+0x18/0x20 [ 87.779721] el0_svc_common+0xd0/0x124 [ 87.783986] el0_svc_compat_handler+0x1c/0x24 [ 87.788858] el0_svc_compat+0x8/0x18 [ 87.792947] [ 87.792947] -> #0 (kn->count#58){++++}: [ 87.798260] lock_acquire+0xc4/0x22c [ 87.802353] __kernfs_remove+0x258/0x2c4 [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0 [ 87.811836] remove_files.isra.1+0x38/0x78 [ 87.816447] sysfs_remove_group+0x48/0x98 [ 87.820971] sysfs_remove_groups+0x34/0x4c [ 87.825583] device_remove_attrs+0x6c/0x7c [ 87.830197] device_del+0x11c/0x33c [ 87.834201] device_unregister+0x14/0x2c [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c [ 87.843509] pwmchip_remove+0xf4/0x13c [ 87.847773] rcar_pwm_remove+0x28/0x34 [ 87.852039] platform_drv_remove+0x24/0x64 [ 87.856651] device_release_driver_internal+0x18c/0x21c [ 87.862391] device_release_driver+0x14/0x1c [ 87.867175] unbind_store+0xe0/0x124 [ 87.871265] drv_attr_store+0x20/0x30 [ 87.875442] sysfs_kf_write+0x54/0x64 [ 87.879618] kernfs_fop_write+0xe4/0x1e8 [ 87.884055] __vfs_write+0x40/0x184 [ 87.888057] vfs_write+0xa8/0x19c [ 87.891887] ksys_write+0x58/0xbc [ 87.895716] __arm64_sys_write+0x18/0x20 [ 87.900154] el0_svc_common+0xd0/0x124 [ 87.904417] el0_svc_compat_handler+0x1c/0x24 [ 87.909289] el0_svc_compat+0x8/0x18 [ 87.913378] [ 87.913378] other info that might help us debug this: [ 87.913378] [ 87.921374] Possible unsafe locking scenario: [ 87.921374] [ 87.927286] CPU0 CPU1 [ 87.931808] ---- ---- [ 87.936331] lock(pwm_lock); [ 87.939293] lock(kn->count#58); [ 87.945120] lock(pwm_lock); [ 87.950599] lock(kn->count#58); [ 87.953908] [ 87.953908] *** DEADLOCK *** [ 87.953908] [ 87.959821] 4 locks held by bash/2986: [ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c [ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8 [ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c [ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.995481] [ 87.995481] stack backtrace: [ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7 [ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT) [ 88.012791] Call trace: [ 88.015235] dump_backtrace+0x0/0x190 [ 88.018891] show_stack+0x14/0x1c [ 88.022204] dump_stack+0xb0/0xec [ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0 [ 88.030385] __lock_acquire+0x1318/0x1864 [ 88.034388] lock_acquire+0xc4/0x22c [ 88.037958] __kernfs_remove+0x258/0x2c4 [ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0 [ 88.046398] remove_files.isra.1+0x38/0x78 [ 88.050487] sysfs_remove_group+0x48/0x98 [ 88.054490] sysfs_remove_groups+0x34/0x4c [ 88.058580] device_remove_attrs+0x6c/0x7c [ 88.062671] device_del+0x11c/0x33c [ 88.066154] device_unregister+0x14/0x2c [ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c [ 88.074421] pwmchip_remove+0xf4/0x13c [ 88.078163] rcar_pwm_remove+0x28/0x34 [ 88.081906] platform_drv_remove+0x24/0x64 [ 88.085996] device_release_driver_internal+0x18c/0x21c [ 88.091215] device_release_driver+0x14/0x1c [ 88.095478] unbind_store+0xe0/0x124 [ 88.099048] drv_attr_store+0x20/0x30 [ 88.102704] sysfs_kf_write+0x54/0x64 [ 88.106359] kernfs_fop_write+0xe4/0x1e8 [ 88.110275] __vfs_write+0x40/0x184 [ 88.113757] vfs_write+0xa8/0x19c [ 88.117065] ksys_write+0x58/0xbc [ 88.120374] __arm64_sys_write+0x18/0x20 [ 88.124291] el0_svc_common+0xd0/0x124 [ 88.128034] el0_svc_compat_handler+0x1c/0x24 [ 88.132384] el0_svc_compat+0x8/0x18 The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9 ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either. We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around. This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed. Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again. So, this patch fixes them. Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com> [shimoda: revise the commit log and code] Fixes: 76abbdde2d95 ("pwm: Add sysfs interface") Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-15pwm: tiehrpwm: Update shadow register for disabling PWMsChristoph Vogtländer
[ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ] It must be made sure that immediate mode is not already set, when modifying shadow register value in ehrpwm_pwm_disable(). Otherwise modifications to the action-qualifier continuous S/W force register(AQSFRC) will be done in the active register. This may happen when both channels are being disabled. In this case, only the first channel state will be recorded as disabled in the shadow register. Later, when enabling the first channel again, the second channel would be enabled as well. Setting RLDCSF to zero, first, ensures that the shadow register is updated as desired. Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs") Signed-off-by: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com> [vigneshr@ti.com: Improve commit message] Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-15pwm: meson: Use the spin-lock only to protect register modificationsMartin Blumenstingl
[ Upstream commit f173747fffdf037c791405ab4f1ec0eb392fc48e ] Holding the spin-lock for all of the code in meson_pwm_apply() can result in a "BUG: scheduling while atomic". This can happen because clk_get_rate() (which is called from meson_pwm_calc()) may sleep. Only hold the spin-lock when modifying registers to solve this. The reason why we need a spin-lock in the driver is because the REG_MISC_AB register is shared between the two channels provided by one PWM controller. The only functions where REG_MISC_AB is modified are meson_pwm_enable() and meson_pwm_disable() so the register reads/writes in there need to be protected by the spin-lock. The original code also used the spin-lock to protect the values in struct meson_pwm_channel. This could be necessary if two consumers can use the same PWM channel. However, PWM core doesn't allow this so we don't need to protect the values in struct meson_pwm_channel with a lock. Fixes: 211ed630753d2f ("pwm: Add support for Meson PWM Controller") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-12MLK-19566 pwm: imx: Add NXP copyrightLiu Ying
This patch adds NXP copyright for the i.MX PWM driver. Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 59c94789cef003fe64ebeb68c7b209da0bf2de78)
2019-02-12MLK-18617-3 pwm: imx: Use 32k clock if it is suppliedLiu Ying
The PWM in i.MX8qxp MIPI subsystem needs to use the '32k' clock to work properly. This patch gets this clock in the PWM driver and uses it if it is supplied. Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit a343cc44ee9aa4be408c51b02176c8d0970a698d) Conflicts: drivers/pwm/pwm-imx.c
2019-02-12MLK-18627 pwm: imx: Add clk_ipg for imx8qmLeonard Crestez
As part of converting the imx pwm driver to an atomic apply function the code handling ipg clock was dropped. Add it back because on imx8qm it is indeed required. This fixes the same issue as imx_4.9.y commit ce627dbfd76e ("MLK-16973-4 pwm: imx: Use ipg and per clks in ->config, ->enable and ->disable") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reported-by: Marius Vlad <marius-cristian.vlad@nxp.com> Tested-by: Marius Vlad <marius-cristian.vlad@nxp.com> Reviewed-by: Liu Ying <victor.liu@nxp.com>
2019-02-12MLK-18379 pwm: fsl-tpm: updates to support i.mx8qmShenwei Wang
The TPM IP block on i.MX8QM has the following changes: 1) The IPG clock has to be enabled before access any registers 2) The extra bits in FTM_SC register are added to enable the PWM mode. This patch updates the driver according to these changes, and it can support the TPM PWM module on i.MX8QM. Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
2019-02-12MLK-18042-01 driver: pwm: fix pwm pre-scale div configBai Ping
In i.MX7ULP TPM PWM module, it has a pre-scale divider, this divider setting is missed, so fix it. Signed-off-by: Bai Ping <ping.bai@nxp.com> Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
2019-02-12MLK-15938-1 pwm: Kconfig: add imx pwm support for arm64 platformAnson Huang
Add ARM64 platform support for i.MX PWM driver. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2019-02-12MLK-14238-01 driver: pwm: Add tpm pwm driver supportBai Ping
Add TPM PWM driver support i.MX7ULP. Signed-off-by: Bai Ping <ping.bai@nxp.com> [Octavian: updated for 4.9 APIs] Signed-off-by: Octavian Purdila <octavian.purdila@nxp.com>
2018-09-15pwm: meson: Fix mux clock namesJerome Brunet
[ Upstream commit b96e9eb62841c519ba1db32d036628be3cdef91f ] 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: 36af66a79056 ("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> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-09pwm: tiehrpwm: Fix disabling of output of PWMsVignesh R
commit 38dabd91ff0bde33352ca3cc65ef515599b77a05 upstream. 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: 19891b20e7c2 ("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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-09pwm: tiehrpwm: Don't use emulation mode bits to control PWM outputVignesh R
commit aa49d628f6e016bcec8c6f8e704b9b18ee697329 upstream. 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: 19891b20e7c2 ("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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-03pwm: lpss: platform: Save/restore the ctrl register over a suspend/resumeHans de Goede
commit 1d375b58c12f08d8570b30b865def4734517f04f upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-24pwm: rcar: Fix a condition to prevent mismatch value setting to dutyRyo Kodama
commit 6225f9c64b40bc8a22503e9cda70f55d7a9dd3c6 upstream. 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: ed6c1476bf7f ("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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-19pwm: stmpe: Fix wrong register offset for hwpwm=2 caseAxel Lin
[ Upstream commit 8472b529e113e0863ea064fdee51bf73c3f86fd6 ] Fix trivial copy/paste bug. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: ef1f09eca74a ("pwm: Add a driver for the STMPE PWM") Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman
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>
2017-09-11Merge tag 'pwm/for-4.14-rc1' of ↵Linus Torvalds
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 ...
2017-09-05Merge branches 'ib-mfd-arm-i2c-4.14', 'ib-mfd-arm-usb-video-4.14', ↵Lee Jones
'ib-mfd-hwmon-4.14', 'ib-mfd-iio-pwm-4.14', 'ib-mfd-input-rtc-4.14', 'ib-mfd-many-4.14' and 'ib-mfd-pinctrl-regulator-4.14' into ibs-for-mfd-merged
2017-09-04pwm: Add STM32 LPTimer PWM driverFabrice Gasnier
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>
2017-09-04mfd: twl: Move header file out of I2C realmWolfram Sang
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>
2017-08-21pwm: pwm-samsung: fix suspend/resume supportBartlomiej Zolnierkiewicz
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>
2017-08-21pwm: samsung: Remove redundant checks from pwm_samsung_config()Bartlomiej Zolnierkiewicz
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>
2017-08-21pwm: mediatek: Disable clock on PWM configuration failureZhi Mao
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>
2017-08-21pwm: mediatek: Fix clock control issueZhi Mao
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>
2017-08-21pwm: mediatek: Fix PWM source clock selectionZhi Mao
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>
2017-08-21pwm: mediatek: Fix Kconfig descriptionZhi Mao
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>
2017-08-21pwm: tegra: Explicitly request exclusive reset controlPhilipp Zabel
Commit a53e35db70d1 ("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>
2017-08-21pwm: hibvt: Explicitly request exclusive reset controlPhilipp Zabel
Commit a53e35db70d1 ("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>
2017-08-21pwm: tiehrpwm: Set driver data before runtime PM enableThierry Reding
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>
2017-08-21pwm: tiehrpwm: Miscellaneous coding style fixupsThierry Reding
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>
2017-08-21pwm: tiecap: Set driver data before runtime PM enableThierry Reding
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>
2017-08-21pwm: tiecap: Miscellaneous coding style fixupsThierry Reding
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>
2017-08-21pwm: tiehrpwm: fix clock imbalance in probe error pathJohan Hovold
Make sure to unprepare the clock before returning on late probe errors. Fixes: b388f15fd14c ("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>
2017-08-21pwm: tiehrpwm: Fix runtime PM imbalance at unbindJohan Hovold
Remove unbalanced RPM put at driver unbind which resulted in a negative usage count. Fixes: 19891b20e7c2 ("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>
2017-08-21pwm: Kconfig: Enable pwm-tiecap to be built for KeystoneVignesh R
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>
2017-08-21pwm: Add ZTE ZX PWM device driverShawn Guo
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>
2017-08-21pwm: bcm2835: Support for polarity setting via DTStefan Wahren
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>
2017-08-18pwm: rockchip: Add rk3328 supportDavid Wu
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>
2017-08-18pwm: rockchip: Use same PWM ops for each IPDavid Wu
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>
2017-08-18pwm: rockchip: Move the configuration of polarityDavid Wu
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>
2017-08-18pwm: rockchip: Use pwm_apply() instead of pwm_enable()David Wu
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>
2017-08-18pwm: rockchip: Remove the judge from return value of pwm_config()David Wu
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>
2017-08-18pwm: rockchip: Add APB and function both clocks supportDavid Wu
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>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-01 10:32:39 +0000