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>
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>
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>
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>
Fix trivial typo.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
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>
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>
Maxim MAX77621 device is high-efficiency, three-phase,
DC-DC step-down switching regulator delivers peak
output currents up to 16A. This device is extension of
MAX8973 and compatible with the register definition.
The MAX77621 has the SHUTDOWN pin which is EN pin on the
MAX8973. On MAX77621, the SHUTDOWN pin (active low) reset
device register to its POR/OTP value. The voltage output
is enabled when SHUTDONW pin is HIGH and EN bit on VOUT
register is HIGH.
For MAX8973, VOUT is enabled when EN bit or EN pin is high.
Add support of the MAX77621 device on max8973 regulator driver
with following changes:
- Make sure SHUTDOWN pin is set HIGH through GPIO calls if
GPIO from AP connected to SHUTDOWN pin provided.
- Enable/disable the rail through register access only.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Regulator core framework support the configuration of ramp
delay reading from platform specific regulator data via the
regulator callback ops.
Instead of reading regulator init data on driver and setting
ramp delay, use the callback to achieve this.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Regulator Device keeps a full copy of it's own, which can be easily accessed.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Using the driver for the internal regulator to also enable/disable
the codec internal clock frequency controller is an unexpected
side-effect for a regulator, and also means that the core clocks
won't be changed as expected if an external regulator is used to
power the codec.
The DVFS is now handled by the codec driver so can be removed from
the LDO1 driver.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code does not set regulators->irq_ldo_lim and regulators->irq_uvov,
so it actually calls free_irq(0, regulators) twice in remove() but does not
free the irq actually used.
Convert to use devm_request_threaded_irq instead and then we don't need to
take care the clean up irq so remove irq_ldo_lim and irq_uvov from
struct da9063_regulators. Note, regulators->irq_uvov is not used at all in
current code.
There is a slightly change in this patch, it will return error in probe()
if devm_request_threaded_irq fails. If the irq is optional, it should be
fine to allow platform_get_irq_byname fails. But current code does not
allow platform_get_irq_byname fails. So I think the reason to allow
request irq failure is just because the irq leak.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the unused variable build warning for reg_matches that appears
during the compilation of the DA9062 regulator driver.
da9062-regulator.c: In function da9062_regulator_probe:
da9062-regulator.c:727:29: warning: unused variable reg_matches
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 1c6c69525b ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix broken probe of da9052 regulators, which since commit b3f6c73db7
("mfd: da9052-core: Fix platform-device id collision") use a
non-deterministic platform-device id to retrieve static regulator
information. Fortunately, adequate error handling was in place so probe
would simply fail with an error message.
Update the mfd-cell ids to be zero-based and use those to identify the
cells when probing the regulator devices.
Fixes: b3f6c73db7 ("mfd: da9052-core: Fix platform-device id collision")
Cc: stable <stable@vger.kernel.org> # v3.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Setting the set_voltage_time_sel callback to the standard function
regulator_set_voltage_time_sel enables the regulator to actually honor
ramp-delays when during regulator_set_voltage calls.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove extra space between platform prefix and driver name in MODULE_ALIAS.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
MAX8973 supports the voltage output enable/disable through its EN
pin. This EN pin can be connected through GPIO from host processor.
Add support to provide GPIO number from platform/DT and if it is
valid GPIO then enable external control default.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There are some platform specific parameter required to configure
the device like enable external control, DVS gpio etc.
Add DT parsing of such properties to make platform specific data.
Update DT binding doc accordingly.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
To find that dvs-gpio is valid or not, gpio API gpio_is_valid()
can be directly used instead of intermediate variable.
Removing the extra variable and using the gpio_is_valid().
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If platform data has dvs-gpio value 0 as default/unset then
make this as invalid gpio so that function gpio_is_valid()
can return false on this case.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add BUCK and LDO regulator driver support for DA9062
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The code should handle more than 32 bits here because "id"
can be a value up to MAX77686_REGULATORS (currently 34).
Convert the gpio_enabled type to DECLARE_BITMAP and use
test_bit/set_bit.
Fixes: 3307e9025d ("regulator: max77686: Add GPIO control")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Add AXP22X regulator definitions and variant id associations.
This introduces a new "switch" type output for one of the regulators.
It is a switchable secondary output of one regulator, with the same
voltage level as the primary output.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
[wens@csie.org: Moved variant choosing to multi family support patch]
[wens@csie.org: Add dc-dc work frequency range]
[wens@csie.org: Add "switch" type output regulator DC1SW]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Rework the AXP20X_ macros and probe function to support the several chip
families, so that each family can define it's own set of regulators.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
[wens@csie.org: Support different DC-DC work frequency ranges]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
If a regulator is listed in devicetree, but the node is marked as
"disabled" we should skip parsing the regulator init data and
deny consumers from interacting with the regulator. This
simplifies devicetree maintenance where we can have one dtsi file
with all regulators supported by a PMIC and then select what
regulators are used depending on the board configuration.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for the 1.175V mode on the LDO1 regulator on the
wm5110. This is need as part of the low power sleep mode operation.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use regulator_is_enabled_regmap() to replace max77843_reg_is_enabled().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
MAX77843_CHG_ENABLE is 0x05, so the enable_mask should be
MAX77843_CHG_MASK | MAX77843_CHG_BUCK_MASK.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The custom implementation of 'regulator_ops.is_enabled' callback for
charger regulator is exactly the same as regulator_is_enabled_regmap()
with 'enable_val' set.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove unneeded semicolons after the switch statement to satisfy
coccicheck.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In MAX8973, BIAS enable control bit is used for changing the startup time
for voltage output. The startup delay is 240us (typ) when the BIASEN
bit is set to 0. The startup delay is reduced to 20us (typ) when the
BIASEN bit is set to 1.
Pass the enable_time through regulator descriptor based on this flag.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace duplicated SAFEOUT regulators initializers in array of struct
'regulator_desc' arrays with macro. Generated object is the same but
SAFEOUT is described only once.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace duplicated initializers in arrays of struct 'regulator_desc'
with macro. Generated object is the same but each type of regulator is
described only once.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The function name in kernel-doc for regulator_map_voltage_linear_range()
was wrong.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not necessary to have regulator init data for a regulator. This
patch removes the necessity of this data and handles a NULL pointer
properly.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
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>
Tidy up error reporting and move rpm reference retrieval out of the for
loop for improved readability.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Modeling the individual RPM resources as platform devices consumes at
least 12-15kb of RAM, just to hold the platform_device structs. Rework
this to instead have one device per pmic exposed by the RPM.
With this representation we can more accurately define the input pins on
the pmic and have the supply description match the data sheet.
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Refactor out all custom property parsing code from the probe function
into a function suitable for regulator_desc->of_parse_cb usage.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver itself should not flag regulators as being DRMS compatible,
this should come from board or dt files.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
pdata is assigned to &pdata_of, however, pdata_of becomes dead (when it
goes out of scope) so pdata effectively becomes a dead pointer to the
out of scope object. This is detected by static analysis:
[drivers/regulator/max8660.c:411]: (error) Dead pointer usage.
Pointer 'pdata' is dead if it has been assigned '&pdata_of' at line 404.
Move declaration of pdata_of so it is always in scope.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of resolving regulator supplies during registration move this to
the time of a consumer retrieving a handle. The benefit is that it's
possible for one driver to register regulators with internal
dependencies out of order.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify the driver by removing board file support and letting
regulator core to parse DT.
The max77693 regulator driver is used only on Exynos based boards which
are DT-only. Board files for Exynos are not supported.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If multiple regulator devices of the same type exist in a system,
the regulator driver assigns generic names for the regulators it
provides, and debugfs is enabled, the regulator subsystem attempts
to create multiple entries with the same name in the regulator debugfs
directory. This fails for all but the first regulator, resulting in
multiple "Failed to create debugfs directory" log entries.
To avoid the problem, prepend the debugfs directory name for a regulator
with its parent device name if available, but only if no explicit
regulator name was provided.
Cc: Alan Tull <atull@opensource.altera.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex lock is not used at all, remove it.
The *vmmc_regulator is not necessary, use a local variable in
stw481x_vmmc_regulator_probe() instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Palmas driver is used to cater to even TPS659038 but TPS659038 does not have
REGEN3 resource. Adding another field in the driver data to check on that.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The register offset for REGEN2_CTRL in different for TPS659038 chip as when
compared with other Palmas family PMICs. In the case of TPS659038 the wrong
offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’:
drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’
drivers/regulator/tps65910-regulator.c:1018: warning: assignment makes pointer from integer without a cast
drivers/regulator/tps65910-regulator.c:1034: error: implicit declaration of function ‘of_node_put’
drivers/regulator/tps65910-regulator.c:1056: error: implicit declaration of function ‘of_property_read_u32’
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Rename the regulator_set_optimum_mode() function regulator_set_load() to
better represent what's going on.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Normally _regulator_do_enable() isn't called on an already-enabled
rdev. That's because the main caller, _regulator_enable() always
calls _regulator_is_enabled() and only calls _regulator_do_enable() if
the rdev was not already enabled.
However, there is one caller of _regulator_do_enable() that doesn't
check: regulator_suspend_finish(). While we might want to make
regulator_suspend_finish() behave more like _regulator_enable(), it's
probably also a good idea to make _regulator_do_enable() robust if it
is called on an already enabled rdev.
At the moment, _regulator_do_enable() is _not_ robust for already
enabled rdevs if we're using an ena_pin. Each time
_regulator_do_enable() is called for an rdev using an ena_pin the
reference count of the ena_pin is incremented even if the rdev was
already enabled. This is not as intended because the ena_pin is for
something else: for keeping track of how many active rdevs there are
sharing the same ena_pin.
Here's how the reference counting works here:
* Each time _regulator_enable() is called we increment
rdev->use_count, so _regulator_enable() calls need to be balanced
with _regulator_disable() calls.
* There is no explicit reference counting in _regulator_do_enable()
which is normally just a warapper around rdev->desc->ops->enable()
with code for supporting delays. It's not expected that the
"ops->enable()" call do reference counting.
* Since regulator_ena_gpio_ctrl() does have reference counting
(handling the sharing of the pin amongst multiple rdevs), we
shouldn't call it if the current rdev is already enabled.
Note that as part of this we cleanup (remove) the initting of
ena_gpio_state in regulator_register(). In _regulator_do_enable(),
_regulator_do_disable() and _regulator_is_enabled() is is clear that
ena_gpio_state should be the state of whether this particular rdev has
requested the GPIO be enabled. regulator_register() was initting it
as the actual state of the pin.
Fixes: 967cfb18c0 ("regulator: core: manage enable GPIO list")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator. However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator. That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings. We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.
Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish(). That may speed up suspend/resume and also
avoids exposing hidden bugs.
[Use much clearer commit message from Doug Anderson]
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The act88600/act8846/act8865 regulators have a number of input supplies
supplying the individual regulators. This may even be recursively like on
most Rockchip boards using the act8846 where REG4 is most of the time
connected to the inl1-supply.
Therefore add the ability to specify the input supplies for the individual inputs.
The input-names are taken from the datasheets of act8600, act8846 and act8865.
On the act8600 some regulators do not have separate input supplies.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds act8600 support to the act8865 driver.
VBUS and USB charger supported by this chip can be added later
Tested on MIPS Creator CI20
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 8f45acb5f9 ("regulator: wm8350: Pass NULL data with REGULATION_OUT
and UNDER_VOLTAGE events") introduced the following build warning:
drivers/regulator/wm8350-regulator.c: In function 'pmic_uv_handler':
drivers/regulator/wm8350-regulator.c:1154:17: warning: unused variable 'wm8350' [-Wunused-variable]
Remove 'wm8350' as it is unused now.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add devm_regulator_register_notifier, this adds the resource against the
device for the consumer supply we are registering the notifier for. There
seem to be few use-cases where this wouldn't be the users intention and
this ensures the notifiers will always be removed at the correct time.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The commit [39f802d6b6d9: 'regulator: Build sysfs entries with static
attribute groups'] converted the sysfs entry creation to static
attribute groups, but this resulted in a regression due to the NULL
check of rdev->constraints. At the point where the device is
registered, rdev->constraints isn't set, so the attributes depending
on it are missing.
We may fix it by shuffling the code order in regulator_register(), but
a quicker fix is to just remove this NULL check. rdev->constraints is
in anyway always set to non-NULL in set_machine_constraints(), thus
the check there is basically superfluous.
Fixes: 39f802d6b6 ('regulator: Build sysfs entries with static attribute groups')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reportded-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
According to the documentation, no data is passed with the OVER_CURRENT
regulator notifier event.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: James Ban <james.ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We tried to read the CONFIG_E register, not the CONTROL_E register.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: James Ban <james.ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The seq_puts/seq_printf return value, because it's frequently misused,
will eventually be converted to void.
See: commit 1f33c41c03 ("seq_file: Rename seq_overflow() to
seq_has_overflowed() and make public")
Miscellanea:
o Remove unnecessary dev_err("seq_<foo> overflow\n") messages
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the documentation, no data is passed with the
REGULATION_OUT and UNDER_VOLTAGE regulator notifier events.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Pass the requested load directly to the rpm.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Expose the requested load directly to the regulator implementation for
hardware that does not support the normal enum based set_mode().
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The LDOs are documented in the rk808 datasheet to have a soft start
time of 400us. Add that to the driver. If this time takes longer on
a certain board the device tree should be able to override with
"regulator-enable-ramp-delay".
This fixes some dw_mmc probing problems (together with other patches
posted to the mmc maiing lists) on rk3288.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
We were not calling of_node_put if the regulator failed to register this
patch fixes this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We were not calling of_node_put if the regulator failed to register this
patch fixes this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
After boot-up, some events may be set, and cause the da9210 interrupt
line to be asserted. As the da9210 driver doesn't have interrupt support
yet, this causes havoc on systems where the interrupt line is shared
among multiple devices.
This is the case on e.g. r8a7791/koelsch, where the interrupt line is
shared with a da9063 regulator, and the following events are set:
EVENT_A = 0x00000011 (GPI0 | GPI4)
EVENT_B = 0x00000002 (NPWRGOOD)
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds new regulator driver to support max77843
MFD(Multi Function Device) chip`s regulators.
The Max77843 has two voltage regulators for USB safeout.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of calling device_create_file() manually after the device
registration, put all in attribute groups and filter the unwanted ones
via is_visible callback. This not only simplifies the code but also
avoids the possible race between the device registration and sysfs
registration.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make it possible to specify the supply of a regulator, through the
vin-supply property in dt.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Refactor drms_uA_update() slightly to allow regulator_set_optimum_mode()
to utilize the same logic instead of duplicating it.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
"force_mode" is a u32 so it is never "< 0", but because of type
promotion then comparing "== -1" will do what we want.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch for adding gpio control about enable/disable of buck.
Signed-off-by: James Ban <james.ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Ensure get_voltage return correct voltage if set_voltage fails.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code is using devm_regulator_register(), so we don't need to store *rdev
in struct lp872x for clean up.
Also clean up lp872x_probe() a bit to remove unnecessary goto and num_regulators
variable.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds the missing state parameter to the call down to the RPM. This
is currently hard coded to the active state, as that's all we're
supporting at this moment.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is a patch for fixing unmatched of_node.
Signed-off-by: James Ban <james.ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Update documentation for regulator_register() function after renaming
its argument.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A common simplified DT parsing code for regulators was introduced in
commit a0c7b164ad ("regulator: of: Provide simplified DT parsing
method"). This is very similar to our own code, so get rid of ours
and use the common code.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fills the DT related fields in the regulator descriptors,
which can then be used by the regulator core's simplified DT code.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Add enable control over GPIO for regulators supporting this: LDO20,
LDO21, LDO22, buck8 and buck9.
This is needed for proper (and full) configuration of the Maxim 77686
PMIC without creating redundant 'regulator-fixed' entries.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Copy the 'regulator_config' structure passed to regulator_register()
function so the driver could safely modify it after parsing init data.
The driver may want to change the config as a result of specific init
data parsed by regulator core (e.g. when core handled parsing device
tree).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds missing registers('BUCK7_SW' & 'LDO29_CTRL'). Since BUCK7 has
1 more register (BUCK7_SW) than others, register offset should
be added one more for which has bigger address than BUCK7 registers.
Fixes: 76b9840b24ae04(regulator: s2mps11: Add support S2MPS13 regulator device)
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
The regulator framework maintains a list of consumer regulators
for a regulator device and protects it from concurrent access using
the regulator device's mutex lock.
In the case of regulator_put() the consumer is removed and regulator
device's parameters are updated without holding the regulator device's
mutex. This would lead to a race condition between the regulator_put()
and any function which traverses the consumer list or modifies regulator
device's parameters.
Fix this race condition by holding the regulator device's mutex in case
of regulator_put.
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The regmap_config struct may be const because it is not modified by
the driver and regmap_init() accepts pointer to const. Make struct
regulator_ops const as well.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const. Make struct
regulator_ops const as well.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const. Make const also
slew_rates array.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
One fix here, a fix for the voltage mapping on one of the s2mps11
regulators which broke systems using it including apparently the Gear 2
smartwatches.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUoX7vAAoJECTWi3JdVIfQtcEH/junzpSCOwIrI8NG9/ZF0xt5
rLB1SlDxtiSPv6eFA+KXYYmO8VNjZ1g+NN1PoeSNgAK08YzG9IUHIqI1L1iDe2qG
2vpPY++Rg5eWPY79Sa9oy/+2zmFmUh3t+Shv7p3WC1Q8GES4bD6dm/QVxykh16nW
nDGYZN981THIHS9xPKsmvCbHMp6PknDZkqO9Umzflt7cYgzgFP8xTaTlb4vkwTza
3ZjGnEMIe1ldkLGFEJmdsSMro07hKzVYk8e3auOK+gAMpO+QjpY8WxuarmpQBPLx
GddKhfkox5HNUxm9jRp0jivgi8YXD4a1lXzwXpxSihax1Q/Q/v00yoJ6selRQXg=
=/mpj
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull one regulator fix from Mark Brown:
"One fix here, a fix for the voltage mapping on one of the s2mps11
regulators which broke systems using it including apparently the
Gear 2 smartwatches"
* tag 'regulator-v3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: s2mps11: Fix dw_mmc failure on Gear 2
This patch initializes regulator_no to -1 to avoid extra subtraction
operation performed every time we register a regulator and avoid negative
regulator no in its name.
Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch is add regulator_nodes/of_match in the regulator descriptor
for using information from DT instead of sppecific codes.
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
"isil" and "isl" prefixes are used at various locations inside the kernel
to reference Intersil corporation. This patch is part of a series fixing
those locations were "isl" is used in compatible strings to use the now
expected "isil" prefix instead (NASDAQ symbol for Intersil and most used
version). The old compatible string is kept for backward compatibility.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch is add regulator_nodes/ofmatch in the regulator descriptor
for using information from DT instead of specific codes.
That will be used regulation_of_get_init_data function for get regulator
property on device tree. Using that make driver simpler.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes, just
removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There are
some ath9k patches coming in through this tree that have been acked by
the wireless maintainers as they relied on the debugfs changes.
Everything has been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlSOD20ACgkQMUfUDdst+ylLPACg2QrW1oHhdTMT9WI8jihlHVRM
53kAoLeteByQ3iVwWurwwseRPiWa8+MI
=OVRS
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core update from Greg KH:
"Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes,
just removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There
are some ath9k patches coming in through this tree that have been
acked by the wireless maintainers as they relied on the debugfs
changes.
Everything has been in linux-next for a while"
* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
fs: debugfs: add forward declaration for struct device type
firmware class: Deletion of an unnecessary check before the function call "vunmap"
firmware loader: fix hung task warning dump
devcoredump: provide a one-way disable function
device: Add dev_<level>_once variants
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
ath: use seq_file api for ath9k debugfs files
debugfs: add helper function to create device related seq_file
drivers/base: cacheinfo: remove noisy error boot message
Revert "core: platform: add warning if driver has no owner"
drivers: base: support cpu cache information interface to userspace via sysfs
drivers: base: add cpu_device_create to support per-cpu devices
topology: replace custom attribute macros with standard DEVICE_ATTR*
cpumask: factor out show_cpumap into separate helper function
driver core: Fix unbalanced device reference in drivers_probe
driver core: fix race with userland in device_add()
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
fs: sysfs: return EGBIG on write if offset is larger than file size
...
Invalid buck4 configuration for linear mapping of voltage in S2MPS14
regulators caused boot failure on Gear 2 (dw_mmc-exynos):
[ 3.569137] EXT4-fs (mmcblk0p15): mounted filesystem with ordered data mode. Opts: (null)
[ 3.571716] VFS: Mounted root (ext4 filesystem) readonly on device 179:15.
[ 3.629842] mmcblk0: error -110 sending status command, retrying
[ 3.630244] mmcblk0: error -110 sending status command, retrying
[ 3.636292] mmcblk0: error -110 sending status command, aborting
Buck4 voltage regulator has different minimal voltage value than other
bucks. Commit merging multiple regulator description macros caused to
use linear_min_sel from buck[1235] regulators as value for buck4. This
lead to lower voltage of buck4 than required.
Output of the buck4 is used internally as power source for
LDO{3,4,7,11,19,20,21,23}. On Gear 2 board LDO11 is used as MMC
regulator (V_EMMC_1.8V).
Fixes: 5a867cf288 ("regulator: s2mps11: Optimize the regulator description macro")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Fixes the following sparse warnings:
drivers/regulator/rk808-regulator.c💯5: warning:
symbol 'rk808_set_suspend_voltage' was not declared. Should it be static?
drivers/regulator/rk808-regulator.c:115:5: warning:
symbol 'rk808_set_suspend_enable' was not declared. Should it be static?
drivers/regulator/rk808-regulator.c:126:5: warning:
symbol 'rk808_set_suspend_disable' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Mark Brown <broonie@kernel.org>
The main thing this time around is support for suspend mode
configuration from DT which will enable some very useful power savings
on systems where we can't rely on the bootloader configuration. We
still don't really support dynamic configuration of this at runtime,
that may come later if there is any demand.
- Support for specifying the target regulation mode and voltage during
system suspend via DT, enabling power savings in that mode.
- Reduce the default verbosity of the logging on boot, improving boot
times especially for systems with very large numbers of regulators.
- Lots of cleanups and fixes for Maxim PMIC drivers.
- New driver for Richtek RT5033.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUhaLEAAoJECTWi3JdVIfQMIEH/0n/0TJngSaoifV72PCkICdx
GbNs2bUkjuNAbYw6S6xmbA6MYPEllGiFnmJPRjV41qf0a1TTG/vam3fjeaBao7En
DxEBsz22iuBM4wmOSEKTsDtTRuiX170cqKKWZ4ugFo/uaDinueW2tz0Uzvz05or5
bSxT8hbeYerNksb13mn7OjW8r0rCE24w1K669MZgwp0uuIY+NKUTnwT4TqMzDo5c
OT4RQ2XZAQOhOfqS4VTR07Ab8PzGQd4zzmTYljqd2MKL7ubKz41vNSnGHwPdrTH1
FeQ9Q/JZl0W6zwUjltGfZLjDewD1Kcb+3gdgCiD+V8wQQ1xg8H15nql4WpK6P8s=
=bMvT
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"The main thing this time around is support for suspend mode
configuration from DT which will enable some very useful power savings
on systems where we can't rely on the bootloader configuration. We
still don't really support dynamic configuration of this at runtime,
that may come later if there is any demand.
Summary:
- Support for specifying the target regulation mode and voltage
during system suspend via DT, enabling power savings in that mode.
- Reduce the default verbosity of the logging on boot, improving boot
times especially for systems with very large numbers of regulators.
- Lots of cleanups and fixes for Maxim PMIC drivers.
- New driver for Richtek RT5033"
* tag 'regulator-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (62 commits)
regulator: core: Fix regualtor_ena_gpio_free not to access pin after freeing
regulator: sky81452: Modify Device Tree structure
regulator: sky81452: Modify Device Tree structure
dt-bindings: Update documentation for "system-power-controller" and fix misspellings
of: Rename "poweroff-source" property to "system-power-controller"
regulator: max77686: Remove support for board files
regulator: max77802: Remove support for board files
regulator: max77802: Fill regulator modes translation callback
regulator: max77802: Document binding for regulator operating modes
regulator: of: Add support for parsing initial and suspend modes
regulator: of: Pass the regulator description in the match table
regulator: of: Add regulator desc param to of_get_regulator_init_data()
regulator: Add mode mapping function to struct regulator_desc
regulator: Document binding for initial and suspend modes
regulator: core: Add PRE_DISABLE notification
regulator: gpio: fix parsing of gpio list
regulator: rpm: add support for RPM-controller SMB208
regulator: da9063: Do not transform local IRQ to virtual
regulator: sky81452: Modify dependent Kconfig symbol
regulator: rt5033: Add RT5033 Regulator device driver
...
After freeing pin from regulator_ena_gpio_free, loop can access
the pin. So this patch fixes not to access pin after freeing.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It reverts commit a4b4e0461e ("of: Add standard property for poweroff capability").
As discussed on the mailing list, it makes more sense to rename back to the
old established property name, without the vendor prefix. Problem being that
the word "source" usually tends to be used for inputs and that is out of control
of the OS. The poweroff capability is an output which simply turns the
system-power off. Also, this property might be used by drivers which power-off
the system and power back on subsequent RTC alarms. This seems to suggest to
remove "poweroff" from the property name and to choose "system-power-controller"
as the more generic name. This patchs adds the required renaming changes and
defines an helper function which checks if this property is set.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver is used only on Exynos based boards with DTS support.
Simplify the driver and remove dead (unused) entries in platform_data
structure.
Convert the driver to DTS-only version. Parse all regulators at once,
not one-by-one. Remove dependency on data provided by max77686 MFD
driver. Use new DT style parsing method for regulators init data.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver is used only on Exynos based boards with DTS support.
Simplify the driver and remove dead (unused) entries in platform_data
structure.
Convert the driver to DTS-only version. Parse all regulators at once,
not one-by-one. Remove dependency on data provided by max77686 MFD
driver. Use new DT style parsing method for regulators init data.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Stephen Boyd