summaryrefslogtreecommitdiffstats
path: root/drivers/regulator/internal.h
AgeCommit message (Collapse)AuthorFilesLines
2018-11-22regulator: core: Only count load for enabled consumersDouglas Anderson1-0/+2
In general when the consumer of a regulator requests that the regulator be disabled it no longer will be drawing much load from the regulator--it should just be the leakage current and that should be very close to 0. Up to this point the regulator framework has continued to count a consumer's load request for disabled regulators. This has led to code patterns that look like this: enable_my_thing(): regular_set_load(reg, load_uA) regulator_enable(reg) disable_my_thing(): regulator_disable(reg) regulator_set_load(reg, 0) Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead of setting a 0 uA load. I will make the assertion that nearly all (if not all) places where we set a nominal load of 100 uA or less we end up with a result that is the same as if we had set a load of 0 uA. Specifically: - The whole point of setting the load is to help set the operating mode of the regulator. Higher loads may need less efficient operating modes. - The only time this matters at all is if there is another consumer of the regulator that wants the regulator on. If there are no other consumers of the regulator then the regulator will turn off and we don't care about the operating mode. - If there's another consumer that actually wants the regulator on then presumably it is requesting a load that makes our nominal <= 100 uA load insignificant. A quick survey of the existing callers to regulator_set_load() to see how everyone uses it: Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: core: Parse coupled regulators propertiesMaciej Purski1-2/+26
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Add new structure "coupling_desc" to regulator_dev, which contains pointers to all coupled regulators including the owner of the structure, number of coupled regulators and counter of currently resolved regulators. Add of_functions to parse all data needed in regulator coupling. Provide method to check DTS data consistency. Check if each coupled regulator's max_spread is equal and if their lists of regulators match. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-05regulator: add dummy function of_find_regulator_by_nodeChangbin Du1-2/+7
If device tree is not enabled, of_find_regulator_by_node() should have a dummy function since the function call is still there. This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced. If this option is enabled, GCC will not auto-inline functions that are not explicitly marked as inline. In this case (no CONFIG_OF), the copmiler will report error in function regulator_dev_lookup(). W/O NO_AUTO_INLINE, function of_get_regulator() is auto-inlined and then the call to of_find_regulator_by_node() is optimized out since of_get_regulator() always return NULL. W/ NO_AUTO_INLINE, the return value of of_get_regulator() is a variable so the call to of_find_regulator_by_node() cannot be optimized out. So we need a stub of_find_regulator_by_node(). static struct regulator_dev *regulator_dev_lookup(struct device *dev, const char *supply) { struct regulator_dev *r = NULL; struct device_node *node; struct regulator_map *map; const char *devname = NULL; regulator_supply_alias(&dev, &supply); /* first do a dt based lookup */ if (dev && dev->of_node) { node = of_get_regulator(dev, supply); if (node) { r = of_find_regulator_by_node(node); if (r) return r; ... Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26Merge branch 'topic/suspend' of ↵Mark Brown1-2/+16
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core
2018-01-26regulator: core: Move of_find_regulator_by_node() to of_regulator.cMaciej Purski1-0/+9
As of_find_regulator_by_node() is an of function it should be moved from core.c to of_regulator.c. It provides better separation of device tree functions from the core and allows other of_functions in of_regulator.c to resolve device_node to regulator_dev. This will be useful for implementation of parsing coupled regulators properties. Declare of_find_regulator_by_node() function in internal.h as well as regulator_class and dev_to_rdev(), as they are needed by of_find_regulator_by_node(). Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26regulator: make regulator voltage be an array to support more statesChunyan Zhang1-2/+16
Some regulator consumers would like to make the regulator device keeping a voltage range output when the system entering into suspend states. Making regulator voltage be an array can allow consumers to set voltage for normal state as well as for suspend states through the same code. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-03-17regulator: Mark supply_name const and duplicate it as suchStephen Boyd1-1/+1
The supply_name member of struct regulator can be const as we don't change it in the regulator core. Furthermore, when we copy the supply name we can use kstrdup_const() here to avoid a copy if the name is in the ro data section. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-02-04regulator: core: have _regulator_get() accept get_type argumentDmitry Torokhov1-0/+10
Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3 valid combinations (normal, exclusive and optional) and an invalid one, let's accept explicit "get_type", like we did in devm-managed code. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-01-08regulator: Allow parsing custom properties when using simplified DT parsingKrzysztof Kozlowski1-0/+2
When drivers use simplified DT parsing method (they provide 'regulator_desc.of_match') they still may want to parse custom properties for some of the regulators. For example some of the regulators support GPIO enable control. Add a driver-supplied callback for such case. This way the regulator core parses common bindings offloading a lot of code from drivers and still custom properties may be used. The callback, called for each parsed regulator, may modify the 'regulator_config' initially passed to regulator_register(). Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-10regulator: of: Add stub OF match function for !OF caseMark Brown1-0/+10
Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-10regulator: of: Provide simplified DT parsing methodMark Brown1-0/+4
Currently regulator drivers which support DT all repeat very similar code to supply a list of known regulator identifiers to be matched with DT, convert that to platform data which is then matched up with the regulators as they are registered. This is both fiddly to get right and for devices which can use the standard helpers to provide their operations is the main source of code in the driver. Since this code is essentially identical for most drivers we can factor it out into the core, moving the identifiers in the match table into the regulator descriptors and also allowing drivers to pass in the name of the subnode to search. When a driver provides an of_match string for the regulator the core will attempt to use that to obtain init_data, allowing the driver to remove all explicit code for DT parsing and simply provide data instead. The current code leaks the phandles for the child nodes, this will be addressed incrementally and makes no practical difference for FDT anyway as the DT data structures are never freed. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-09-17regulator: core: Split devres code out into a separate fileMark Brown1-0/+38
Cut down on the size of core.c a bit more and ensure that the devres versions of things don't do too much peering inside the internals of the APIs they wrap. Signed-off-by: Mark Brown <broonie@linaro.org>