kernel/drivers/regulator/internal.h, branch linux-5.1.y

regulator: core: Only count load for enabled consumers

2018-11-22T14:38:00Z

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 Signed-off-by: Mark Brown

regulator: core: Parse coupled regulators properties

2018-05-17T07:05:48Z

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 Signed-off-by: Mark Brown

regulator: add dummy function of_find_regulator_by_node

2018-05-05T01:40:49Z

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 Signed-off-by: Mark Brown

Merge branch 'topic/suspend' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core

2018-01-26T17:40:03Z

regulator: core: Move of_find_regulator_by_node() to of_regulator.c

2018-01-26T15:48:07Z

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 Signed-off-by: Mark Brown

regulator: make regulator voltage be an array to support more states

2018-01-26T14:43:45Z

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 Signed-off-by: Mark Brown

regulator: Mark supply_name const and duplicate it as such

2017-03-17T13:12:22Z

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 Signed-off-by: Mark Brown

regulator: core: have _regulator_get() accept get_type argument

2017-02-04T10:31:52Z

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 Signed-off-by: Mark Brown

regulator: Allow parsing custom properties when using simplified DT parsing

2015-01-08T20:15:45Z

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 Signed-off-by: Mark Brown

regulator: of: Add stub OF match function for !OF case

2014-09-10T15:40:07Z

Signed-off-by: Mark Brown