summaryrefslogtreecommitdiffstats
path: root/drivers/pwm
AgeCommit message (Collapse)AuthorFilesLines
2020-10-24Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-1/+1
Pull ARM SoC platform updates from Olof Johansson: "SoC changes, a substantial part of this is cleanup of some of the older platforms that used to have a bunch of board files. In particular: - Remove non-DT i.MX platforms that haven't seen activity in years, it's time to remove them. - A bunch of cleanup and removal of platform data for TI/OMAP platforms, moving over to genpd for power/reset control (yay!) - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them closer to multiplatform support (not quite there yet, but getting close). There are a few other changes too, smaller fixlets, etc. For new platform support, the primary ones are: - New SoC: Hisilicon SD5203, ARM926EJ-S platform. - Cpufreq support for i.MX7ULP" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits) ARM: mstar: Select MStar intc ARM: stm32: Replace HTTP links with HTTPS ones ARM: debug: add UART early console support for SD5203 ARM: hisi: add support for SD5203 SoC ARM: omap3: enable off mode automatically clk: imx: imx35: Remove mx35_clocks_init() clk: imx: imx31: Remove mx31_clocks_init() clk: imx: imx27: Remove mx27_clocks_init() ARM: imx: Remove unused definitions ARM: imx35: Retrieve the IIM base address from devicetree ARM: imx3: Retrieve the AVIC base address from devicetree ARM: imx3: Retrieve the CCM base address from devicetree ARM: imx31: Retrieve the IIM base address from devicetree ARM: imx27: Retrieve the CCM base address from devicetree ARM: imx27: Retrieve the SYSCTRL base address from devicetree ARM: s3c64xx: bring back notes from removed debug-macro.S ARM: s3c24xx: fix Wunused-variable warning on !MMU ARM: samsung: fix PM debug build with DEBUG_LL but !MMU MAINTAINERS: mark linux-samsung-soc list non-moderated ARM: imx: Remove remnant board file support pieces ...
2020-10-23Merge tag 'tag-chrome-platform-for-v5.10' of ↵Linus Torvalds1-20/+17
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform updates from Benson Leung: "cros-ec: - Error code cleanup across cros-ec by Guenter - Remove cros_ec_cmd_xfer in favor of cros_ec_cmd_xfer_status cros_ec_typec: - Landed initial USB4 support in typec connector class driver for cros_ec - Role switch bugfix on disconnect, and reordering configuration steps cros_ec_lightbar: - Fix buffer outsize and result for get_lightbar_version misc: - Remove config MFD_CROS_EC, now that transition from MFD is complete - Enable KEY_LEFTMETA in new location on arm based cros-ec-keyboard keymap" * tag 'tag-chrome-platform-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA platform/chrome: Use kobj_to_dev() instead of container_of() platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer() platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites platform/chrome: Kconfig: Remove the transitional MFD_CROS_EC config platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command platform/chrome: cros_ec_trace: Add fields to command traces platform/chrome: cros_ec_typec: Re-order connector configuration steps platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role() platform/chrome: cros_ec_typec: USB4 support pwm: cros-ec: Simplify EC error handling platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status platform/chrome: cros_ec_sysfs: Report range of error codes from EC cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code
2020-10-22Merge tag 'pwm/for-5.10-rc1' of ↵Linus Torvalds10-90/+64
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This release cycle's updates are mostly cleanup and some minor fixes" * tag 'pwm/for-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: dt-bindings: pwm: renesas,pwm-rcar: Add r8a7742 support dt-bindings: pwm: renesas,tpu-pwm: Document r8a7742 support pwm: Allow store 64-bit duty cycle from sysfs interface pwm: img: Fix null pointer access in probe pwm: pca9685: Disable unused alternative addresses pwm: pca9685: Use BIT() macro instead of shift pwm: pca9685: Make comments more consistent pwm: sun4i: Simplify with dev_err_probe() pwm: sprd: Simplify with dev_err_probe() pwm: sifive: Simplify with dev_err_probe() pwm: rockchip: Simplify with dev_err_probe() pwm: jz4740: Simplify with dev_err_probe() pwm: bcm2835: Simplify with dev_err_probe() pwm: Convert to use DEFINE_SEQ_ATTRIBUTE macro pwm: rockchip: Keep enabled PWMs running while probing dt-bindings: pwm: renesas,pwm-rcar: Add r8a774e1 support
2020-10-15Merge tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drmLinus Torvalds4-89/+128
Pull drm updates from Dave Airlie: "Not a major amount of change, the i915 trees got split into display and gt trees to better facilitate higher level review, and there's a major refactoring of i915 GEM locking to use more core kernel concepts (like ww-mutexes). msm gets per-process pagetables, older AMD SI cards get DC support, nouveau got a bump in displayport support with common code extraction from i915. Outside of drm this contains a couple of patches for hexint moduleparams which you've acked, and a virtio common code tree that you should also get via it's regular path. New driver: - Cadence MHDP8546 DisplayPort bridge driver core: - cross-driver scatterlist cleanups - devm_drm conversions - remove drm_dev_init - devm_drm_dev_alloc conversion ttm: - lots of refactoring and cleanups bridges: - chained bridge support in more drivers panel: - misc new panels scheduler: - cleanup priority levels displayport: - refactor i915 code into helpers for nouveau i915: - split into display and GT trees - WW locking refactoring in GEM - execbuf2 extension mechanism - syncobj timeline support - GEN 12 HOBL display powersaving - Rocket Lake display additions - Disable FBC on Tigerlake - Tigerlake Type-C + DP improvements - Hotplug interrupt refactoring amdgpu: - Sienna Cichlid updates - Navy Flounder updates - DCE6 (SI) support for DC - Plane rotation enabled - TMZ state info ioctl - PCIe DPC recovery support - DC interrupt handling refactor - OLED panel fixes amdkfd: - add SMI events for thermal throttling - SMI interface events ioctl update - process eviction counters radeon: - move to dma_ for allocations - expose sclk via sysfs msm: - DSI support for sm8150/sm8250 - per-process GPU pagetable support - Displayport support mediatek: - move HDMI phy driver to PHY - convert mtk-dpi to bridge API - disable mt2701 tmds tegra: - bridge support exynos: - misc cleanups vc4: - dual display cleanups ast: - cleanups gma500: - conversion to GPIOd API hisilicon: - misc reworks ingenic: - clock handling and format improvements mcde: - DSI support mgag200: - desktop g200 support mxsfb: - i.MX7 + i.MX8M - alpha plane support panfrost: - devfreq support - amlogic SoC support ps8640: - EDID from eDP retrieval tidss: - AM65xx YUV workaround virtio: - virtio-gpu exported resources rcar-du: - R8A7742, R8A774E1 and R8A77961 support - YUV planar format fixes - non-visible plane handling - VSP device reference count fix - Kconfig fix to avoid displaying disabled options in .config" * tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drm: (1494 commits) drm/ingenic: Fix bad revert drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init drm/amdgpu: Remove warning for virtual_display drm/amdgpu: kfd_initialized can be static drm/amd/pm: setup APU dpm clock table in SMU HW initialization drm/amdgpu: prevent spurious warning drm/amdgpu/swsmu: fix ARC build errors drm/amd/display: Fix OPTC_DATA_FORMAT programming drm/amd/display: Don't allow pstate if no support in blank drm/panfrost: increase readl_relaxed_poll_timeout values MAINTAINERS: Update entry for st7703 driver after the rename Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached" drm/amd/display: HDMI remote sink need mode validation for Linux drm/amd/display: Change to correct unit on audio rate drm/amd/display: Avoid set zero in the requested clk drm/amdgpu: align frag_end to covered address space drm/amdgpu: fix NULL pointer dereference for Renoir drm/vmwgfx: fix regression in thp code due to ttm init refactor. drm/amdgpu/swsmu: add interrupt work handler for smu11 parts drm/amdgpu/swsmu: add interrupt work function ...
2020-09-24pwm: Allow store 64-bit duty cycle from sysfs interfaceJarkko Nikula1-2/+2
PWM core was converted to u64 by the commit a9d887dc1c60 ("pwm: Convert period and duty cycle to u64") but did not change the duty_cycle_store() so it will error out if trying to pass a numeric string bigger than 2^32-1. Fix this by using u64 and kstrtou64() in duty_cycle_store(). Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Guru Das Srinagesh <gurus@codeaurora.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: img: Fix null pointer access in probeHauke Mehrtens1-1/+2
dev_get_drvdata() is called in img_pwm_runtime_resume() before the driver data is set. When pm_runtime_enabled() returns false in img_pwm_probe() it calls img_pwm_runtime_resume() which results in a null pointer access. This patch fixes the problem by setting the driver data earlier in the img_pwm_probe() function. This crash was seen when booting the Imagination Technologies Creator Ci40 (Marduk) with kernel 5.4 in OpenWrt. Fixes: e690ae526216 ("pwm: img: Add runtime PM") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: pca9685: Disable unused alternative addressesDavid Jander1-7/+16
The PCA9685 supports listening to 1 or more alternative I2C chip addresses for some special features that this driver does not support. By default the LED ALLCALL address is active (default 0x70), which causes this chip to respond to address 0x70 in addition to its main address (0x41). This is not desireable if there is another device on the same bus that uses this address (like a TMP103 for example). Since this feature is not supported by this driver, it is best to disable these addresses in the chip to avoid unsuspected bus collisions. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: pca9685: Use BIT() macro instead of shiftDavid Jander1-4/+4
Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: pca9685: Make comments more consistentDavid Jander1-7/+7
Make all explanatory comments start with an uppercase char. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: sun4i: Simplify with dev_err_probe()Krzysztof Kozlowski1-24/+12
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: sprd: Simplify with dev_err_probe()Krzysztof Kozlowski1-5/+2
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: sifive: Simplify with dev_err_probe()Krzysztof Kozlowski1-5/+3
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: rockchip: Simplify with dev_err_probe()Krzysztof Kozlowski1-7/+3
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: jz4740: Simplify with dev_err_probe()Krzysztof Kozlowski1-6/+3
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: bcm2835: Simplify with dev_err_probe()Krzysztof Kozlowski1-7/+3
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: Convert to use DEFINE_SEQ_ATTRIBUTE macroLiu Shixin1-14/+3
Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code. Signed-off-by: Liu Shixin <liushixin2@huawei.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-24pwm: rockchip: Keep enabled PWMs running while probingSimon South1-1/+4
Following commit cfc4c189bc70 ("pwm: Read initial hardware state at request time") the Rockchip PWM driver can no longer assume a device's pwm_state structure has been populated after a call to pwmchip_add(). Consequently, the test in rockchip_pwm_probe() intended to prevent the driver from stopping PWM devices already enabled by the bootloader no longer functions reliably and this can lead to the kernel hanging during startup, particularly on devices like the Pinebook Pro that use a PWM-controlled backlight for their display. Avoid this by querying the device directly at probe time to determine whether or not it is enabled. Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time") Signed-off-by: Simon South <simon@simonsouth.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-09-17pwm: Add support for sl28cpld PWM controllerMichael Walle3-0/+281
Add support for the PWM controller of the sl28cpld board management controller. This is part of a multi-function device driver. The controller has one PWM channel and can just generate four distinct frequencies. Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-09-11Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi18-193/+39
Sync drm-intel-gt-next here so we can have an unified fixes flow. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-09-06pwm: crc: Implement get_state() methodHans de Goede1-0/+31
Implement the pwm_ops.get_state() method to complete the support for the new atomic PWM API. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-14-hdegoede@redhat.com
2020-09-06pwm: crc: Implement apply() method to support the new atomic PWM APIHans de Goede1-35/+54
Replace the enable, disable and config pwm_ops with an apply op, to support the new atomic PWM API. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-13-hdegoede@redhat.com
2020-09-06pwm: crc: Enable/disable PWM output on enable/disableHans de Goede1-0/+4
The pwm-crc code is using 2 different enable bits: 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) 2. bit 0 of the BACKLIGHT_EN register So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM, this commit makes crc_pwm_disable() clear it on disable and makes crc_pwm_enable() set it again on re-enable. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-12-hdegoede@redhat.com
2020-09-06pwm: crc: Fix period changes not having any effectHans de Goede1-5/+2
The pwm-crc code is using 2 different enable bits: 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) 2. bit 0 of the BACKLIGHT_EN register The BACKLIGHT_EN register at address 0x51 really controls a separate output-only GPIO which is earmarked to be used as output connected to the backlight-enable pin for LCD panels, this GPO is part of the PMIC's "Display Panel Control Block." . This pin should probably be moved over to a GPIO provider driver (and consumers modified accordingly), but that is something for an(other) patch. Enabling / disabling the actual PWM output is controlled by the PWM_OUTPUT_ENABLE bit of the PWM0_CLK_DIV register. As the comment in the old code already indicates we must disable the PWM before we can change the clock divider. But the crc_pwm_disable() and crc_pwm_enable() calls the old code make for this only change the BACKLIGHT_EN register; and the value of that register does not matter for changing the period / the divider. What does matter is that the PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written. This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead when changing the period, so that period changes actually work. Note this fix will cause a significant behavior change on some devices using the CRC PWM output to drive their backlight. Before the PWM would always run with the output frequency configured by the BIOS at boot, now the period time specified by the i915 driver will actually be honored. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-11-hdegoede@redhat.com
2020-09-06pwm: crc: Fix off-by-one error in the clock-divider calculationsHans de Goede1-3/+14
The CRC PWM controller has a clock-divider which divides the clock with a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx defines, this range maps to a register value of 0-127. So after calculating the clock-divider we must subtract 1 to get the register value, unless the requested frequency was so high that the calculation has already resulted in a (rounded) divider value of 0. Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which corresponds to the max. divider value of 128 could have resulted in a bug where the code would use 128 as divider-register value which would have resulted in an actual divider value of 0 (and the enable bit being set). A rounding error stopped this bug from actually happen. This same rounding error means that after the subtraction of 1 it is impossible to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow setting a divider of 128 (register-value 127). Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-10-hdegoede@redhat.com
2020-09-06pwm: crc: Fix period / duty_cycle times being off by a factor of 256Hans de Goede1-3/+3
While looking into adding atomic-pwm support to the pwm-crc driver I noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and there is a clock-divider which divides this with a value between 1-128, and there are 256 duty-cycle steps. The pwm-crc code before this commit assumed that a clock-divider setting of 1 means that the PWM output is running at 6 MHZ, if that is true, where do these 256 duty-cycle steps come from? This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that seems unlikely for a PMIC which is using a silicon process optimized for power-switching transistors. It is way more likely that there is an 8 bit counter for the duty cycle which acts as an extra fixed divider wrt the PWM output frequency. The main user of the pwm-crc driver is the i915 GPU driver which uses it for backlight control. Lets compare the PWM register values set by the video-BIOS (the GOP), assuming the extra fixed divider is present versus the PWM frequency specified in the Video-BIOS-Tables: Device: PWM Hz set by BIOS PWM Hz specified in VBT Asus T100TA 200 200 Asus T100HA 200 200 Lenovo Miix 2 8 23437 20000 Toshiba WT8-A 23437 20000 So as we can see if we assume the extra division by 256 then the register values set by the GOP are an exact match for the VBT values, where as otherwise the values would be of by a factor of 256. This commit fixes the period / duty_cycle calculations to take the extra division by 256 into account. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-9-hdegoede@redhat.com
2020-09-06pwm: lpss: Remove suspend/resume handlersHans de Goede3-28/+0
PWM controller drivers should not restore the PWM state on resume. The convention is that PWM consumers do this by calling pwm_apply_state(), so that it can be done at the exact moment when the consumer needs the state to be stored, avoiding e.g. backlight flickering. The only in kernel consumers of the pwm-lpss code, the i915 driver and the pwm-class sysfs interface code both correctly restore the state on resume, so there is no need to do this in the pwm-lpss code. More-over the removed resume handler is buggy, since it blindly restores the ctrl-register contents without setting the update bit, which is necessary to get the controller to actually use/apply the restored base-unit and on-time-div values. Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-8-hdegoede@redhat.com
2020-09-06pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware stateHans de Goede1-12/+9
Before this commit pwm_lpss_apply() was assuming 2 pre-conditions were met by the existing hardware state: 1. That the base-unit and on-time-div read back from the control register are those actually in use, so that it can skip setting the update bit if the read-back value matches the desired values. 2. That the controller is enabled when the cached pwm_state.enabled says that the controller is enabled. As the long history of fixes for subtle (often suspend/resume) lpss-pwm issues shows, these assumptions are not necessary always true. 1. Specifically is not true on some (*) Cherry Trail devices with a nasty GFX0._PS3 method which: a. saves the ctrl reg value. b. sets the base-unit to 0 and writes the update bit to apply/commit c. restores the original ctrl value without setting the update bit, so that the 0 base-unit value is still in use. 2. Assumption 2. currently is true, but only because of the code which saves/restores the state on suspend/resume. By convention restoring the PWM state should be done by the PWM consumer and the presence of this code in the pmw-lpss driver is a bug. Therefor the save/restore code will be dropped in the next patch in this series, after which this assumption also is no longer true. This commit changes the pwm_lpss_apply() to not make any assumptions about the state the hardware is in. Instead it makes pwm_lpss_apply() always fully program the PWM controller, making it much less fragile. *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models and various Medion models. Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-7-hdegoede@redhat.com
2020-09-06pwm: lpss: Add pwm_lpss_prepare_enable() helperHans de Goede1-19/+26
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a runtime-pm reference; and then on any errors it needs to release it again. This leads to somewhat hard to read code. This commit introduces a new pwm_lpss_prepare_enable() helper and moves all the steps necessary for the not-enabled -> enabled transition there, so that we can error check the entire transition in a single place and only have one pm_runtime_put() on failure call site. While working on this I noticed that the enabled -> enabled (update settings) path was quite similar, so I've added an enable parameter to the new pwm_lpss_prepare_enable() helper, which allows using it in that path too. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-6-hdegoede@redhat.com
2020-09-06pwm: lpss: Add range limit check for the base_unit register valueHans de Goede1-1/+2
When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0. But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal. When the user requestes a low enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value which is bigger then base_unit_range - 1. Currently the codes for this deals with this by applying a mask: base_unit &= (base_unit_range - 1); But this means that we let the value overflow the range, we throw away the higher bits and store whatever value is left in the lower bits into the register leading to a random output frequency, rather then clamping the output frequency to the highest frequency which the hardware can do. This commit fixes both issues by clamping the base_unit value to be between 1 and (base_unit_range - 1). Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com
2020-09-06pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()Hans de Goede1-3/+3
According to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. So assuming e.g. a 16 bit counter this means that if base_unit is set to 1, after 65535 input clock-cycles the counter has been increased from 0 to 65535 and it will overflow on the next cycle, so it will overflow after every 65536 clock cycles and thus the calculations done in pwm_lpss_prepare() should use 65536 and not 65535. This commit fixes this. Note this also aligns the calculations in pwm_lpss_prepare() with those in pwm_lpss_get_state(). Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit"). The next patch in this series really fixes the potential overflow of the base_unit value. Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com
2020-08-24pwm: cros-ec: Simplify EC error handlingGuenter Roeck1-22/+4
With enhanced error reporting from cros_ec_cmd_xfer_status() in place, we can fully use it and no longer rely on EC error codes. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-08-24pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_statusGuenter Roeck1-7/+22
Since commit c5cd2b47b203 ("platform/chrome: cros_ec_proto: Report command not supported") we can no longer assume that cros_ec_cmd_xfer_status() reports -EPROTO for all errors returned by the EC itself. A follow-up patch will change cros_ec_cmd_xfer_status() to report additional errors reported by the EC as distinguished Linux error codes. Handle this change by no longer assuming that only -EPROTO is used to report all errors returned by the EC itself. Instead, support both the old and the new error codes. Add a comment describing cros_ec_num_pwms() to explain its functionality. Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org> Cc: Prashant Malani <pmalani@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-08-19ARM: s5pv210: don't imply CONFIG_PLAT_SAMSUNGArnd Bergmann1-1/+1
The plat-samsung directory and mach-s5pv210 can be build completely independently, so split the two Kconfig symbols CONFIG_PLAT_SAMSUNG and CONFIG_ARCH_S5PV210. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-18-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-08-14Merge tag 'pwm/for-5.9-rc1' of ↵Linus Torvalds15-33/+39
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "The majority of this batch is conversion of the PWM period and duty cycle to 64-bit unsigned integers, which is required so that some types of hardware can generate the full range of signals that they're capable of. The remainder is mostly minor fixes and cleanups" * tag 'pwm/for-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: bcm-iproc: handle clk_get_rate() return pwm: Replace HTTP links with HTTPS ones pwm: omap-dmtimer: Repair pwm_omap_dmtimer_chip's broken kerneldoc header pwm: mediatek: Provide missing kerneldoc description for 'soc' arg pwm: bcm-kona: Remove impossible comparison when validating duty cycle pwm: bcm-iproc: Remove impossible comparison when validating duty cycle pwm: iqs620a: Use lowercase hexadecimal literals for consistency pwm: Convert period and duty cycle to u64 clk: pwm: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function pwm: sun4i: Use nsecs_to_jiffies to avoid a division pwm: sifive: Use 64-bit division macro pwm: iqs620a: Use 64-bit division pwm: imx27: Use 64-bit division macro pwm: imx-tpm: Use 64-bit division macro pwm: clps711x: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro drm/i915: Use 64-bit division macro
2020-07-30pwm: bcm-iproc: handle clk_get_rate() returnRayagonda Kokatanur1-2/+7
Handle clk_get_rate() returning 0 to avoid possible division by zero. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-07-30pwm: Replace HTTP links with HTTPS onesAlexander A. Klimov3-3/+3
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-07-30pwm: omap-dmtimer: Repair pwm_omap_dmtimer_chip's broken kerneldoc headerLee Jones1-1/+1
Argument descriptions must be prepended with a '@' to be understood by the kerneldoc tooling/parsers/validators. Fixes the following W=1 warning: drivers/pwm/pwm-omap-dmtimer.c:70: warning: Function parameter or member 'dm_timer_pdev' not described in 'pwm_omap_dmtimer_chip' Cc: Tony Lindgren <tony@atomide.com> Cc: Joachim Eastwood <manabian@gmail.com> Cc: NeilBrown <neilb@suse.de> Cc: Grant Erickson <marathon96@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-07-30pwm: mediatek: Provide missing kerneldoc description for 'soc' argLee Jones1-0/+1
Kerneldoc syntax is used, but not complete. Descriptions are required for all arguments. Fixes the following W=1 build warning: drivers/pwm/pwm-mediatek.c:57: warning: Function parameter or member 'soc' not described in 'pwm_mediatek_chip' Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: John Crispin <blogic@openwrt.org> Cc: Zhi Mao <zhi.mao@mediatek.com> Cc: linux-pwm@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-07-30pwm: bcm-kona: Remove impossible comparison when validating duty cycleLee Jones1-1/+1
'dc' here is an unsigned long, thus checking for <0 will always evaluate to false. Fixes the following W=1 warning: drivers/pwm/pwm-bcm-kona.c:141:35: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-pwm@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-07-30pwm: bcm-iproc: Remove impossible comparison when validating duty cycleLee Jones1-2/+1
'duty' here is an unsigned int, thus checking for <0 will always evaluate to false. Fixes the following W=1 warning: drivers/pwm/pwm-bcm-iproc.c:147:12: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-pwm@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-07-01pwm: remove pwm-puv3 driverMike Rapoport3-160/+0
The unicore32 port is removed from the kernel. There is no point to keep stale PWM driver for this architecture. Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net>
2020-06-17pwm: iqs620a: Use lowercase hexadecimal literals for consistencyThierry Reding1-4/+4
Other drivers use lowercase hexadecimal literals, so convert the IQS620a driver to do the same for consistency. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-17pwm: Convert period and duty cycle to u64Guru Das Srinagesh3-12/+12
Because period and duty cycle are defined as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Change their definitions to u64 in the structs of the PWM framework so that higher durations may be set. Also use the right format specifiers in debug prints in both core.c, pwm-stm32-lp.c as well as video/fbdev/ssd1307fb.c. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-17pwm: sun4i: Use nsecs_to_jiffies to avoid a divisionGuru Das Srinagesh1-1/+1
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using nsecs_to_jiffies() which does away with the need for a division operation. Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-17pwm: sifive: Use 64-bit division macroGuru Das Srinagesh1-1/+1
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to handle a 64-bit divisor. Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-17pwm: iqs620a: Use 64-bit divisionThierry Reding1-3/+4
The PWM framework is going to change the PWM period and duty cycles to be 64-bit unsigned integers. To avoid build errors on platforms that do not natively support 64-bit division, use explicity 64-bit division. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-16pwm: imx27: Use 64-bit division macroGuru Das Srinagesh1-1/+1
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend. Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-16pwm: imx-tpm: Use 64-bit division macroGuru Das Srinagesh1-1/+1
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to handle a 64-bit divisor. Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-16pwm: clps711x: Use 64-bit division macroGuru Das Srinagesh1-1/+1
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to handle a 64-bit divisor. Cc: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-06-04pwm: Add missing "CONFIG_" prefixKees Cook1-1/+1
The IS_ENABLED() use was missing the CONFIG_ prefix which would have lead to skipping this code. Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>