blackbird-obmc-linux/include/linux/regulator, branch dev-5.0-raptor-04-16-2019

Merge branch 'for-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21

2018-12-11T20:44:49+00:00

regulator: core: Only count load for enabled consumers

2018-11-22T14:38:00+00:00

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: Fix return value of _set_load() stub

2018-11-20T15:22:46+00:00

The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang Signed-off-by: Mark Brown Reviewed-by: Douglas Anderson Signed-off-by: Mark Brown

Merge branch 'topic/coupled' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21 for trivial conflict

2018-11-19T13:16:15+00:00

regulator: core: Use ww_mutex for regulators locking

2018-11-19T12:33:17+00:00

Wait/wound mutex shall be used in order to avoid lockups on locking of coupled regulators. Signed-off-by: Dmitry Osipenko Suggested-by: Lucas Stach Signed-off-by: Mark Brown

regulator: core: Add new max_uV_step constraint

2018-11-08T16:20:49+00:00

On NVIDIA Tegra30 there is a requirement for regulator "A" to have voltage higher than voltage of regulator "B" by N microvolts, the N value changes depending on the voltage of regulator "B". This is similar to min-spread between voltages of regulators, the difference is that the spread value isn't fixed. This means that extra carefulness is required for regulator "A" to drop its voltage without violating the requirement, hence its voltage should be changed in steps so that its couple "B" could follow (there is also max-spread requirement). Add new "max_uV_step" constraint that breaks voltage change into several steps, each step is limited by the max_uV_step value. Signed-off-by: Dmitry Osipenko Signed-off-by: Mark Brown

regulator: core: Limit regulators coupling to a single couple

2018-11-08T16:20:47+00:00

Device tree binding was changed in a way that now max-spread values must be defied per regulator pair. Limit number of pairs in order to adapt to the new binding without changing regulators code. Signed-off-by: Dmitry Osipenko Signed-off-by: Mark Brown

regulator: pfuze100-regulator: add coin support to PF0100

2018-11-06T17:27:46+00:00

The driver currently supports coin cell / super cap charging, so this patch extends it to support PF0100. Signed-off-by: Adam Ford Reviewed-by: Fabio Estevam Signed-off-by: Mark Brown

Merge tag 'bd71847-support' into regulator-4.20

2018-09-28T14:07:30+00:00

regulator/mfd: Support for the ROHM BD71847 This adds support for the BD71847 which touches both MFD and regulator. There's a few other bits and pieces included as some dependency patches had already been applied so would've required rebasing.

regulator: Support regulators where voltage ranges are selectable

2018-09-28T13:57:03+00:00

For example ROHM BD71837 and ROHM BD71847 Power management ICs have regulators which provide multiple linear ranges. Ranges can be selected by individual non contagious bit in vsel register. Add regmap helper functions for selecting ranges. Signed-off-by: Matti Vaittinen Signed-off-by: Mark Brown