summaryrefslogtreecommitdiffstats
path: root/drivers/pwm
AgeCommit message (Collapse)AuthorFilesLines
2019-09-27Merge tag 'pwm/for-5.4-rc1' of ↵Linus Torvalds26-233/+528
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "Besides one new driver being added for the PWM controller found in various Spreadtrum SoCs, this series of changes brings a slew of, mostly minor, fixes and cleanups for existing drivers, as well as some enhancements to the core code. Lastly, Uwe is added to the PWM subsystem entry of the MAINTAINERS file, making official his role as a reviewer" * tag 'pwm/for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (34 commits) MAINTAINERS: Add myself as reviewer for the PWM subsystem MAINTAINERS: Add patchwork link for PWM entry MAINTAINERS: Add a selection of PWM related keywords to the PWM entry pwm: mediatek: Add MT7629 compatible string dt-bindings: pwm: Update bindings for MT7629 SoC pwm: mediatek: Update license and switch to SPDX tag pwm: mediatek: Use pwm_mediatek as common prefix pwm: mediatek: Allocate the clks array dynamically pwm: mediatek: Remove the has_clks field pwm: mediatek: Drop the check for of_device_get_match_data() pwm: atmel: Consolidate driver data initialization pwm: atmel: Remove unneeded check for match data pwm: atmel: Remove platform_device_id and use only dt bindings pwm: stm32-lp: Add check in case requested period cannot be achieved pwm: Ensure pwm_apply_state() doesn't modify the state argument pwm: fsl-ftm: Don't update the state for the caller of pwm_apply_state() pwm: sun4i: Don't update the state for the caller of pwm_apply_state() pwm: rockchip: Don't update the state for the caller of pwm_apply_state() pwm: Let pwm_get_state() return the last implemented state pwm: Introduce local struct pwm_chip in pwm_apply_state() ...
2019-09-26pwm: mediatek: Add MT7629 compatible stringSam Shih1-0/+6
This adds pwm support for MT7629, and separate mt7629 compatible string from mt7622 Signed-off-by: Sam Shih <sam.shih@mediatek.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-25pwm: mediatek: Update license and switch to SPDX tagSam Shih1-5/+3
Add SPDX identifiers to pwm-mediatek.c. Update MODULE_LICENSE to correctly reflect the GNU General Public License v2.0. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sam Shih <sam.shih@mediatek.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-25pwm: mediatek: Use pwm_mediatek as common prefixSam Shih1-57/+60
Use pwm_mediatek as common prefix to match the filename. No functional change intended. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sam Shih <sam.shih@mediatek.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-25pwm: mediatek: Allocate the clks array dynamicallySam Shih1-35/+44
Instead of using fixed size of arrays, allocate the memory for them based on the number of PWMs specified for each SoC generation. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sam Shih <sam.shih@mediatek.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-25pwm: mediatek: Remove the has_clks fieldSam Shih1-13/+1
We can use fixed clocks to repair mt7628 PWM during configure from userspace. The SoC is legacy MIPS and has no complex clock tree. Because we can get the clock frequency for period calculation from fixed clocks specified in DT, we can remove the has_clock field, and directly use devm_clk_get() and clk_get_rate(). Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sam Shih <sam.shih@mediatek.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: mediatek: Drop the check for of_device_get_match_data()Sam Shih1-7/+3
This patch drop the check for of_device_get_match_data. Due to the only way call driver probe is compatible match. The data pointer which points to the SoC specify data is directly set by driver, and it should not be NULL in our case. We can safety remove the check for the result of of_device_get_match_data(). Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sam Shih <sam.shih@mediatek.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: atmel: Consolidate driver data initializationThierry Reding1-4/+2
This helps readability by separating the driver-specific bits from the PWM framework bits. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: atmel: Remove unneeded check for match dataThierry Reding1-6/+2
Since the driver is now exclusively DT, it only binds if it finds a match in the of_device_id table. But in that case the associated data can never be NULL, so drop the unnecessary check. While at it, drop the extra local variable and store the pointer to this per-SoC data in the driver data directly. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: atmel: Remove platform_device_id and use only dt bindingsKamel Bouhara2-33/+4
Since commit 26202873bb51 ("avr32: remove support for AVR32 architecture") there is no more user of platform_device_id and we should only use dt bindings Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: stm32-lp: Add check in case requested period cannot be achievedFabrice Gasnier1-0/+6
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>
2019-09-21pwm: Ensure pwm_apply_state() doesn't modify the state argumentUwe Kleine-König20-29/+27
It is surprising for a PWM consumer when the variable holding the requested state is modified by pwm_apply_state(). Consider for example a driver doing: #define PERIOD 5000000 #define DUTY_LITTLE 10 ... struct pwm_state state = { .period = PERIOD, .duty_cycle = DUTY_LITTLE, .polarity = PWM_POLARITY_NORMAL, .enabled = true, }; pwm_apply_state(mypwm, &state); ... state.duty_cycle = PERIOD / 2; pwm_apply_state(mypwm, &state); For sure the second call to pwm_apply_state() should still have state.period = PERIOD and not something the hardware driver chose for a reason that doesn't necessarily apply to the second call. So declare the state argument as a pointer to a const type and adapt all drivers' .apply callbacks. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: fsl-ftm: Don't update the state for the caller of pwm_apply_state()Uwe Kleine-König1-4/+0
The pwm-fsl-ftm driver is one of only three PWM drivers which updates the state for the caller of pwm_apply_state(). This might have surprising results if the caller reuses the values expecting them to still represent the same state. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: sun4i: Don't update the state for the caller of pwm_apply_state()Uwe Kleine-König1-6/+0
The pwm-sun4i driver is one of only three PWM drivers which updates the state for the caller of pwm_apply_state(). This might have surprising results if the caller reuses the values expecting them to still represent the same state. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: rockchip: Don't update the state for the caller of pwm_apply_state()Uwe Kleine-König1-6/+0
The pwm-rockchip driver is one of only three PWM drivers which updates the state for the caller of pwm_apply_state(). This might have surprising results if the caller reuses the values expecting them to still represent the same state. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: Let pwm_get_state() return the last implemented stateUwe Kleine-König1-1/+8
When pwm_apply_state() is called the lowlevel driver usually has to apply some rounding because the hardware doesn't support nanosecond resolution. So let pwm_get_state() return the actually implemented state instead of the last applied one if possible. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: Introduce local struct pwm_chip in pwm_apply_state()Uwe Kleine-König1-11/+14
pwm->chip is dereferenced several times in the pwm_apply_state() function. Introducing a local variable for it helps keeping some lines a bit shorter. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: rockchip: Set polarity unconditionally in .get_state()Uwe Kleine-König1-4/+4
Don't rely on *state being zero initialized and PWM_POLARITY_NORMAL being zero. So always assign .polarity. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: bcm2835: Suppress error message during deferred probeStefan Wahren1-2/+5
This suppresses error messages in case the PWM clock isn't ready yet. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: bcm2835: Fix period_ns range checkStefan Wahren1-4/+5
The range check for period_ns was written under assumption of a fixed PWM clock. With clk-bcm2835 driver the PWM clock is a dynamic one. So fix this by doing the range check on the period register value. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: bcm2835: Suppress error message for invalid period_nsStefan Wahren1-4/+1
The PWM config can be triggered via sysfs, so we better suppress the error message in case of an invalid period to avoid kernel log spamming. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: rcar: Remove a redundant condition in rcar_pwm_apply()Yoshihiro Shimoda1-1/+1
Since the rcar_pwm_apply() has already checked whether state->enabled is set or not, this patch removes a redundant condition. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: sprd: Add Spreadtrum PWM supportBaolin Wang3-0/+321
This patch adds the Spreadtrum PWM support, which provides maximum 4 channels. Signed-off-by: Neo Hou <neo.hou@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: mediatek: Add MT8516 SoC supportFabien Parent1-0/+7
Add the compatible and the platform data to support PWM on the MT8516 SoC. Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: Remove dev_err() usage after platform_get_irq()Stephen Boyd1-3/+1
We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. // <smpl> @@ expression ret; struct platform_device *E; @@ ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) ); if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl> While we're here, remove braces on if statements that only have one statement (manually). Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-pwm@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: imx: Document known limitationsUwe Kleine-König1-0/+4
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: jz4740: Document known limitationsUwe Kleine-König1-0/+5
The JZ4740 PWM implementation doesn't fulfill the (up to now insufficiently documented) requirements of the PWM API. At least document them in the driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: sifive: Remove redundant error messageDing Xiang1-3/+1
devm_ioremap_resource() already outputs an error message, so remove the extra error message on failure. Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21pwm: mxs: Use devm_platform_ioremap_resource() to simplify codeAnson Huang1-3/+1
Use the new helper devm_platform_ioremap_resource() which wraps the platform_get_resource() and devm_ioremap_resource() together, to simplify the code. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-19Merge tag 'tag-chrome-platform-for-v5.4' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform updates from Benson Leung: "CrOS EC / MFD Migration: - Move cros_ec core driver from mfd into chrome platform. Wilco EC: - Add batt_ppid_info command to Wilco telemetry driver. CrOS EC: - cros_ec_rpmsg : Add support to inform EC of suspend/resume status - cros_ec_rpmsg : Fix race condition on probe failed - cros_ec_chardev : Add a poll handler to receive MKBP events Misc: - bugfixes in cros_usbpd_logger and cros_ec_ishtp" * tag 'tag-chrome-platform-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_usbpd_logger: null check create_singlethread_workqueue platform/chrome: cros_ec_chardev: Add a poll handler to receive MKBP events platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed platform/chrome: chromeos_tbmc: Report wake events mfd: cros_ec: Use mfd_add_hotplug_devices() helper mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC subdevices mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper mfd / platform: cros_ec: Reorganize platform and mfd includes mfd / platform: cros_ec: Rename config to a better name mfd: cros_ec: Switch to use the new cros-ec-chardev driver mfd / platform: cros_ec: Miscellaneous character device to talk with the EC mfd / platform: cros_ec: Move cros-ec core driver out from MFD mfd / platform: cros_ec: Handle chained ECs as platform devices platform/chrome: cros_ec_rpmsg: Add host command AP sleep state support platform/chrome: chromeos_laptop: drop checks of NULL-safe functions platform/chrome: wilco_ec: Add batt_ppid_info command to telemetry driver
2019-09-02mfd / platform: cros_ec: Reorganize platform and mfd includesEnric Balletbo i Serra1-2/+2
There is a bit of mess between cros-ec mfd includes and platform includes. For example, we have a linux/mfd/cros_ec.h include that exports the interface implemented in platform/chrome/cros_ec_proto.c. Or we have a linux/mfd/cros_ec_commands.h file that is non related to the multifunction device (in the sense that is not exporting any function of the mfd device). This causes crossed includes between mfd and platform/chrome subsystems and makes the code difficult to read, apart from creating 'curious' situations where a platform/chrome driver includes a linux/mfd/cros_ec.h file just to get the exported functions that are implemented in another platform/chrome driver. In order to have a better separation on what the cros-ec multifunction driver does and what the cros-ec core provides move and rework the affected includes doing: - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c driver from include/linux/mfd/cros_ec.h to a new file include/linux/platform_data/cros_ec_proto.h - Update all the drivers with the new includes, so - Drivers that only need to know about the protocol include - linux/platform_data/cros_ec_proto.h - linux/platform_data/cros_ec_commands.h - Drivers that need to know about the cros-ec mfd device also include - linux/mfd/cros_ec.h Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Series changes: 3 - Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp) Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-09-02mfd / platform: cros_ec: Move cros-ec core driver out from MFDEnric Balletbo i Serra1-1/+1
Now, the ChromeOS EC core driver has nothing related to an MFD device, so move that driver from the MFD subsystem to the platform/chrome subsystem. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-08-08pwm: Fallback to the static lookup-list when acpi_pwm_get failsHans de Goede1-2/+5
Commit 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") made pwm_get unconditionally return the acpi_pwm_get return value if the device passed to pwm_get has an ACPI fwnode. But even if the passed in device has an ACPI fwnode, it does not necessarily have the necessary ACPI package defining its pwm bindings, especially since the binding / API of this ACPI package has only been introduced very recently. Up until now X86/ACPI devices which use a separate pwm controller for controlling their LCD screen's backlight brightness have been relying on the static lookup-list to get their pwm. pwm_get unconditionally returning the acpi_pwm_get return value breaks this, breaking backlight control on these devices. This commit fixes this by making pwm_get fall back to the static lookup-list if acpi_pwm_get returns -ENOENT. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96571 Reported-by: youling257@gmail.com Fixes: 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") Cc: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-07-09Merge tag 'pwm/for-5.3-rc1' of ↵Linus Torvalds13-455/+1063
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This set of changes contains a new driver for SiFive SoCs as well as enhancements to the core (device links are used to track dependencies between PWM providers and consumers, support for PWM controllers via ACPI, sysfs will now suspend/resume PWMs that it has claimed) and various existing drivers" * tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits) pwm: fsl-ftm: Make sure to unlock mutex on failure pwm: fsl-ftm: Use write protection for prescaler & polarity pwm: fsl-ftm: More relaxed permissions for updating period pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWM pwm: bcm2835: Improve precision of PWM leds: pwm: Support ACPI via firmware-node framework pwm: Add support referencing PWMs from ACPI pwm: rcar: Remove suspend/resume support pwm: sysfs: Add suspend/resume support pwm: Add power management descriptions pwm: meson: Add documentation to the driver pwm: meson: Add support PWM_POLARITY_INVERSED when disabling pwm: meson: Don't cache struct pwm_state internally pwm: meson: Read the full hardware state in meson_pwm_get_state() pwm: meson: Simplify the calculation of the pre-divider and count pwm: meson: Move pwm_set_chip_data() to meson_pwm_request() pwm: meson: Add the per-channel register offsets and bits in a struct pwm: meson: Add the meson_pwm_channel data to struct meson_pwm pwm: meson: Pass struct pwm_device to meson_pwm_calc() pwm: meson: Don't duplicate the polarity internally ...
2019-06-26pwm: fsl-ftm: Make sure to unlock mutex on failureThierry Reding1-2/+2
Upon failure to enable clocks while trying to enable the PWM, make sure to unlock the mutex that was taken to avoid a deadlock during subsequent operations. Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Cc: Patrick Havelange <patrick.havelange@essensium.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: fsl-ftm: Use write protection for prescaler & polarityPatrick Havelange1-0/+21
Modifying the prescaler or polarity value must be done with the write protection disabled. Currently this is working by chance as the write protection is in a disabled state by default. This patch makes sure that we enable/disable the write protection when needed. Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: fsl-ftm: More relaxed permissions for updating periodPatrick Havelange1-180/+186
The Flextimer has only one period for several channels. The PWM subsystem doesn't allow to model something like that. The current implementation simply disallows changing the period once it has been set, having as a side effect that you need to enable and disable the PWM if you want to change the period. The driver should allow as much freedom as possible for configuring the period and duty cycle. Therefore, this patch reworks the code to allow the following: - period and duty_cycle can be set at will when the PWM is disabled; - when enabling a PWM, verify that the period is either not set yet, or the same as the other already enabled PWM(s), and fail if not; - allow to change the period on the fly when the PWM is the only one enabled. It also allows to have different periods configured for different PWMs. Only one period can be used at a time, thus the first PWM to be enabled will set that period, only other PWMs with that same period can be enabled at the same time. To use another PWM with another period, the enabled PWMs must be disabled first. Example scenario : echo 5000000 > pwm0/period #OK echo 1000000 > pwm0/duty_cycle #OK echo 1000000 > pwm1/period #OK echo 1000000 > pwm1/duty_cycle #OK echo 1 > pwm0/enable #OK echo 1 > pwm1/enable #FAIL (pwm0/period != pwm1/period) echo 0 > pwm0/enable #OK echo 1 > pwm1/enable #OK echo 1000000 > pwm0/period #OK echo 2000000 > pwm0/period #OK echo 1 > pwm0/enable #FAIL (pwm0/period != pwm1/period) echo 2000000 > pwm1/period #OK (pwm1 still running, changed on the fly) echo 1 > pwm0/enable #OK (now pwm0/period == pwm1/period) echo 3000000 > pwm1/period #FAIL (other PWMs running) echo 0 > pwm0/enable #OK echo 3000000 > pwm1/period #OK (only this PWM running) Adapting the code to satisfy these constraints turned up a number of additional issues with the current implementation: - the prescaler value 0 was not used (when it could have been); - when setting the period was not possible, the internal state was inconsistent; - the maximal value for configuring the period was never used; Since all of these interact with each other, rather than trying to fix each individual issue, this patch reworks how the period and duty cycle are set entirely, with the following additional improvements: - implement the new apply() method instead of the individual methods; - return the exact used period/duty_cycle values; - more coherent argument types for period, duty_cycle; Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWMClaudiu Beznea1-0/+1
Add compatible string for SAM9X60 HLCDC's PWM. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: bcm2835: Improve precision of PWMSean Young1-3/+5
If sending IR with carrier of 455kHz using the pwm-ir-tx driver, the carrier ends up being 476kHz. The clock is set to bcm2835-pwm with a rate of 10MHz. A carrier of 455kHz has a period of 2198ns, but the arithmetic truncates this to 2100ns rather than 2200ns. So, use DIV_ROUND_CLOSEST() to reduce rounding errors, and we have a much more accurate carrier of 454.5kHz. Reported-by: Andreas Christ <andreas@christ-faesch.ch> Signed-off-by: Sean Young <sean@mess.org> Acked-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: Add support referencing PWMs from ACPINikolaus Voss1-0/+122
In analogy to referencing a GPIO using the "gpios" property from ACPI, support referencing a PWM using the "pwms" property. ACPI entries must look like Package () {"pwms", Package () { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}} In contrast to the DT implementation, only _one_ PWM entry in the "pwms" property is supported. As a consequence "pwm-names"-property and con_id lookup aren't supported. Support for ACPI is added via the firmware-node framework which is an abstraction layer on top of ACPI/DT. To keep this patch clean, DT and ACPI paths are kept separate. The firmware-node framework could be used to unify both paths in a future patch. To support leds-pwm driver, an additional method devm_fwnode_pwm_get() which supports both ACPI and DT configuration is exported. Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> [thierry.reding@gmail.com: fix build failures for !ACPI] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: rcar: Remove suspend/resume supportYoshihiro Shimoda1-39/+0
According to the Documentation/pwm.txt, all PWM consumers should implement power management instead of the PWM driver. So, this patch removes suspend/resume support. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: sysfs: Add suspend/resume supportYoshihiro Shimoda1-0/+102
According to the Documentation/pwm.txt, all PWM consumers should have power management. Since this sysfs interface is one of consumers so that this patch adds suspend/resume support. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> [thierry.reding@gmail.com: fix build warnings for !PM] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Add documentation to the driverMartin Blumenstingl1-0/+22
Add links to the datasheet and a short summary how the hardware works. The goal is to make it easier for other developers to understand why the pwm-meson driver is implemented the way it is. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Co-authored-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Add support PWM_POLARITY_INVERSED when disablingMartin Blumenstingl1-1/+22
meson_pwm_apply() has to consider the PWM polarity when disabling the output. With enabled=false and polarity=PWM_POLARITY_NORMAL the output needs to be LOW. The driver already supports this. With enabled=false and polarity=PWM_POLARITY_INVERSED the output needs to be HIGH. Implement this in the driver by internally enabling the output with the same settings that we already use for "period == duty". This fixes a PWM API violation which expects that the driver honors the polarity also for enabled=false. Due to the IP block not supporting this natively we only get "an as close as possible" to 100% HIGH signal (in my test setup with input clock of 24MHz and measuring the output with a logic analyzer at 24MHz sampling rate I got a duty cycle of 99.998475% on a Khadas VIM). Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Don't cache struct pwm_state internallyMartin Blumenstingl1-24/+1
The PWM core already caches the "current struct pwm_state" as the "current state of the hardware registers" inside struct pwm_device. Drop the struct pwm_state from struct meson_pwm_channel in favour of the struct pwm_state in struct pwm_device. While here also drop any checks based on the pwm_state because the PWM core already takes care of this. No functional changes intended. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Read the full hardware state in meson_pwm_get_state()Martin Blumenstingl1-3/+49
Update the meson_pwm_get_state() implementation to take care of all information in the registers instead of only reading the "enabled" state. The PWM output is only enabled if two conditions are met: 1. the per-channel clock is enabled 2. the PWM output is enabled Calculate the PWM period and duty cycle using the reverse formula which we already have in meson_pwm_calc() and update struct pwm_state with the results. As result of this /sys/kernel/debug/pwm now shows the PWM state set by the bootloader (or firmware) after booting Linux. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Simplify the calculation of the pre-divider and countMartin Blumenstingl1-15/+10
Replace the loop to calculate the pre-divider and count with two separate div64_u64() calculations. This makes the code easier to read and improves the precision. Three example cases: 1) 32.768kHz LPO clock for the SDIO wifi chip on Khadas VIM clock input: 500MHz (FCLK_DIV4) period: 30518ns duty cycle: 15259ns old algorithm: pre_div=0, cnt=15259 new algorithm: pre_div=0, cnt=15259 (no difference in calculated values) 2) PWM LED on Khadas VIM clock input: 24MHz (XTAL) period: 7812500ns duty cycle: 7812500ns old algorithm: pre_div=2, cnt=62004 new algorithm: pre_div=2, cnt=62500 Using a scope (24MHz sampling rate) shows the actual difference: - old: 7753000ns, off by -59500ns (0.7616%) - new: 7815000ns, off by +2500ns (0.032%) 3) Theoretical case where pre_div is different clock input: 24MHz (XTAL) period: 2730624ns duty cycle: 1365312ns old algorithm: pre_div=1, cnt=32768 new algorithm: pre_div=0, cnt=65534 Using a scope (24MHz sampling rate) shows the actual difference: - old: 2731000ns - new: 2731000ns (my scope is not precise enough to measure the difference if there's any) Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Move pwm_set_chip_data() to meson_pwm_request()Martin Blumenstingl1-14/+8
All existing PWM drivers (except pwm-meson and two other ones) call pwm_set_chip_data() from their pwm_ops.request() callback. Now that we can access the struct meson_pwm_channel from struct meson_pwm we can do the same. Move the call to pwm_set_chip_data() to meson_pwm_request() and drop the custom meson_pwm_add_channels(). This makes the implementation consistent with other drivers and makes it slightly more obvious thatpwm_get_chip_data() cannot be used from pwm_ops.get_state() (because that's called by the PWM core before pwm_ops.request()). No functional changes intended. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Add the per-channel register offsets and bits in a structMartin Blumenstingl1-56/+34
Introduce struct meson_pwm_channel_data which contains the per-channel offsets for the PWM register and REG_MISC_AB bits. Replace the existing switch (pwm->hwpwm) statements with an access to the new struct. This simplifies the code and will make it easier to implement pwm_ops.get_state() because the switch-case which all per-channel registers and offsets (as previously implemented in meson_pwm_enable()) doesn't have to be duplicated. No functional changes intended. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26pwm: meson: Add the meson_pwm_channel data to struct meson_pwmMartin Blumenstingl1-15/+10
Make struct meson_pwm_channel accessible from struct meson_pwm. PWM core has a limitation: per-channel data can only be set after pwmchip_add() is called. However, pwmchip_add() internally calls pwm_ops.get_state(). If pwm_ops.get_state() needs access to the per-channel data it has to obtain it from struct pwm_chip and struct pwm_device's hwpwm information. Add a struct meson_pwm_channel for each PWM channel to struct meson_pwm so the pwm_ops.get_state() callback can be implemented as it needs access to the clock from struct meson_pwm_channel. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-30 03:13:43 +0000