linux-toradex.git/drivers/regulator, branch v4.13-rc2 Linux kernel for Apalis and Colibri modules Merge remote-tracking branches 'regulator/topic/settle', 'regulator/topic/tps65910' and 'regulator/topic/tps65917' into regulator-next 2017-07-03T15:52:21+00:00 Mark Brown broonie@kernel.org 2017-07-03T15:52:21+00:00 8d67f64f7739464c352d4b167ed1748f3b2c1f44 






Merge remote-tracking branches 'regulator/topic/hi6421v530', 'regulator/topic/lp8755', 'regulator/topic/lp87565', 'regulator/topic/max8997' and 'regulator/topic/palmas' into regulator-next
2017-07-03T15:52:18+00:00

Mark Brown
broonie@kernel.org

2017-07-03T15:52:18+00:00

9b08f765f5816a6053026b8eba1ee34e0272853c












Merge remote-tracking branches 'regulator/topic/axp20x', 'regulator/topic/bd9571mwv', 'regulator/topic/da9061' and 'regulator/topic/hi6421' into regulator-next
2017-07-03T15:52:17+00:00

Mark Brown
broonie@kernel.org

2017-07-03T15:52:17+00:00

8f5bb9c143c965d982d762add43162f077ebcdbc












Merge remote-tracking branch 'regulator/topic/core' into regulator-next
2017-07-03T15:52:16+00:00

Mark Brown
broonie@kernel.org

2017-07-03T15:52:16+00:00

fcaa3167b2763d35a7dc60c5724f23e441d29f4f












regulator: core: Fix size limit of supply_map
2017-06-30T11:56:42+00:00

Haishan Zhou
zhssmail@gmail.com

2017-06-30T03:43:42+00:00

dbc559554086f176b04f97eec561ad26ee54e47c

Now the debugfs file supply_map has a size limit PAGE_SIZE and the user
can not see the whole content of regulator_map_list when it is larger
than this limit.

This patch uses seq_file instead to make sure supply_map shows the full
information of regulator_map_list.

Signed-off-by: Haishan Zhou <zhssmail@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>





Now the debugfs file supply_map has a size limit PAGE_SIZE and the user
can not see the whole content of regulator_map_list when it is larger
than this limit.

This patch uses seq_file instead to make sure supply_map shows the full
information of regulator_map_list.

Signed-off-by: Haishan Zhou <zhssmail@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>







regulator: core: Fix voltage change propagations to supply regulators
2017-06-28T19:39:36+00:00

Tirupathi Reddy
tirupath@codeaurora.org

2017-05-25T10:03:17+00:00

2c2874b191d54fbf9216524e629558eee89e1d20

Some regulators support get_voltage() and some support get_voltage_sel()
operations but currently we only propagate changes if the regulator has
a get_voltage() operation.  Also do this if we've got get_voltage_sel()

[Rewite commit message for clarity -- broonie]

Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>





Some regulators support get_voltage() and some support get_voltage_sel()
operations but currently we only propagate changes if the regulator has
a get_voltage() operation.  Also do this if we've got get_voltage_sel()

[Rewite commit message for clarity -- broonie]

Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>







regulator: lp87565: Fix the initial voltage range
2017-06-20T12:38:35+00:00

Keerthy
j-keerthy@ti.com

2017-06-20T03:36:55+00:00

42f1ea48efd99394a4790e8ab956f1fb8e0a931e

The latest documentation reveals that initial voltage range that is
supported is starting from 0.6V for all the PMICs belonging to lp87565
family. Fix the same.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: f0168a9bf ("regulator: lp87565: Add support for lp87565 PMIC regulators")
Signed-off-by: Mark Brown <broonie@kernel.org>





The latest documentation reveals that initial voltage range that is
supported is starting from 0.6V for all the PMICs belonging to lp87565
family. Fix the same.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: f0168a9bf ("regulator: lp87565: Add support for lp87565 PMIC regulators")
Signed-off-by: Mark Brown <broonie@kernel.org>







regulator: hi6421v530: Describe consumed platform device
2017-06-14T17:27:20+00:00

Guodong Xu
guodong.xu@linaro.org

2017-06-14T15:11:06+00:00

ded7b2aeefaff4e9d52a935e13ff1f1970b7cfda

The hi6421v530-regulator driver consumes a similarly named platform device.
Adding that to the module device table, allows modprobe to locate this
driver once the device is created.

Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>





The hi6421v530-regulator driver consumes a similarly named platform device.
Adding that to the module device table, allows modprobe to locate this
driver once the device is created.

Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>







regulator: tps65910: check TPS65910_NUM_REGS at build time
2017-06-13T17:46:48+00:00

Michał Mirosław
mirq-linux@rere.qmqm.pl

2017-06-13T14:41:56+00:00

fe953904f3463609a9a671f68148d8532f2a5d9f

Check TPS65910_NUM_REGS at build time instead of silently registering
not all regulators at runtime.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Mark Brown <broonie@kernel.org>





Check TPS65910_NUM_REGS at build time instead of silently registering
not all regulators at runtime.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Mark Brown <broonie@kernel.org>







regulator: core: Prioritise consumer mappings over regulator name
2017-06-13T17:43:28+00:00

Charles Keepax
ckeepax@opensource.wolfsonmicro.com

2017-06-13T15:12:47+00:00

062171973e05440673cb997e64395e84a8e66350

Currently, when looking up a regulator supply, the regulator name
takes priority over the consumer mappings. As there are a lot of
regulator names that are in fairly common use (VDD, MICVDD, etc.) this
can easily lead to obtaining the wrong supply, when a system contains
two regulators that share a name.

The explicit consumer mappings contain much less ambiguity as they
specify both a name and a consumer device. As such prioritise those if
one exists and only fall back to the regulator name if there are no
matching explicit mappings.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>





Currently, when looking up a regulator supply, the regulator name
takes priority over the consumer mappings. As there are a lot of
regulator names that are in fairly common use (VDD, MICVDD, etc.) this
can easily lead to obtaining the wrong supply, when a system contains
two regulators that share a name.

The explicit consumer mappings contain much less ambiguity as they
specify both a name and a consumer device. As such prioritise those if
one exists and only fall back to the regulator name if there are no
matching explicit mappings.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>