#
60377339 |
|
16-Feb-2024 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
regulator: pwm-regulator: Use dev_err_probe() for error paths in .probe() One error path already used the dev_err_probe() helper. Make use of it in the other error paths, too, for consistent output. This results in a more compact source code and symbolic output of the error code. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://msgid.link/r/20240216071829.1513748-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
09235bf3 |
|
16-Feb-2024 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
regulator: pwm-regulator: Use dev_err_probe() for error paths in .probe() One error path already used the dev_err_probe() helper. Make use of it in the other error paths, too, for consistent output. This results in a more compact source code and symbolic output of the error code. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://msgid.link/r/20240216071829.1513748-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b3cbdcc1 |
|
13-Jan-2024 |
Martin Blumenstingl <martin.blumenstingl@googlemail.com> |
regulator: pwm-regulator: Manage boot-on with disabled PWM channels Odroid-C1 uses a Monolithic Power Systems MP2161 controlled via PWM for the VDDEE voltage supply of the Meson8b SoC. Commit 6b9352f3f8a1 ("pwm: meson: modify and simplify calculation in meson_pwm_get_state") results in my Odroid-C1 crashing with memory corruption in many different places (seemingly at random). It turns out that this is due to a currently not supported corner case. The VDDEE regulator can generate between 860mV (duty cycle of ~91%) and 1140mV (duty cycle of 0%). We consider it to be enabled by the bootloader (which is why it has the regulator-boot-on flag in .dts) as well as being always-on (which is why it has the regulator-always-on flag in .dts) because the VDDEE voltage is generally required for the Meson8b SoC to work. The public S805 datasheet [0] states on page 17 (where "A5" refers to the Cortex-A5 CPU cores): [...] So if EE domains is shut off, A5 memory is also shut off. That does not matter. Before EE power domain is shut off, A5 should be shut off at first. It turns out that at least some bootloader versions are keeping the PWM output disabled. This is not a problem due to the specific design of the regulator: when the PWM output is disabled the output pin is pulled LOW, effectively achieving a 0% duty cycle (which in return means that VDDEE voltage is at 1140mV). The problem comes when the pwm-regulator driver tries to initialize the PWM output. To do so it reads the current state from the hardware, which is: period: 3666ns duty cycle: 3333ns (= ~91%) enabled: false Then those values are translated using the continuous voltage range to 860mV. Later, when the regulator is being enabled (either by the regulator core due to the always-on flag or first consumer - in this case the lima driver for the Mali-450 GPU) the pwm-regulator driver tries to keep the voltage (at 860mV) and just enable the PWM output. This is when things start to go wrong as the typical voltage used for VDDEE is 1100mV. Commit 6b9352f3f8a1 ("pwm: meson: modify and simplify calculation in meson_pwm_get_state") triggers above condition as before that change period and duty cycle were both at 0. Since the change to the pwm-meson driver is considered correct the solution is to be found in the pwm-regulator driver. Update the duty cycle during driver probe if the regulator is flagged as boot-on so that a call to pwm_regulator_enable() (by the regulator core during initialization of a regulator flagged with boot-on) without any preceding call to pwm_regulator_set_voltage() does not change the output voltage. [0] https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://msgid.link/r/20240113224628.377993-4-martin.blumenstingl@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6a7d11ef |
|
13-Jan-2024 |
Martin Blumenstingl <martin.blumenstingl@googlemail.com> |
regulator: pwm-regulator: Calculate the output voltage for disabled PWMs If a PWM output is disabled then it's voltage has to be calculated based on a zero duty cycle (for normal polarity) or duty cycle being equal to the PWM period (for inverted polarity). Add support for this to pwm_regulator_get_voltage(). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://msgid.link/r/20240113224628.377993-3-martin.blumenstingl@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c92688ca |
|
13-Jan-2024 |
Martin Blumenstingl <martin.blumenstingl@googlemail.com> |
regulator: pwm-regulator: Add validity checks in continuous .get_voltage Continuous regulators can be configured to operate only in a certain duty cycle range (for example from 0..91%). Add a check to error out if the duty cycle translates to an unsupported (or out of range) voltage. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://msgid.link/r/20240113224628.377993-2-martin.blumenstingl@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c748a6d7 |
|
19-Dec-2023 |
Sean Young <sean@mess.org> |
pwm: Rename pwm_apply_state() to pwm_apply_might_sleep() In order to introduce a pwm api which can be used from atomic context, we will need two functions for applying pwm changes: int pwm_apply_might_sleep(struct pwm *, struct pwm_state *); int pwm_apply_atomic(struct pwm *, struct pwm_state *); This commit just deals with renaming pwm_apply_state(), a following commit will introduce the pwm_apply_atomic() function. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
045a44d4 |
|
14-Jul-2023 |
Rob Herring <robh@kernel.org> |
regulator: Explicitly include correct DT includes The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174930.4063320-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
259b93b2 |
|
16-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14 Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7dda20c9 |
|
10-Mar-2023 |
Rob Herring <robh@kernel.org> |
regulator: Use of_property_present() for testing DT property presence It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144721.1544756-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e458d3f3 |
|
25-Sep-2021 |
Anand Moon <linux.amoon@gmail.com> |
regulator: pwm-regulator: Make use of the helper function dev_err_probe() devm_pwm_get() can return -EPROBE_DEFER if the pwm regulator is not ready yet. Use dev_err_probe() for pwm regulator resources to indicate the deferral reason when waiting for the resource to come up. Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Link: https://lore.kernel.org/r/20210925173413.1019-1-linux.amoon@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
59ae97a7 |
|
02-Sep-2020 |
Vincent Whitchurch <vincent.whitchurch@axis.com> |
regulator: pwm: Fix machine constraints application If the zero duty cycle doesn't correspond to any voltage in the voltage table, the PWM regulator returns an -EINVAL from get_voltage_sel() which results in the core erroring out with a "failed to get the current voltage" and ending up not applying the machine constraints. Instead, return -ENOTRECOVERABLE which makes the core set the voltage since it's at an unknown value. For example, with this device tree: fooregulator { compatible = "pwm-regulator"; pwms = <&foopwm 0 100000>; regulator-min-microvolt = <2250000>; regulator-max-microvolt = <2250000>; regulator-name = "fooregulator"; regulator-always-on; regulator-boot-on; voltage-table = <2250000 30>; }; Before this patch: fooregulator: failed to get the current voltage(-22) After this patch: fooregulator: Setting 2250000-2250000uV fooregulator: 2250 mV Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
dc8c5ea3 |
|
20-Aug-2020 |
Jisheng Zhang <Jisheng.Zhang@synaptics.com> |
regulator: pwm: Fix W=1 build warning when CONFIG_OF=n Fix below warning when CONFIG_OF=n: drivers/regulator/pwm-regulator.c:393:34: warning: ‘pwm_of_match’ defined but not used [-Wunused-const-variable=] 393 | static const struct of_device_id pwm_of_match[] = { | ^~~~~~~~~~~~ Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200821111658.59a7218b@xhacker.debian Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4e773e73 |
|
26-Jun-2020 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Demote kerneldoc header to standard comment This particular comment doesn't have anything to do with documenting functions or data structures. Instead it is used as a section header. Fixes W=1 warning: drivers/regulator/pwm-regulator.c:55: warning: Function parameter or member 'rdev' not described in 'pwm_regulator_init_state' Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200626065738.93412-4-lee.jones@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0cd71b9a |
|
02-Mar-2020 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: pwm: Don't warn on probe deferral Deferred probe is an expected return value for devm_pwm_get(). Given that the driver deals with it properly, rather than warn on probe deferral, only output a message on probe deferral if debug level prints are enabled. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200302141428.14119-1-jonathanh@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d2912cb1 |
|
04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
638aef7a |
|
11-Jan-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: pwm: No need to make a copy of regulator_ops per instance Having instance specific copy of desc is enough to support multiple instance of pwm regulator. The regulator_ops is never changed so no need to copy it per instance, make pwm_regulator_voltage_table_ops and pwm_regulator_voltage_continuous_ops const to ensure they won't be changed. The pwm_regulator_desc is a template to be copied so also make it const. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a4aae5af |
|
23-Jul-2017 |
Fabio Estevam <fabio.estevam@nxp.com> |
regulator: pwm-regulator: Remove unneeded gpiod NULL check The gpiod API checks for NULL descriptors, so there is no need to duplicate the check in the driver. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
73e705bf |
|
14-Sep-2016 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Add set_voltage_time op The new op is analogous to set_voltage_time_sel. It can be used by regulators which don't have a table of discrete voltages. The function returns the time for the regulator output voltage to stabilize after being set to a new value, in microseconds. If the op is not set a default implementation is used to calculate the delay. This change also removes the ramp_delay calculation in the PWM regulator, since the driver now uses the core code for the calculation of the delay. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ea398e28 |
|
14-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Support extra continuous mode cases The continuous mode allows one to declare a PWM regulator without having to declare the voltage <-> dutycycle association table. It works fine as long as your voltage(dutycycle) function is linear, but also has the following constraints: - dutycycle for min_uV = 0% - dutycycle for max_uV = 100% - dutycycle for min_uV < dutycycle for max_uV While the linearity constraint is acceptable for now, we sometimes need to restrict of the PWM range (to limit the maximum/minimum voltage for example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be tweaked with PWM polarity, but not all PWMs support inverted polarity). Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define such constraints. If those properties are not defined, the PWM regulator use the default pwm-dutycycle-range = <0 100> and pwm-dutycycle-unit = <100> values (existing behavior). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
d9070fdb |
|
14-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Retrieve correct voltage The continuous PWM voltage regulator is caching the voltage value in the ->volt_uV field. While most of the time this value should reflect the real voltage, sometime it can be sightly different if the PWM device rounded the set_duty_cycle request. Moreover, this value is not valid until someone has modified the regulator output. Remove the ->volt_uV field and always rely on the PWM state to calculate the regulator output. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
87248991 |
|
14-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Properly initialize the ->state field The ->state field is currently initialized to 0, thus referencing the voltage selector at index 0, which might not reflect the current voltage value. If possible, retrieve the current voltage selector from the PWM state, else return -EINVAL. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
3f4eb39b |
|
14-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Switch to the atomic PWM API Use the atomic API wherever appropriate and get rid of pwm_apply_args() call (the reference period and polarity are now explicitly set when calling pwm_apply_state()). We also make use of the pwm_set_relative_duty_cycle() helper to ease relative to absolute duty_cycle conversion. Note that changes introduced by commit fd786fb0276a ("regulator: pwm: Try to avoid voltage error in duty cycle calculation") are no longer needed because pwm_set_relative_duty_cycle() takes care of all rounding approximation for us. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
fd4f99c4 |
|
14-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Adjust PWM config at probe time The PWM attached to a PWM regulator device might have been previously configured by the bootloader. Make sure the bootloader and linux config are in sync, and adjust the PWM config if that's not the case. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
c2588393 |
|
06-Jul-2016 |
Douglas Anderson <dianders@chromium.org> |
regulator: pwm: Fix regulator ramp delay for continuous mode The original commit adding support for continuous voltage mode didn't handle the regulator ramp delay properly. It treated the delay as a fixed delay in uS despite the property being defined as uV / uS. Let's adjust it. Luckily there appear to be no users of this ramp delay for PWM regulators (as per grepping through device trees in linuxnext). Note also that the upper bound of usleep_range probably shouldn't be a full 1 ms longer than the lower bound since I've seen plenty of hardware with a ramp rate of ~5000 uS / uV and for small jumps the total delays are in the tens of uS. 1000 is way too much. We'll try to be dynamic and use 10%. NOTE: This commit doesn't add support for regulator-enable-ramp-delay. That could be done in a future patch when someone has a user of that featre. Though this patch is shows as "fixing" a bug, there are no actual known users of continuous mode PWM regulator w/ ramp delay in mainline and so this likely won't have any effect on anyone unless they are working out-of-tree with private patches. For anyone in this state, it is highly encouraged to also pick Boris Brezillon's WIP patches to get yourself a reliable and glitch-free regulator. Fixes: 4773be185a0f ("regulator: pwm-regulator: Add support for continuous-voltage") Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
27bfa889 |
|
23-Jun-2016 |
Alexandre Courbot <acourbot@nvidia.com> |
regulator: pwm: Support for enable GPIO Add an optional enable GPIO to the pwm-regulator driver. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
83058300 |
|
03-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Drop unneeded pwm_enable() call Now that the PWM regulator driver implements the ->enable/disable() hooks we can remove the pwm_enable() call from pwm_regulator_set_voltage(). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6bc24526 |
|
14-Apr-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Use pwm_get_args() where appropriate The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework allowing the PWM framework to support hardware readout and expose real PWM state even when the PWM has just been requested (before the user calls pwm_config/enable/disable()). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
8c12ad8e |
|
14-Apr-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: Use pwm_get_args() where appropriate The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework allowing the PWM framework to support hardware readout and expose real PWM state even when the PWM has just been requested (before the user calls pwm_config/enable/disable()). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
fd786fb0 |
|
05-Apr-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: pwm: Try to avoid voltage error in duty cycle calculation In continuous mode of the PWM regulators, the requested voltage PWM duty cycle is calculated in terms of 100% scale where entire range denotes 100%. The calculation for PWM pulse ON time(duty_pulse) is done as: duty_cycle = ((requested - minimum) * 100) / voltage_range. then duty pulse is calculated as duty_pulse = (pwm_period/100) * duty_cycle This leads to the calculation error if we have the requested voltage where accurate pulse time is possible. For example: Consider following case voltage range is 800000uV to 1350000uV. pwm-period = 1550ns (1ns time is 1mV). Requested 900000uV. duty_cycle = ((900000uV - 800000uV) * 100)/ 1550000 = 6.45 but we will get 6. duty_pulse = (1550/100) * 6 = 90 pulse time. 90 pulse time is equivalent to 90mV and this gives us pulse time equivalent to 890000uV instead of 900000uV. Proposing the solution in which if requested voltage makes the accurate duty pulse then there will not be any error. On this case, if (req_uV - min_uV) * pwm_period is perfect dividable by voltage_range then get the duty pulse time directly. duty_pulse = ((900000uV - 800000uV) * 1550)/1550000) = 100 and this is equivalent to 100mV and so final voltage is (800000 + 100000) = 900000uV which is same as requested, Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5bf59bd5 |
|
14-Mar-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: pwm: Prints error number along with detail Prints the error number along with error message when any error occurs. This help on getting the reason of failure quickly from log without any code instrument. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f907a0a9 |
|
08-Mar-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: pwm: Add support to have multiple instance of pwm regulator Some of platforms like Nvidia's Tegra210 Jetson-TX1 platform has multiple PMW based regulators. Add support to have multiple instances of the driver by not changing any global data of pwm regulator and if required, making instance specific copy and then making changes. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1aaab348 |
|
08-Mar-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: pwm: Fix calculation of voltage-to-duty cycle With following equation for calculating voltage_to_duty_cycle_percentage 100 - (((req_uV * 100) - (min_uV * 100)) / diff); we get 0% for max_uV and 100% for min_uV. Correcting this to ((req_uV * 100) - (min_uV * 100)) / diff; to get proper duty cycle. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1de7d802 |
|
21-Sep-2015 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: pwm: implement ->enable(), ->disable() and ->is_enabled methods Implement the ->enable(), ->disable() and ->is_enabled methods and remove the PWM call in ->set_voltage_sel(). This is particularly important for critical regulators tagged as always-on, because not claiming the PWM (and its dependencies) might lead to unpredictable behavior (like a system hang because the PWM clk is only claimed when the PWM device is enabled). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
60cb65eb |
|
10-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Fix ' comparison between signed and unsigned integer' warning drivers/regulator/pwm-regulator.c: In function ‘pwm_regulator_init_table’: drivers/regulator/pwm-regulator.c:171:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b343e08f |
|
10-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Fix 'used uninitialized' warning drivers/regulator/pwm-regulator.c: In function 'pwm_regulator_init_table': drivers/regulator/pwm-regulator.c:172:14: warning: 'length' is used uninitialized in this function [-Wuninitialized] if ((length < sizeof(*duty_cycle_table)) || ^ Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f293634b |
|
10-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Fix 'unused-variable' warning drivers/regulator/pwm-regulator.c: In function 'pwm_regulator_init_continuous': drivers/regulator/pwm-regulator.c:202:22: warning: unused variable 'np' [-Wunused-variable] struct device_node *np = pdev->dev.of_node; ^ Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f3f6439d |
|
09-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Small clean-ups Remove over-bracketing, use framework API to fetch PWM period and be more forthcoming that pwm_voltage_to_duty_cycle() actually returns duty cycle as a percentage, rather than a register value. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f747a1fe |
|
09-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Remove obsoleted property In "[3d7ef30] regulator: pwm-regulator: Simplify voltage to duty-cycle call" we stopped using max_duty_cycle, so we can retire it from device data and DT. There is no need to deprecate this property, as it hasn't hit Mainline yet. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5ad2cb14 |
|
07-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Don't assign structure attributes right away Perhaps this is just personal preference, but ... This patch introduces a new local variable to receive and test regulator initialisation data. It simplifies and cleans up the code making it that little bit easier to read and maintain. The local value is assigned to the structure attribute when all the others are. This is the way we usually do things. Prevents this kind of nonsense: this->is->just.silly = fetch_silly_value(&pointer); if (!this->is->just.silly) { printk("Silly value failed: %d\n", this->is->just.silly); return this->is->just.silly; } Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
cae897de |
|
07-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Simplify voltage to duty-cycle call If we reverse some of the logic and change the formula used, we can simplify the function greatly. It is intentional that this function is supplied and then re-worked within the same patch-set. The submission in the previous patch is the tried and tested (i.e. in real releases) method written by ST. This patch contains a simplification provided later. It looks and performs better, but doesn't have the same time-under-test that the original method does. The idea is that we keep some history in order to provide an easy way back i.e. revert. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4773be18 |
|
07-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Add support for continuous-voltage The current version of PWM regulator only supports a static table approach, where pre-calculated values are supplied by the vendor and obtained via DT. The continuous-voltage method takes min_uV and max_uV, and divides the difference between them up into a number of slices. The number of slices depend on how large the duty cycle register is. This information is provided by a DT property. As the name alludes, this provides values for a continuous voltage range between min_uV and max_uV, which has obvious benefits over either limited voltage possibilities, or the requirement to provide a large voltage-table. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f9178dad |
|
06-Jul-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Separate voltage-table initialisation Take this out of the main .probe() routine in order to facilitate the introduction of different ways to obtain 'duty cycle' information. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ab101e35 |
|
05-Jun-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Diffientiate between dev (device) and rdev (regulator_dev) Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c779cebb |
|
05-Jun-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Remove superfluous is_enabled check The core framework already takes care of this. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b6f55e74 |
|
05-Jun-2015 |
Lee Jones <lee.jones@linaro.org> |
regulator: pwm-regulator: Remove unnecessary descriptor attribute from ddata The Regulator Device keeps a full copy of it's own, which can be easily accessed. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
072e78b1 |
|
10-Nov-2014 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: of: Add regulator desc param to of_get_regulator_init_data() The of_get_regulator_init_data() function is used to extract the regulator init_data but information on how to extract certain data is defined in the static regulator descriptor (e.g: how to map the hardware operating modes). Add a const struct regulator_desc * parameter to the function signature so the parsing logic could use the information in the struct regulator_desc. of_get_regulator_init_data() relies on of_get_regulation_constraints() to actually extract the init_data so it has to pass the struct regulator_desc but that is modified on a later patch. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6c794b26 |
|
20-Oct-2014 |
Wolfram Sang <wsa@kernel.org> |
regulator: drop owner assignment from platform_drivers A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
aa66cc66 |
|
27-Sep-2014 |
Chris Zhong <zyw@rock-chips.com> |
regulator: pwm-regulator: get voltage and duty table from dts rename st-pwm to pwm-regulator. And support getting voltage & duty table from device tree, other platforms can also use this driver without any modify. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|