summaryrefslogtreecommitdiffstats
path: root/drivers/regulator (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'pwm/for-4.8-rc1' of ↵Linus Torvalds2016-08-061-44/+118
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This set of changes improve some aspects of the atomic API as well as make use of this new API in the regulator framework to allow properly dealing with critical regulators controlled by a PWM. Aside from that there's a bunch of updates and cleanups for existing drivers, as well as the addition of new drivers for the Broadcom iProc, STMPE and ChromeOS EC controllers" * tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits) regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range regulator: pwm: Support extra continuous mode cases pwm: Add ChromeOS EC PWM driver dt-bindings: pwm: Add binding for ChromeOS EC PWM mfd: cros_ec: Add EC_PWM function definitions mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper pwm: atmel: Use of_device_get_match_data() pwm: atmel: Fix checkpatch warnings pwm: atmel: Fix disabling of PWM channels dt-bindings: pwm: Add R-Car H3 device tree bindings pwm: rcar: Use ARCH_RENESAS pwm: tegra: Add support for Tegra186 dt-bindings: pwm: tegra: Add compatible string for Tegra186 pwm: tegra: Avoid overflow when calculating duty cycle pwm: tegra: Allow 100 % duty cycle pwm: tegra: Add support for reset control pwm: tegra: Rename mmio_base to regs pwm: tegra: Remove useless padding pwm: tegra: Drop NUM_PWM macro pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value ...
| * regulator: pwm: Support extra continuous mode casesBoris Brezillon2016-07-251-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>
| * regulator: pwm: Retrieve correct voltageBoris Brezillon2016-07-111-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>
| * regulator: pwm: Properly initialize the ->state fieldBoris Brezillon2016-07-111-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>
| * regulator: pwm: Switch to the atomic PWM APIBoris Brezillon2016-07-111-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>
| * regulator: pwm: Adjust PWM config at probe timeBoris Brezillon2016-07-111-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>
* | Merge tag 'armsoc-drivers' of ↵Linus Torvalds2016-08-021-14/+451
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver updates from Olof Johansson: "Driver updates for ARM SoCs. A slew of changes this release cycle. The reset driver tree, that we merge through arm-soc for historical reasons, is also sizable this time around. Among the changes: - clps711x: Treewide changes to compatible strings, merged here for simplicity. - Qualcomm: SCM firmware driver cleanups, move to platform driver - ux500: Major cleanups, removal of old mach-specific infrastructure. - Atmel external bus memory driver - Move of brcmstb platform to the rest of bcm - PMC driver updates for tegra, various fixes and improvements - Samsung platform driver updates to support 64-bit Exynos platforms - Reset controller cleanups moving to devm_reset_controller_register() APIs - Reset controller driver for Amlogic Meson - Reset controller driver for Hisilicon hi6220 - ARM SCPI power domain support" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (100 commits) ARM: ux500: consolidate base platform files ARM: ux500: move soc_id driver to drivers/soc ARM: ux500: call ux500_setup_id later ARM: ux500: consolidate soc_device code in id.c ARM: ux500: remove cpu_is_u* helpers ARM: ux500: use CLK_OF_DECLARE() ARM: ux500: move l2x0 init to .init_irq mfd: db8500 stop passing around platform data ASoC: ab8500-codec: remove platform data based probe ARM: ux500: move ab8500_regulator_plat_data into driver ARM: ux500: remove unused regulator data soc: raspberrypi-power: add CONFIG_OF dependency firmware: scpi: add CONFIG_OF dependency video: clps711x-fb: Changing the compatibility string to match with the smallest supported chip input: clps711x-keypad: Changing the compatibility string to match with the smallest supported chip pwm: clps711x: Changing the compatibility string to match with the smallest supported chip serial: clps711x: Changing the compatibility string to match with the smallest supported chip irqchip: clps711x: Changing the compatibility string to match with the smallest supported chip clocksource: clps711x: Changing the compatibility string to match with the smallest supported chip clk: clps711x: Changing the compatibility string to match with the smallest supported chip ...
| * | ARM: ux500: move ab8500_regulator_plat_data into driverArnd Bergmann2016-07-121-14/+451
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is only one instance of ab8500_regulator_platform_data, and it's safe to assume we won't ever merge another one, so it's rather pointless to pass it through multiple levels of platform data pointers. This moves the structure and everything referenced by it into the driver that uses it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| | |
| \ \
| \ \
| \ \
| \ \
| \ \
*-----. \ \ Merge remote-tracking branches 'regulator/topic/qcom-spmi', ↵Mark Brown2016-07-206-29/+170
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | 'regulator/topic/rn5t618', 'regulator/topic/tps65218' and 'regulator/topic/twl' into regulator-next
| | | | * | | regulator: twl: fix use of integer as pointerBen Dooks2016-06-081-1/+1
| | | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TWL6030_FIXED_LDO() macro passes the TWL_FIXED_LDO() macro an 0x0 instead of a NULL. Changing this to a NULL fixes the following warnings: drivers/regulator/twl-regulator.c:1068:1: warning: Using plain integer as NULL pointer drivers/regulator/twl-regulator.c:1069:1: warning: Using plain integer as NULL pointer drivers/regulator/twl-regulator.c:1070:1: warning: Using plain integer as NULL pointer drivers/regulator/twl-regulator.c:1071:1: warning: Using plain integer as NULL pointer drivers/regulator/twl-regulator.c:1072:1: warning: Using plain integer as NULL pointer drivers/regulator/twl-regulator.c:1073:1: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * | | regulator: tps65218: force set power-up/down strobe to 3 for dcdc3Tero Kristo2016-06-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The reset value for this register seems broken on certain versions of tps65218 chip, so make sure the dcdc3 settings is proper. Needed for proper functionality of rtc+ddr / rtc-only modes. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * | | regulator: tps65218: Enable suspend configurationTero Kristo2016-06-271-11/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TPS65218 has a pre-defined power-up / power-down sequence which in a typical application does not need to be changed. However, it is possible to define custom sequences under I2C control. The power-up sequence is defined by strobes and delay times. Each output rail is assigned to a strobe to determine the order in which the rails are enabled. Every regulator has sequence registers and every regulator has a default strobe value and gets disabled when a particular power down sequence occurs. To keep a regulator on during suspend we write value 0 to strobe so that the regulator is out of all sequencers and is not impacted by any power down sequence. Hence saving the default strobe value during probe so that when we want to regulator to be enabled during suspend we write 0 to strobe and when we want it to get disabled during suspend we write the default saved strobe value. This allows platform data to specify which power rails should be on or off during RTC only suspend. This is necessary to keep DDR state while in RTC only suspend. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * | | regulator: tps65217: Enable suspend configurationRuss Dill2016-06-271-9/+60
| | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TPS65217 has a pre-defined power-up / power-down sequence which in a typical application does not need to be changed. However, it is possible to define custom sequences under I2C control. The power-up sequence is defined by strobes and delay times. Each output rail is assigned to a strobe to determine the order in which the rails are enabled. Every regulator of tps65217 PMIC has sequence registers and every regulator has a default strobe value and gets disabled when a particular power down sequence occurs. To keep a regulator on during suspend we write value 0 to strobe so that the regulator is out of all sequencers and is not impacted by any power down sequence. Hence saving the default strobe value during probe so that when we want to regulator to be enabled during suspend we write 0 to strobe and when we want it to get disabled during suspend we write the default saved strobe value. This allows platform data to specify which power rails should be on or off during RTC only suspend. This is necessary to keep DDR state while in RTC only suspend. Signed-off-by: Russ Dill <Russ.Dill@ti.com> [Enhanced commit log and added dynamic allocation for strobes] Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | * / / regulator: rn5t618: Add RN5T567 PMIC supportStefan Agner2016-06-292-6/+39
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the driver to support Ricoh RN5T567. Support the additional DCDC and slightly different voltage range of LDORTC1. Signed-off-by: Stefan Agner <stefan@agner.ch> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
| * | | regulator: qcom_spmi: Add support for get_mode/set_mode on switchesStephen Boyd2016-06-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The voltage switches support mode switching, so add support for these ops to those types of regulators. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: qcom_spmi: Update mvs1/mvs2 switches on pm8941Stephen Boyd2016-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mvs1 and mvs2 switches are actually called 5vs1 and 5vs2 on some datasheets. Let's rename them to match the datasheets and also match the RPM based regulator driver which calls these by their 5vs names (see qcom_smd-regulator.c). There aren't any users of these regulators so far, so there aren't any concerns of DT ABI breakage here. While we're here making updates to the switches, also mandate usage of the OCP irq for these switches too. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: qcom_spmi: Add support for S4 supply on pm8941Stephen Boyd2016-06-261-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The S4 supply is sometimes called the boost regulator because it outputs 5V. Typically it's connected to the 5vs1 and 5vs2 switches for use in USB OTG and HDMI applications. Add support for this regulator which was mistakenly left out from the initial submission of this driver. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
| \ \
| \ \
| \ \
| \ \
| \ \
| \ \
*-------. \ \ Merge remote-tracking branches 'regulator/topic/mt6397', ↵Mark Brown2016-07-206-31/+129
|\ \ \ \ \ \ \ | | | | | |_|/ | | | | |/| | | | | | | | | 'regulator/topic/of', 'regulator/topic/pfuze100', 'regulator/topic/pwm' and 'regulator/topic/qcom-smd' into regulator-next
| | | | | * | regulator: qcom_smd: Avoid overlapping linear voltage rangesStephen Boyd2016-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pm8x41_hfsmps ranges overlap. The first range is from 375000 to 1562500: 375000 + (95 * 12500) == 1562500 and the second range starts at 1550000. Interestingly, the second range ends at the correct value when it's set to be the appropriate start value, 1575000: 1575000 + ((158 - 96) * 25000) == 3125000 Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | | * | regulator: qcom_smd: Remove list_voltage callback for rpm_smps_ldo_ops_fixedAxel Lin2016-06-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use regulator_list_voltage_linear_range in rpm_smps_ldo_ops_fixed is wrong because it is used for fixed regulator without any linear range. The rpm_smps_ldo_ops_fixed is used for pm8941_lnldo which has fixed_uV set and n_voltages = 1. In this case, regulator_list_voltage() can return rdev->desc->fixed_uV without .list_voltage implementation. Fixes: 3bfbb4d1a480 ("regulator: qcom_smd: add list_voltage callback") Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | * | | regulator: pwm: Fix regulator ramp delay for continuous modeDouglas Anderson2016-07-071-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>
| | | | * | | regulator: pwm: Support for enable GPIOAlexandre Courbot2016-06-231-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>
| | | | * | | regulator: pwm: Drop unneeded pwm_enable() callBoris Brezillon2016-06-031-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>
| | | * | | regulator: pfuze100-regulator: Adjust MODULE_DESCRIPTION()Fabio Estevam2016-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjust the MODULE_DESCRIPTION() text to also include the PFUZE3000 as a supported device. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * | | regulator: Kconfig: Mention that PFUZE3000 is also supportedFabio Estevam2016-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CONFIG_REGULATOR_PFUZE100 option also supports PFUZE3000, so mention that in the Kconfig text. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * | | regulator: pfuze100-regulator: Remove global variableFabio Estevam2016-06-061-7/+6
| | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should better not use a global 'struct pfuze_regulator' variable, as this could cause problems if multiple regulator chips are used. Place it inside the private struct instead. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | * / / regulator: of: setup initial suspend stateKeerthy2016-06-221-0/+3
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setup initial suspend state to mem, if suspend state is defined for mem state. This makes sure that the regulators are in proper mode already from boot. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: mt6397: Add buck change mode regulator interface for mt6397Henry Chen2016-05-301-9/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUCKs of mt6397 have auto mode and pwm mode. User can use regulator interfaces to control modes Signed-off-by: Henry Chen <henryc.chen@mediatek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: mt6397: Constify struct regulator_opsHenry Chen2016-05-301-3/+3
| |/ / | | | | | | | | | | | | | | | | | | Consitify the structure of regulator operations. Signed-off-by: Henry Chen <henryc.chen@mediatek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
| \ \
| \ \
| \ \
| \ \
| \ \
| \ \
*-------. \ \ Merge remote-tracking branches 'regulator/topic/fixed', ↵Mark Brown2016-07-209-39/+449
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 'regulator/topic/headers', 'regulator/topic/lp837x', 'regulator/topic/max8973' and 'regulator/topic/mt6323' into regulator-next
| | | | | * | | regulator: mt6323: Constify struct regulator_opsAxel Lin2016-07-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | | * | | regulator: mt6323: Fix module descriptionAxel Lin2016-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | | * | | regulator: mt6323: Add support for MT6323 regulatorChen Zhong2016-07-183-0/+435
| | | | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MT6323 is a regulator found on boards based on MediaTek MT7623 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Signed-off-by: Chen Zhong <chen.zhong@mediatek.com> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | * / / regulator: max8973: Fix setting ramp delayAxel Lin2016-05-301-10/+6
| | | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code can set ramp delay to a wrong setting that the return value from .set_voltage_time_sel is not enough for proper delay. Fix the logic in .set_ramp_delay and also remove unused ret_val variable. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * / / regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR()Axel Lin2016-06-211-8/+6
| | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No need to pass _nlr to LP873X_REGULATOR(), use ARRAY_SIZE to calculate it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | * / / regulator: pv880x0: Clean up unnecessary header inclusionAxel Lin2016-05-303-9/+0
| | |/ / | | | | | | | | | | | | | | | | Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * / / regulator: fixed: Remove workaround to handle of_get_named_gpio() returnLaxman Dewangan2016-05-301-12/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPIO interface of_get_named_gpio() has implemented the proper error returns even EPROBE_DEFER and hence caller need not to implement any workaround for translating the returned error. Remove the workaround implemented to handle the return of of_get_named_gpio(). Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
| \ \
| \ \
| \ \
| \ \
*-----. \ \ Merge remote-tracking branches 'regulator/topic/act8865', ↵Mark Brown2016-07-205-40/+36
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | 'regulator/topic/can-change-voltage', 'regulator/topic/da9210' and 'regulator/topic/da9211' into regulator-next
| | | | * | | regulator: da9211: add descriptions for da9212/da9214James Ban2016-06-292-5/+11
| | | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a patch for adding description for da9212/da9214. Signed-off-by: James Ban <James.Ban.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * / / regulator: da9210: addition of device tree supportSteve Twiss2016-07-151-2/+19
| | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Addition of device tree support for DA9210. Two files are modified, the driver source file and the binding document. Updates for the regulator source file include an .of_match_table entry and node match checking in the probe() function for a compatible da9210 string. Minor binding documentation changes have been made to the title and the example. Tested-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | * / / regulator: Remove regulator_can_change_voltage()Mark Brown2016-06-091-27/+0
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is little obvious use case for a regualtor driver to know if it is possible to vary voltages at all by itself. If a consumer needs to limit what voltages it tries to set based on the system configuration then it will need to enumerate the possible voltages, and without that even if it is possible to change voltages that doesn't mean that constraints or other consumers will allow whatever change the driver is trying to do at a given time. It doesn't even indicate if _set_voltage() calls will work as noop _set_voltage() calls return success. There were no users of this API that weren't abusing it and now they're all gone so remove the API. Signed-off-by: Mark Brown <broonie@kernel.org>
| * / / regulator: act8865: Fix missing of_node_put() in act8865_pdata_from_dt()Wei Yongjun2016-07-141-6/+6
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This node pointer is returned by of_get_child_by_name() with refcount incremented in this function. of_node_put() is missing when exitting this function while invalid device type. Fix it by move of_get_child_by_name() code after device type check. Found by Coccinelle. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Mark Brown <broonie@kernel.org>
* | | Merge remote-tracking branch 'regulator/topic/axp20x' into regulator-nextMark Brown2016-07-201-28/+119
|\ \ \
| * | | regulator: axp20x: Add support for the (external) drivebus regulatorHans de Goede2016-06-061-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The axp20x pmics have 2 power inputs, one called ACIN which is intended for to be supplied via a powerbarrel on the board and one called VBUS which is intended to be supplied via an otg connector. In the VBUS case the pmic needs to know if the board is supplying power to the otg connector, because then it should not take any power from its VBUS pin. The axp209 pmic has a N_VBUSEN input pin via which the board can signal to the pmic whether the board is supplying power to the otg connector or not. On the axp221/axp223 this pin can alternatively be used as an output which controls an external regulator which (optionally) supplies power to the otg connector from the board. When the pin is used as output it is called DRIVEVBUS in the datasheet. This commit adds support for the DRIVEVBUS pin as an extra pmic controlled regulator. Since this is optional a new x-powers,drivebus dt property is added. When this is present the misc-control register is written to change the N_VBUSEN input pin to DRIVEVBUS output pin mode and the extra drivebus regulator is registered with the regulator subsystem. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: axp20x: support AXP809 variantChen-Yu Tsai2016-05-311-29/+90
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221, though a few LDOs were removed, and a new switch output added. Like the AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained to DCDC1 and DCDC5, respectively. Add support for this new variant. Also remove the "axp22x_" prefix from DC1SW/DC5LDO supply handling code, as the AXP809 uses it as well. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
*-. \ \ Merge remote-tracking branches 'regulator/fix/da9053' and ↵Mark Brown2016-07-202-6/+6
|\ \ \ \ | | | | | | | | | | | | | | | 'regulator/fix/s2mps11' into regulator-linus
| | * | | regulator: s2mps11: Fix the voltage linear range for s2mps15Alim Akhtar2016-07-121-3/+3
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes some of the LDOs and BUCKs voltage range as per user manual of s2mps15 (REV0.4). Fixes: 51af20675800 ("regulator: s2mps11: Add support for S2MPS15 regulators") Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
| * / / regulator: da9053/52: Fix incorrectly stated minimum and maximum voltage limitsSteve Twiss2016-07-201-3/+3
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fix alters the minimum and maximum BUCK voltage limits for DA9052 and DA9053. It does so for the following cases: DA9052 - BUCK3 (MEM) min: 0.925V -> 0.950V max: 2.500V -> 2.525V DA9053 - BUCK3 (MEM) min: 0.925V -> 0.950V max: 2.500V -> 2.525V - BUCK4 (PERI) min: 0.925V -> 0.950V max: 2.500V -> 2.525V The voltage range remains the same, but the limits are shifted by +0.025V. This change is provided on DA9052:MEM, DA9053:MEM and DA9053:PERI and is a voltage difference of 0.025V, compared to those measured before this fix is applied. The patch has the effect of decreasing *all* measured voltages on those BUCKs when compared against the previously measured values for the same software voltage request. For example, with this fix applied for DA9052:MEM, DA9053:MEM and DA9053:PERI, the following is true. Because the previous software defined slot 0 as being 0.925V, if a request for 0.950V was previously sent, the slot 1 voltage would have been used. This would have corresponded to an actual measured voltage of 0.975V. But, with this patch fix, and with slot 0 properly aligned to 0.950V, if a voltage of 0.950V is requested by software, a measured value of 0.950V will be provided. Tested-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
*-. \ \ Merge remote-tracking branches 'regulator/fix/anatop' and ↵Mark Brown2016-07-012-2/+7
|\ \ \ \ | | | | | | | | | | | | | | | 'regulator/fix/max77620' into regulator-linus
| | * | | regulator: max77620: check for valid regulator infoVenkat Reddy Talla2016-06-291-1/+6
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SD4 regulator is not registered with regulator core framework in probe as there is no support in MAX77620 PMIC, removing SD4 entry from MAX77620 regulator information list and checking for valid regulator information data before configuring FPS source and FPS power up/down period to avoid NULL pointer exception if regulator not registered with core. Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 00:28:17 +0100