summaryrefslogtreecommitdiff
path: root/drivers/regulator/pwm-regulator.c
AgeCommit message (Collapse)AuthorFilesLines
2020-08-21regulator: pwm: Fix W=1 build warning when CONFIG_OF=nJisheng Zhang1-1/+1
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>
2020-06-26regulator: pwm-regulator: Demote kerneldoc header to standard commentLee Jones1-1/+1
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>
2020-03-02regulator: pwm: Don't warn on probe deferralJon Hunter1-1/+5
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>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-4/+1
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>
2019-01-14regulator: pwm: No need to make a copy of regulator_ops per instanceAxel Lin1-12/+5
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>
2017-07-24regulator: pwm-regulator: Remove unneeded gpiod NULL checkFabio Estevam1-4/+2
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>
2016-09-16regulator: core: Add set_voltage_time opMatthias Kaehlcke1-10/+0
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>
2016-07-25regulator: pwm: Support extra continuous mode casesBoris Brezillon1-10/+82
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>
2016-07-11regulator: pwm: Retrieve correct voltageBoris Brezillon1-6/+6
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>
2016-07-11regulator: pwm: Properly initialize the ->state fieldBoris Brezillon1-0/+22
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>
2016-07-11regulator: pwm: Switch to the atomic PWM APIBoris Brezillon1-28/+10
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>
2016-07-11regulator: pwm: Adjust PWM config at probe timeBoris Brezillon1-5/+3
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>
2016-07-07regulator: pwm: Fix regulator ramp delay for continuous modeDouglas Anderson1-2/+7
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>
2016-06-23regulator: pwm: Support for enable GPIOAlexandre Courbot1-0/+26
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>
2016-06-03regulator: pwm: Drop unneeded pwm_enable() callBoris Brezillon1-5/+0
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>
2016-05-03Merge branch 'for-4.7/pwm-regulator' of ↵Mark Brown1-8/+15
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm into regulator-pwm
2016-05-03regulator: pwm: Use pwm_get_args() where appropriateBoris Brezillon1-6/+14
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>
2016-04-05regulator: pwm: Try to avoid voltage error in duty cycle calculationLaxman Dewangan1-15/+23
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>
2016-03-15regulator: pwm: Prints error number along with detailLaxman Dewangan1-11/+12
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>
2016-03-12regulator: pwm: Add support to have multiple instance of pwm regulatorLaxman Dewangan1-7/+20
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>
2016-03-12regulator: pwm: Fix calculation of voltage-to-duty cycleLaxman Dewangan1-1/+1
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>
2015-09-22regulator: pwm: implement ->enable(), ->disable() and ->is_enabled methodsBoris Brezillon1-6/+29
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>
2015-07-10regulator: pwm-regulator: Fix ' comparison between signed and unsigned ↵Lee Jones1-1/+1
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>
2015-07-10regulator: pwm-regulator: Fix 'used uninitialized' warningLee Jones1-1/+1
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>
2015-07-10regulator: pwm-regulator: Fix 'unused-variable' warningLee Jones1-2/+0
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>
2015-07-09regulator: pwm-regulator: Small clean-upsLee Jones1-6/+5
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>
2015-07-09regulator: pwm-regulator: Remove obsoleted propertyLee Jones1-9/+0
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>
2015-07-07regulator: pwm-regulator: Don't assign structure attributes right awayLee Jones1-3/+5
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>
2015-07-07regulator: pwm-regulator: Simplify voltage to duty-cycle callLee Jones1-20/+7
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>
2015-07-07regulator: pwm-regulator: Add support for continuous-voltageLee Jones1-8/+106
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>
2015-07-07regulator: pwm-regulator: Separate voltage-table initialisationLee Jones1-32/+45
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>
2015-06-08regulator: pwm-regulator: Diffientiate between dev (device) and rdev ↵Lee Jones1-9/+9
(regulator_dev) Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-08regulator: pwm-regulator: Remove superfluous is_enabled checkLee Jones1-8/+4
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>
2015-06-08regulator: pwm-regulator: Remove unnecessary descriptor attribute from ddataLee Jones1-9/+6
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>
2014-12-15Merge tag 'driver-core-3.19-rc1' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core update from Greg KH: "Here's the set of driver core patches for 3.19-rc1. They are dominated by the removal of the .owner field in platform drivers. They touch a lot of files, but they are "simple" changes, just removing a line in a structure. Other than that, a few minor driver core and debugfs changes. There are some ath9k patches coming in through this tree that have been acked by the wireless maintainers as they relied on the debugfs changes. Everything has been in linux-next for a while" * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits) Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries" fs: debugfs: add forward declaration for struct device type firmware class: Deletion of an unnecessary check before the function call "vunmap" firmware loader: fix hung task warning dump devcoredump: provide a one-way disable function device: Add dev_<level>_once variants ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries ath: use seq_file api for ath9k debugfs files debugfs: add helper function to create device related seq_file drivers/base: cacheinfo: remove noisy error boot message Revert "core: platform: add warning if driver has no owner" drivers: base: support cpu cache information interface to userspace via sysfs drivers: base: add cpu_device_create to support per-cpu devices topology: replace custom attribute macros with standard DEVICE_ATTR* cpumask: factor out show_cpumap into separate helper function driver core: Fix unbalanced device reference in drivers_probe driver core: fix race with userland in device_add() sysfs/kernfs: make read requests on pre-alloc files use the buffer. sysfs/kernfs: allow attributes to request write buffer be pre-allocated. fs: sysfs: return EGBIG on write if offset is larger than file size ...
2014-11-26regulator: of: Add regulator desc param to of_get_regulator_init_data()Javier Martinez Canillas1-1/+2
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>
2014-10-20regulator: drop owner assignment from platform_driversWolfram Sang1-1/+0
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>
2014-09-28regulator: pwm-regulator: get voltage and duty table from dtsChris Zhong1-0/+197
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>