summaryrefslogtreecommitdiff
path: root/drivers/regulator/core.c
AgeCommit message (Collapse)Author
2015-11-04Merge remote-tracking branches 'regulator/topic/supply', ↵Mark Brown
'regulator/topic/tps6105x' and 'regulator/topic/tps65023' into regulator-next
2015-11-04Merge remote-tracking branch 'regulator/topic/list' into regulator-nextMark Brown
2015-11-04Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2015-11-04regulator: Use regulator_lock_supply() for get_voltage() tooMark Brown
Since we need to read voltages of parents as part of setting supply voltages we need to be able to do get_voltage() internally without taking locks so reorganize the locking to take locks on the full tree on entry rather than as we recurse when called externally. Reported-by: John Stultz <john.stultz@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-22regulator: core: Propagate voltage changes to supply regulatorsSascha Hauer
Until now changing the voltage of a regulator only ever effected the regulator itself, but never its supplies. It's a common pattern though to put LDO regulators behind switching regulators. The switching regulators efficiently drop the input voltage but have a high ripple on their output. The output is then cleaned up by the LDOs. For higher energy efficiency the voltage drop at the LDOs should be minimized. For this scenario we need to propagate the voltage change to the supply regulators. Another scenario where voltage propagation is desired is a regulator which only consists of a switch and thus cannot regulate voltages itself. In this case we can pass setting voltages to the supply. This patch adds support for voltage propagation. We do voltage propagation when the current regulator has a minimum dropout voltage specified or if the current regulator lacks a get_voltage operation (indicating it's a switch and not a regulator). Changing the supply voltage must be done carefully. When we are increasing the current regulators output we must first increase the supply voltage and then the regulator itself. When we are decreasing the current regulators voltage we must decrease the supply voltage after changing the current regulators voltage. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-20regulator: core: Factor out regulator_map_voltageSascha Hauer
_regulator_call_set_voltage has code to translate a minimum/maximum voltage pair into a selector. This code is useful for others aswell, so create a regulator_map_voltage function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-16regulator: core: create unlocked version of regulator_set_voltageSascha Hauer
The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-01regulator: core: create unlocked version of regulator_list_voltageSascha Hauer
The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-01regulator: core: introduce function to lock regulators and its suppliesSascha Hauer
Each regulator_dev is locked with its own mutex. This is fine as long as only one regulator_dev is locked, but makes lockdep unhappy when we have to walk up the supply chain like it can happen in regulator_get_voltage: regulator_get_voltage -> mutex_lock(&regulator->rdev->mutex) -> _regulator_get_voltage(regulator->rdev) -> regulator_get_voltage(rdev->supply) -> mutex_lock(&regulator->rdev->mutex); This causes lockdep to issue a possible deadlock warning. There are at least two ways to work around this: - We can always lock the whole supply chain using the functions introduced with this patch. - We could store the current voltage in struct regulator_rdev so that we do not have to walk up the supply chain for the _regulator_get_voltage case. Anyway, regulator_lock_supply/regulator_unlock_supply will be needed once we allow regulator_set_voltage to optimize the supply voltages. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-01regulator: core: Handle probe deferral from DT when resolving suppliesMark Brown
When resolving regulator-regulator supplies we ignore probe deferral returns from regulator_dev_lookup() (such as are generated for DT when we can see a supply is registered) and just fall back to the dummy regulator if there are full constraints (as is the case for DT). This means that probe deferral is broken for DT systems, fix that by paying attention to -EPROBE_DEFER return codes like we do -ENODEV. A further patch will simplify this further, this is a minimal fix for the specific issue. Fixes: 9f7e25edb1575a6d2 (regulator: core: Handle full constraints systems when resolving supplies) Reported-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonnie@kernel.org> Cc: stable@vger.kernel.org
2015-09-21Merge remote-tracking branch 'regulator/fix/core' into regulator-linusMark Brown
2015-09-21regulator: core: Remove regulator_listTomeu Vizoso
As we are already registering a device with regulator_class for each regulator device, regulator_list is redundant and can be replaced with calls to class_find_device() and class_for_each_device(). Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-17regulator: core: Correct return value check in regulator_resolve_supplyCharles Keepax
The ret pointer passed to regulator_dev_lookup is only filled with a valid error code if regulator_dev_lookup returned NULL. Currently regulator_resolve_supply checks this ret value before it checks if a regulator was returned, this can result in valid regulator lookups being ignored. Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-09-16regulator: core: Make error messages more informativeStephen Boyd
The same error print exists 4 times in the regulator core <rdev>: operation not allowed Unfortunately, seeing this in the dmesg is not very informative. Add what type of operation is not allowed to the message so that these errors are unique, hopefully pointing developers in the right direction <rdev>: drms operation not allowed <rdev>: voltage operation not allowed <rdev>: current operation not allowed <rdev>: mode operation not allowed Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-08Merge tag 'regmap-v4.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap updates from Mark Brown: "This has been a busy release for regmap. By far the biggest set of changes here are those from Markus Pargmann which implement support for block transfers in smbus devices. This required quite a bit of refactoring but leaves us better able to handle odd restrictions that controllers may have and with better performance on smbus. Other new features include: - Fix interactions with lockdep for nested regmaps (eg, when a device using regmap is connected to a bus where the bus controller has a separate regmap). Lockdep's default class identification is too crude to work without help. - Support for must write bitfield operations, useful for operations which require writing a bit to trigger them from Kuniori Morimoto. - Support for delaying during register patch application from Nariman Poushin. - Support for overriding cache state via the debugfs implementation from Richard Fitzgerald" * tag 'regmap-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: (25 commits) regmap: fix a NULL pointer dereference in __regmap_init regmap: Support bulk reads for devices without raw formatting regmap-i2c: Add smbus i2c block support regmap: Add raw_write/read checks for max_raw_write/read sizes regmap: regmap max_raw_read/write getter functions regmap: Introduce max_raw_read/write for regmap_bulk_read/write regmap: Add missing comments about struct regmap_bus regmap: No multi_write support if bus->write does not exist regmap: Split use_single_rw internally into use_single_read/write regmap: Fix regmap_bulk_write for bus writes regmap: regmap_raw_read return error on !bus->read regulator: core: Print at debug level on debugfs creation failure regmap: Fix regmap_can_raw_write check regmap: fix typos in regmap.c regmap: Fix integertypes for register address and value regmap: Move documentation to regmap.h regmap: Use different lockdep class for each regmap init call thermal: sti: Add parentheses around bridge->ops->regmap_init call mfd: vexpress: Add parentheses around bridge->ops->regmap_init call regmap: debugfs: Fix misuse of IS_ENABLED ...
2015-09-04Merge remote-tracking branches 'regmap/topic/debugfs' and ↵Mark Brown
'regmap/topic/force-update' into regmap-next
2015-09-02regulator: core: fix possible NULL dereferenceSudip Mukherjee
We were checking rdev->supply for NULL after dereferencing it. Lets check for rdev->supply along with _regulator_is_enabled() and call regulator_enable() only if rdev->supply is not NULL. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-30Merge remote-tracking branches 'regulator/topic/mt6311', ↵Mark Brown
'regulator/topic/ocp', 'regulator/topic/owner', 'regulator/topic/pfuze100' and 'regulator/topic/pwm' into regulator-next
2015-08-30Merge remote-tracking branches 'regulator/topic/da9210', ↵Mark Brown
'regulator/topic/da9211', 'regulator/topic/fan53555', 'regulator/topic/isl9305' and 'regulator/topic/list' into regulator-next
2015-08-30Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2015-08-28regulator: core: use debug level print in regulator_check_drmsArchit Taneja
When calling regulator_set_load, regulator_check_drms prints and returns an error if the regulator device's flag REGULATOR_CHANGE_DRMS isn't set. drms_uA_update, however, bails out without reporting an error. Replace the error print with a debug level print so that we don't get such prints when the underlying regulator doesn't support DRMS. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-17regulator: core: Use IS_ERR_OR_NULL()Viresh Kumar
Use IS_ERR_OR_NULL() rather than open coding it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-14regulator: core: Print at debug level on debugfs creation failureStephen Boyd
Failure to create a debugfs node is not an error, but we print a warning upon failure to create the node. Downgrade this to a debug printk so that we're quiet here. This allows multiple drivers to request a CPU's regulator so that CPUfreq and AVSish drivers can coexist. The downside of this approach is that whoever gets to debugfs first the others who come later to not have any debugfs attributes associated with them. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-13regulator: core: Spelling fixViresh Kumar
Trivial spell fix, s/succesfully/successfully. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12regulator: core: Use class device list for regulator_list in late initMark Brown
The regulator_list has exactly the same contents as the list that the driver core maintains of regulator_class members so is redundant. As a first step in converting over to use the class device list convert our iteration in late_initcall() to use the class device iterator. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12regulator: core: Move more deallocation into class unregisterMark Brown
We really ought to be using the class dvice lifetime management features more than we are rather than open coding them so take a step towards that by moving some of the simplest deallocations to the dev_release() function. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12regulator: core: Reduce rdev locking region when releasing regulatorMark Brown
When we release a regulator we need to remove references to it from the rdev which means locking the rdev. Currently we also free resources associated with the regulator inside the rdev lock but there is no need to do this, we can reduce the region the lock is held by restricting it to just actions that affect the rdev. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-07regulator: core: Drop regulator_list_mutex when we're done with it on removeMark Brown
When removing a regulator we hold regulator_list_mutex in order to ensure the regualtor doesn't become removed again. However we only need to protect the list until we remove the regulator from the list so move the unlock earlier to reduce the locked region. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-24regulator: Add over current protection (OCP) supportStephen Boyd
Some regulators can automatically shut down when they detect an over current event. Add an op (set_over_current_protection) and a DT property + constraint to support this capability. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-24Merge remote-tracking branches 'regulator/fix/88pm800', ↵Mark Brown
'regulator/fix/max8973', 'regulator/fix/s2mps11' and 'regulator/fix/supply' into regulator-linus
2015-07-16regulator: core: Fix memory leak in regulator_resolve_supply()Javier Martinez Canillas
The regulator_resolve_supply() function calls set_supply() which in turn calls create_regulator() to allocate a supply regulator. If an error occurs after set_supply() succeeded, the allocated regulator has to be freed before propagating the error code. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-16regulator: core: Increase refcount for regulator supply's moduleJavier Martinez Canillas
When a regulator is unregistered with regulator_unregister(), a call to regulator_put() is made for its input supply if there is one. This does a module_put() to decrement the refcount of the module that owns the supply but there isn't a corresponding try_module_get() in set_supply() to make the calls balanced. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-15regulator: core: Handle full constraints systems when resolving suppliesMark Brown
When resolving device supplies if we fail to look up the regulator we substitute in the dummy supply instead if the system has fully specified constraints. When resolving supplies for regulators we do not have the equivalent code and instead just directly use the regulator_dev_lookup() result causing spurious failures. This does not affect DT systems since we are able to detect missing mappings directly as part of regulator_dev_lookup() and so have appropriate handling in the DT specific code. Reported-by: Christian Hartmann <cornogle@googlemail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-06regulator: Add lockdep asserts to help detecting locking misuseKrzysztof Kozlowski
Add lockdep_assert_held_once() to functions explicitly mentioning that rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't pollute the dmesg to much. The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain regulators calling regulator_notifier_call_chain() without rdev->mutex held. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-22Merge remote-tracking branches 'regulator/topic/da9063', ↵Mark Brown
'regulator/topic/doc', 'regulator/topic/fan53555', 'regulator/topic/gpio' and 'regulator/topic/ilim' into regulator-next
2015-06-12regulator: Add input current limit supportStephen Boyd
Some regulators can limit their input current (typically annotated as ilim). Add an op (set_input_current_limit) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-12regulator: Add soft start supportStephen Boyd
Some regulators support a "soft start" feature where the voltage ramps up slowly when the regulator is enabled. Add an op (set_soft_start) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-12regulator: Add pull down supportStephen Boyd
Some regulators need to be configured to pull down a resistor when the regulator is disabled. Add an op (set_pull_down) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-12regulator: Add system_load constraintStephen Boyd
Some regulators have a fixed load that isn't captured by consumers that the kernel knows about. Add a constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-10regulator: core: replace sprintf with scnprintfStefan Wahren
In order to avoid potential overflows in print_constraints we better replace sprintf() with scnprintf(). Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-10Merge branch 'fix/core' of ↵Mark Brown
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core
2015-06-10regulator: core: fix constraints output bufferStefan Wahren
The buffer for condtraints debug isn't big enough to hold the output in all cases. So fix this issue by increasing the buffer. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
2015-06-09regulator: core: Don't corrupt display when printing uV offsetsMark Brown
We weren't taking into account the already used buffer when telling sprintf() where to print to. Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-03regulator: core: Don't spew backtraces on duplicate sysfsStephen Boyd
We don't consider a failure to add the sysfs node as a problem, so use sysfs_create_link_nowarn() so that we don't print a backtrace when duplicated files exist. Also, downgrade the printk message to a debug statement so that we're quiet here. This allows multiple drivers to request a CPU's regulator so that CPUfreq and AVSish drivers can coexist. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-10Merge remote-tracking branches 'regulator/topic/mode', ↵Mark Brown
'regulator/topic/notifier', 'regulator/topic/palmas', 'regulator/topic/qcom' and 'regulator/topic/stw481x' into regulator-next
2015-04-10Merge remote-tracking branches 'regulator/topic/dbx500', ↵Mark Brown
'regulator/topic/load-op', 'regulator/topic/max77693' and 'regulator/topic/max8660' into regulator-next
2015-04-10Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2015-04-10Merge branch 'topic/debugfs' of ↵Mark Brown
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core
2015-04-10regulator: output current-limit for all regulators in summaryHeiko Stübner
Voltage regulators can have (unregulated) current limits too, so we should probably output both voltage and current for all regulators. Holding the rdev->mutex actually conflicts with _regulator_get_current_limit but also is not really necessary, as the global regulator_list_mutex already protects us from the regulator vanishing while we go through the list. On the rk3288-firefly the summary now looks like: regulator use open bypass voltage current min max ------------------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 0mA 5000mV 5000mV vcc_lan 1 1 0 3300mV 0mA 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 0mA 3300mV 3300mV vcca_18 0 0 0 1800mV 0mA 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 0mA 1000mV 1000mV [...] Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-10regulator: add a summary tree in debugfsHeiko Stübner
On modern systems the regulator hierarchy can get quite long and nested with regulators supplying other regulators. In some cases when debugging it might be nice to get a tree of these regulators, their consumers and the regulation constraints in one go. To achieve this add a regulator_summary sysfs node, similar to clk_summary in the common clock framework, that walks the regulator list and creates a tree out of the regulators, their consumers and core per-regulator settings. On a rk3288-firefly the regulator_summary would for example look something like: regulator use open bypass value min max ----------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 5000mV 5000mV vcc_lan 1 1 0 3300mV 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 3300mV 3300mV vcca_18 0 0 0 1800mV 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 1000mV 1000mV vccio_sd 0 0 0 3300mV 3300mV 3300mV vcc_20 0 3 0 2000mV 2000mV 2000mV vcc18_lcd 0 0 0 1800mV 1800mV 1800mV vcc_18 0 2 0 1800mV 1800mV 1800mV ff100000.saradc 0mV 0mV ff0d0000.dwmmc 1650mV 1950mV vdd_10 0 0 0 1000mV 1000mV 1000mV vdd_log 0 0 0 1100mV 1100mV 1100mV vcc_io 0 3 0 3300mV 3300mV 3300mV ff0f0000.dwmmc 3300mV 3400mV vcc_flash 1 1 0 1800mV 1800mV 1800mV ff0f0000.dwmmc 1700mV 1950mV vcc_sd 1 1 0 3300mV 3300mV 3300mV ff0c0000.dwmmc 3300mV 3400mV vcc_ddr 0 0 0 1200mV 1200mV 1200mV vdd_gpu 0 0 0 1000mV 850mV 1350mV vdd_cpu 0 1 0 900mV 850mV 1350mV cpu0 900mV 900mV vcc_5v 0 2 0 5000mV 5000mV 5000mV vcc_otg_5v 0 0 0 5000mV 5000mV 5000mV vcc_host_5v 0 0 0 5000mV 5000mV 5000mV regulator-dummy 0 0 0 0mV 0mV 0mV Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>