The regulator_resolve_supply() function calls set_supply() which in turn
calls create_regulator() to allocate a supply regulator.
If an error occurs after set_supply() succeeded, the allocated regulator
has to be freed before propagating the error code.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When a regulator is unregistered with regulator_unregister(), a call to
regulator_put() is made for its input supply if there is one. This does
a module_put() to decrement the refcount of the module that owns the
supply but there isn't a corresponding try_module_get() in set_supply()
to make the calls balanced.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When resolving device supplies if we fail to look up the regulator we
substitute in the dummy supply instead if the system has fully specified
constraints. When resolving supplies for regulators we do not have the
equivalent code and instead just directly use the regulator_dev_lookup()
result causing spurious failures.
This does not affect DT systems since we are able to detect missing
mappings directly as part of regulator_dev_lookup() and so have appropriate
handling in the DT specific code.
Reported-by: Christian Hartmann <cornogle@googlemail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add lockdep_assert_held_once() to functions explicitly mentioning that
rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't
pollute the dmesg to much.
The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain
regulators calling regulator_notifier_call_chain() without rdev->mutex
held.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
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>
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>
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>
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>
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>
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 commit [39f802d6b6: '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>
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>
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>
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>
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>
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>
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>
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
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>
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>
Add a PRE_DISABLE notification so that consumers can use a
notifier to run any steps required to prepare for the
regulator being switched off. Since the regulator disable
can fail an abort notification is also added.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some systems have very large numbers of regulators so the constraint
logging done at startup can end up being a very big part of the boot
output which is both verbose and slows things down if the console is
a serial console. Lower to dev_dbg() instead, we may want to provide
a boot parameter to raise this in future but for now people can edit
the source.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Most drivers do not set the ena_gpio field of struct regulator_config
before passing it to the regulator core. This is fine as long as the
gpio identifier that is passed is a positive integer. But the gpio
identifier 0 is also valid. So we are not able to decide wether we got a
real gpio identifier or not based on a 0 in ena_gpio.
To be able to decide if it is a valid gpio that got passed, this patch
adds a ena_gpio_initialized field that should be set if was initialized
with a correct value, either a gpio >= 0 or a negative error number. The
core then checks if ena_gpio or ena_gpio_initialized before handling it
as a gpio. This way we maintain backwards compatibility and fix the
behaviour for gpio number 0.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
In some cases we need to know when a regulator is about to be changed.
Add a way for clients to be notified. Note that for set_voltage() we
don't necessarily know what voltage we'll end up with, so we tell the
client what the range will be so they can prepare.
Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie+linaro@kernel.org>
Commit 272e2315fa ("regulator: core: add const qualifier to ops in
struct regulator_desc") introduced const qualifier to ops in regulator_desc.
This patch adds 'const' to regulator_ops vars in newly added core APIs
for v3.17-rc1:
- regulator_get_hardware_vsel_register()
- regulator_list_hardware_vsel()
This patch also fix a build error in mc13892-regulator.c due to const
regulator_desc.ops. Modification of regulator_desc.ops' member fields is not
allowed.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Some regulator require a minimum delay between its disable and next enable.
This is to avoid damages when out-of-range frequent disable/enable of a
single regulator can bring to the regulator chip.
Add @off_on_delay to struct regulator_desc. Device drivers' can use this field
to set this guard time.
Add @last_off_jiffy to struct regulator_dev. When @off_on_delay is set by
driver, regulator core can store its last off (disable) time into this field.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
A common delay function can be helpful when implementing new features. Factor
it out to maximize code reusability.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
struct regulator_ops *ops is a member in struct regulator_desc, which gets
its value from individual regulator driver upon regulator_register() and
is used by regulator core APIs. It's not allowed for regulator core to
modify any of these callbacks in *ops. Add 'const' qualifier to enforce that.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Load switches are modeled as regulators but they just provide
the voltage of their parent input supply. So, the drivers for
these switches usually neither provide a .list_voltage handler
not set a .n_voltages count. But there is code in the kernel
that assumes that all regulators should be able to provide this
information (e.g: cpufreq and mmc subsystems).
If the voltage count and list are not available for a regulator
and it has a parent input supply, then use the parent values.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@linaro.org>
Load switches are modeled as regulators but they just provide
the voltage of their parent input supply. So the drivers for
these switches usually don't provide a .get_voltage function
handler but there is code in the kernel that assumes that all
regulators should be able to provide its current voltage rail.
So, if the output voltage for a regulator is not available and
it has a parent supply, then pass the voltage of its parent.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add helper functions that allow regulator consumers to obtain low-level
details about the regulator hardware, like the voltage selector register
address and such. These details can be useful when configuring hardware
or firmware that want to do low-level access to regulators, with no
involvement from the kernel.
The use-case for Tegra is a voltage-controlled oscillator clocksource
which has control logic to change the supply voltage via I2C to achieve
a desired output clock rate.
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Convert the regulator GPIO handling to use a gpio descriptor rather than
numbers. This allows us to revise the interfaces to permit all GPIOs
to be used with the regulator core.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Mark Brown <broonie@linaro.org>
With commit 064d5cd110
(regulator: core: Fix the init of DT defined fixed regulators)
We ensure that regulator must be capable of providing it's current
voltage when constraints are used, however adding the return value in
the print is a little more informative to explain the nature of the
failure involved.
So, instead of providing message such as:
smps9: failed to get the current voltage
having error value added to the message such as:
smps9: failed to get the current voltage(-22)
is a little more informative for debugging the error.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
When a regulator is defined using DT and it has a single voltage the
regulator init always tries to apply this voltage. However it fails if
the regulator isn't settable because it is using an internal low level
function. To overcome this we now first query the regulator and only
set it if needed.
Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator_init_complete does a scan of regulators which dont have
always-on or consumers are automatically disabled as being unused.
However, with deferred probing, late_initcall() is too soon to
declare a regulator as unused as the regulator itself might not
have registered due to defferal - Example: A regulator deffered due
to i2bus not available which in turn is deffered due to pinctrl
availability.
Since deferred probing is done in late_initcall(), do the cleanup of
unused regulators by regulator_init_complete in late_initcall_sync
instead of late_initcall.
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
[nm@ti.com: minor rewording]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
In the spirit of conservatism that governs our general approach to
permissions it is better if we don't touch regulators we weren't explicitly
given permissions to control. This avoids the need to explicitly specify
unknown regulators in DT as always on, if a regulator is not otherwise
involved in software control it can be omitted from the DT.
Regulators explicitly given constraints in DT still need to have an always
on constraint specified as before.
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator_get_optional() doesn't hold an exclusive reference to
the regulator. Fix the documentation and reword the exclusive
documentation to fix the grammatical error "this reference is
held".
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Use map_voltage_linear_range() if list_voltage_linear_range() is in use and
nothing is set.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently the regulator core does not take an additional reference to
the of_node it is passed. This means that the caller must ensure that
the of_node is valid for the duration of the regulator's existance.
It is reasonable for the framework to assume it is passed a valid
of_node but seems onerous for it to assume the caller will keep the node
valid for the life-time of the regulator, especially when
devm_regulator_register is used and there will likely be no code in the
driver called at the point it would be safe to put the of_node.
This patch adds an additional of_node_get when the regulator is
registered and an of_node_put when it is unregistered in the core. This
means individual drivers are free to put their of_node references at the
end of probe letting the regulator core handling it from there. This
simplifies code on the driver side.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
A couple of fixes here which ensure that regulators using the core
support for GPIO enables work in all cases by ensuring that helpers are
used consistently rather than open coding in places and hence not having
GPIO support in some of them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTFU8hAAoJELSic+t+oim9SmgP+wVddsDf+4igNw6Lo5JTW368
aY5m6ulB8XIwCtYQhsLHzUIcVbY3/p1zY+cdi0VmmINja3qHCE30H4Asq/LjcT9U
1DI4Z20CgUOST5PZDKK5+sILSro/AxfsnGyIIj5F9YhX3wl46jUfrw2us5fbPDJU
ny3NnUM8R/fFIzOd0ishxcY3L1GSe/4a2Ob9uqsq/tPWAeHKoDVAefN6wUeFhulI
0CVlrRaL/FGnnbdcQ+TZgKxm7TXRrUkLqrUR2RxZr7Olk2ZEQhT18OcncdFesIM2
F9GuXE+QL04QrTeLVOsPXWqmcS0UzJqy2luNBbMfOQ/K/JY/lyL6wrLlVi4snfcX
v2GrrPQTJ13IU/itBtAMOtWmjJlg3r91vYgqXu05T/7Lt2DCkp3YfUZ6UDjwDe1c
K4l/l/VwbUPur3NhMupZO+Ohfe+grp2+UPCUC6McmNWAEJSZPoGA7lNo618ZfrQQ
x3ByYcIit9dpTNw6j0rWbgOqsZ4VscW32gSJd+QXAqxolbvnbDnRDHNjS4O9sx1k
rHHZk8oDvhkfp4ptSkWQeuDUEAZsuidlonQMdfQl1+T2yZnxE19G3CwmPA94itAk
i8owlr+Fp3YcDoE8jaRf2JFKiKHC5f3dF5ceDqFufMk0a+nqEGkOj/RmGch3y3wz
itzqO0PcRi/YEsoTW7dt
=Vx3C
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of fixes here which ensure that regulators using the core
support for GPIO enables work in all cases by ensuring that helpers
are used consistently rather than open coding in places and hence not
having GPIO support in some of them"
* tag 'regulator-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Replace direct ops->disable usage
regulator: core: Replace direct ops->enable usage
There are many places where ops->disable is called directly. Instead we
should use _regulator_do_disable() which also handles gpio regulators.
To be able to use the wrapper function from _regulator_force_disable(),
I moved the _notifier_call_chain() call from _regulator_do_disable() to
_regulator_disable(). This way, _regulator_force_disable() can use
different flags for _notifier_call_chain() without calling it twice.
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
There are some direct ops->enable in the regulator core driver. This is
a potential issue as the function _regulator_do_enable() handles gpio
regulators and the normal ops->enable calls. These gpio regulators are
simply ignored when ops->enable is called directly.
One possible bug is that boot-on and always-on gpio regulators are not
enabled on registration.
This patch replaces all ops->enable calls by _regulator_do_enable.
[Handle missing enable operations -- broonie]
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: Handle invalid enable operation for always/boot on regulators
Signed-off-by: Mark Brown <broonie@linaro.org>
Change "dummy supplies not allowed" error message to warning instead, as this
is a just warning message with no change to the behavior.
[Added a CC to stable since some other bug fixes cause this to come up
more frequently on PCs which is how it was noticed -- broonie]
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make it okay to call regulator_set_voltage on regulators with fixed
voltage if the requested range overlaps the current/configured voltage.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Once we have full constraints then all supply mappings should be known to
the regulator API. This means that we should treat failed lookups as fatal
rather than deferring in the hope of further registrations but this was
broken by commit 9b92da1f12 "regulator: core: Fix default return
value for _get()" which was targeted at DT systems but unintentionally
broke non-DT systems by changing the default return value.
Fix this by explicitly returning -EPROBE_DEFER from the DT lookup if we
find a property but no corresponding regulator and by having the non-DT
case default to -ENODEV when we have full constraints.
Fixes: 9b92da1f12 "regulator: core: Fix default return value for _get()"
Signed-off-by: Mark Brown <broonie@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org
Fix the following checkpatch errors and warnings.
ERROR: trailing whitespace
ERROR: return is not a function, parentheses are not required
WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Only print an error when _regulator_get() is expected to return a valid
regulator, that is when _regulator_get() is called from regulator_get() and
we're not using the dummy because we don't have full-constraints, or when
_regulator_get() is called from regulator_get_exclusive() in which case
returning a dummy is not allowed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Eliminate the gap between DT becoming available and this being used to say
we have full constraints by checking directly for DT every time we check
for full constraints. This improves interoperaton with optional regulator
support.
Signed-off-by: Mark Brown <broonie@linaro.org>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Simple code reorganisation so we can change the logic for deciding what
full constraints are more easily.
Signed-off-by: Mark Brown <broonie@linaro.org>
Commit c368e5fc2a "regulator: fixed:
get rid of {get|list}_voltage()" broke regulator_list_voltage() for
the fixed regulator, because an earlier commit
5a523605af "regulator: core: provide
fixed voltage in desc for single voltage rail" missed to add support
for the fixed-voltage special case to that function. This patch
fixes that regression.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
These patches add the ability to create an alternative device on which
a lookup for a certain supply should be conducted.
A common use-case for this would be devices that are logically
represented as a collection of drivers within Linux but are are
presented as a single device from device tree. It this case it is
necessary for each sub device to locate their supply data on the main
device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This helps people spot if they have missed a supply from a device tree or
equivalent data structure.
Suggested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Keep busy-wait looping to a minimum while waiting for a regulator to
ramp-up to the target voltage. This follows the guidelines set forth
in Documentation/timers/timers-howto.txt and assumes that regulators
are never enabled in atomic context.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Ensure that the return value is always set when we return now that the
logic has changed for regulator_get_optional() so we don't get missing
codes leaking out.
Reported-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Now that we are defaulting to providing dummy regulators fix the logic
for substituting a dummy by making the default return code -EPROBE_DEFER.
Reported-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Machine constraints is configured during regulator register. If current
constraints are provided through machine constraints then it is observed
that sometime the current configured on rail is out of range what machine
constraint has.
Set the current constraints when setting machine constraints to make
sure that rail's current is within the range of given machine constraints.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The turn-on time of the regulator depends on the regulator device's
electrical characteristics. Sometimes regulator turn-on time also
depends on the capacitive load on the given platform and it can be
more than the datasheet value.
The driver provides the enable-time as per datasheet.
Add support for configure the enable ramp time through regulator
constraints so that regulator core can take this value for enable
time for that regulator.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
No boards have used this functionality and the new default of providing
dummy regulators by default provides a better solution to the problem it
was trying to solve.
Signed-off-by: Mark Brown <broonie@linaro.org>
When a system has said that it has fully specified constraints for its
regulators it is still possible that some supplies may be missing,
especially if regulator support has been added to a driver after the
board was integrated. We can handle such situations more gracefully by
providing a dummy regulator.
Unless the caller has specifically indicated that the system design may
not include a given regulator by using regulator_get_optional() or that
it needs its interactions to have an effect using regulator_get_exclusive()
provide a dummy regulator if we can't locate a real one.
The kconfig option REGULATOR_DUMMY that provided similar behaviour for all
regulators has been removed, systems that need it should flag that they
have full constraints instead.
Signed-off-by: Mark Brown <broonie@linaro.org>
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>
The implementation of devm_regulator_get, devm_regulator_get_exclusive and
devm_regulator_get_optional are almost the same.
Introduce _devm_regulator_get helper function and refactor the code.
Also move devm_regulator_get_exclusive to proper place, put it after
regulator_get_exclusive() function.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Many regulator drivers have a remove function that consists solely of
calling regulator_unregister() so provide a devm_regulator_register()
in order to allow this repeated code to be removed and help eliminate
error handling code.
Signed-off-by: Mark Brown <broonie@linaro.org>
If given rail has the single voltage (n_voltages = 1) then provide the
rail voltage through regulator descriptor so that core can use this
value for finding voltage.
This will avoid the implementation of the callback for get_voltage() or
list_voltage() callback on regulator driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add a resource managed regulator_get_exclusive()
Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
Move regulator_list_voltage_{linear,linear_range,table} helper functions to
helpers.c.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
While the majority of supplies on devices are mandatory and can't be
physically omitted for electrical reasons some devices do have optional
supplies and need to know if they are missing, MMC being the most common
of these.
Currently the core accurately reports all errors when regulators are
requested since it does not know if the supply is one that must be provided
even if by a regulator software does not know about or if it is one that
may genuinely be disconnected. In order to allow this behaviour to be
changed and stub regulators to be provided in the former case add a new
regulator request function regulator_get_optional() which provides a hint
to the core that the regulator may genuinely not be connected.
Currently the implementation is identical to the current behaviour, future
patches will add support in the core for returning stub regulators in the
case where normal regulator_get() fails and the board has requested it.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Chris Ball <cjb@laptop.org>
The dev_attrs field of struct class is going away soon, dev_groups
should be used instead. This converts the regulator class code to use
the correct field.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Current code does not allow fixed voltage range in multiple linear ranges.
If someone does set range->uV_step == 0 in one of the linear ranges, we hit
divided by zero bug. This patch fixes this issue.
For fixed voltage range, return any selector means the same voltage.
Thus just return 0.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.
Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
In function _regulator_do_set_voltage(), old_selector gets intialised only
if (_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel &&
rdev->desc->ops->get_voltage_sel)) is true.
Before calling set_voltage_time_sel() we checks if (old_selector >= 0) and it
will true if it got intialised properly. so we don't need to check again
_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel before
calling set_voltage_time_sel().
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Some hardwares support disabling ramp delay, so adding ramp_disable flag to
constraints. It will be used to figure out whether ramp_delay in constraints
is explicitly set to zero or its unintialized (zero by default).
And we don't need to call set_voltage_time_sel() for regulators for whom ramp
delay is disabled in constraints.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Many regulators have several linear ranges of selector with different
step sizes, for example offering better resolution at lower voltages.
Provide regulator_{map,list}_voltage_linear_range() allowing these
regulators to use generic code. To do so a table of regulator_linear_range
structs needs to be pointed to from the descriptor.
This was inspired by similar code included in a driver submission from
Chao Xie and Yi Zhang at Marvell.
Signed-off-by: Mark Brown <broonie@linaro.org>
Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators. This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Andrew Chew <achew@nvidia.com>
Cc: Matthew Longnecker <mlongnecker@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add a couple kernel-doc lines to get rid of kernel-doc generation
warnings, no functional change.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A lot of regulator hardware has ascendant voltage list.
This patch adds regulator_map_voltage_ascend() and export it.
Drivers that have ascendant voltage list can use this as their map_voltage()
operation, this is more efficient than default regulator_map_voltage_iterate()
function.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
commit 6d191a5fc7
(regulator: core: Don't defer probe if there's no DT binding for a supply)
Attempted to differentiate between regulator_get() with an actual
DT binding for the supply and when there is none to avoid unnecessary
deferal.
However, ret value supplied by regulator_dev_lookup() is being
ignored by regulator_get(). So, exit with the appropriate return value.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Regulator drivers may specify regulator_desc->supply_name which
regulator_register() will use to find the supply node for a regulator.
If no supply was specified in the device tree or the supply has yet
to be registered regulator_register() will fail, deferring the probe
of the regulator. In the case where no supply node was specified in the
device tree, there is no supply and it is pointless to try and find one
later, so go ahead and add the regulator without the supply.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add enable_is_inverted flag to indicate set enable_mask bits to disable
when using regulator_enable_regmap and friends APIs.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The regulator_dev has regulator_enable_gpio structure.
'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.
regulator_dev ---> regulator_enable_gpio
.ena_gpio .gpio
.ena_gpio_invert .ena_gpio_invert
Pointer, 'ena_pin' is used for checking valid enable GPIO pin.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
To support shared enable GPIO pin, replace GPIO code with new static functions
Reference count: 'enable_count'
Balance the reference count of each GPIO and actual pin control.
The count is incremented with enabling GPIO.
On the other hand, it is decremented on disabling GPIO.
Actual GPIO pin is enabled at the initial use.(enable_count = 0)
The pin is disabled if it is not used(shared) any more. (enable_count <=1)
Regardless of the enable count, update GPIO state of the regulator.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A Regulator can be enabled by external GPIO pin.
This is configurable in the regulator_config.
At this moment, the GPIO can be owned by only one regulator device.
In some devices, multiple regulators are enabled by shared one GPIO pin.
This patch extends this limitation, enabling shared enable GPIO of regulators.
New list for enable GPIO: 'regulator_ena_gpio_list'
This manages enable GPIO list.
New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
The enable count is used for balancing GPIO control count.
This count is incremented when GPIO is enabled.
On the other hand, it's decremented when GPIO is disabled.
Reference count: 'request_count'
The reference count, 'request_count' is incremented/decremented on
requesting/freeing the GPIO. This count makes sure only free the GPIO
when it has no users.
How it works
If the GPIO is already used, skip requesting new GPIO usage.
The GPIO is new one, request GPIO function and add it to the list of
enable GPIO.
This list is used for balancing enable GPIO count and pin control.
Updating a GPIO and invert code moved
'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
new function, regulator_ena_gpio_request().
Use regulator_enable_pin structure rather than regulator_dev.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Unwinding code disables all successfully enabled regulators.
Error is logged for every failed regulator.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
commit f59c8f9f (regulator: core: Support bypass mode)
has a short documentation error around the regulator_allow_bypass
parameter 'enable' which is documented as 'allow'.
This generates kernel-doc warning as follows:
./scripts/kernel-doc drivers/regulator/core.c >/dev/null
Warning(drivers/regulator/core.c:2841): No description found for parameter 'enable'
Warning(drivers/regulator/core.c:2841): Excess function parameter 'allow' description in 'regulator_allow_bypass'
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
commit dd8004af: 'regulator: core: Log when a device causes a voltage
constraint fail', tried to print out some information about the
check consumer min/max uV fixup, however, it uses a garbage pointer
left over from list_for_each_entry leading to boot messages in the
form:
'[ 2.079890] <RANDOM ASCII>: Restricting voltage, 3735899821-4294967295uV'
Because it references regulator->dev, it could potentially read memory from
anywhere causing a panic.
This patch instead uses rdev and the updated min/max uV values.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Optimize _regulator_do_set_voltage() for the case selector is equal to
old_selector. Since the voltage does not change, we don't need to call
set_voltage_sel() and set_voltage_time_sel() in this case.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator_register() does not return 0 on success, fix the comment.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some DVM regulators needs to update apply_bit after setting vsel_reg to
initiate voltage change on the output. This patch adds apply_reg and
apply_bit to struct regulator_desc and update
regulator_set_voltage_sel_regmap() to set apply_bit of apply_reg when
apply_bit is set.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Regulator drivers with continuous_voltage_range flag set allows not setting
n_voltages. Thus if continuous_voltage_range is set, check the constraint range
instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Having a linear_min_sel setting means the first linear_min_sel selectors are
invalid. We need to subtract linear_min_sel when use n_voltages to determinate
if regulator can change voltage.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Introduce a regulator_can_change_voltage() function for the subsytems or
drivers which might check if applying voltage change is possible and use
special workaround code when the driver is used with fixed regulators or
regulators with disabled ability to change the voltage.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some drivers (at least 3 drivers) have such variant of linear mapping that
the first few selectors are invalid and the reset are linear mapping.
Let's support this case in core.
This patch adds linear_min_sel in struct regulator_desc,
so we can allow specific minimal selector for starting linear mapping.
Then extends regulator_[map|list]_voltage_linear() to support this feature.
Note that for selectors less than min_linear_index, we need count them to
n_voltages so regulator_list_voltage() won't fail while checking the boundary
for selector before calling list_voltage callback.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator_is_supported_voltage() should return true only if the voltage
of fixed/constant regulator is between min_uV and max_uV.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
When regulator_register fails and exits through the scrub path the
regulator_put function was called whilst holding the
regulator_list_mutex, causing deadlock.
This patch adds a private version of the regulator_put function which
can be safely called whilst holding the mutex, replacing the
aforementioned call.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If the gpio_request_one() fails, or returns EPROBE_DEFER, the
regulator must be device_unregister()ed. When this is not done,
there are WARNING: from sysfs:
WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x238/0x268()
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some regulators can set any voltage within the constraints range,
not being limited to specified operating points.
This patch makes it possible to describe such regulator and makes
the regulator_is_supported_voltage() function behave correctly.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Pull workqueue changes from Tejun Heo:
"This is workqueue updates for v3.7-rc1. A lot of activities this
round including considerable API and behavior cleanups.
* delayed_work combines a timer and a work item. The handling of the
timer part has always been a bit clunky leading to confusing
cancelation API with weird corner-case behaviors. delayed_work is
updated to use new IRQ safe timer and cancelation now works as
expected.
* Another deficiency of delayed_work was lack of the counterpart of
mod_timer() which led to cancel+queue combinations or open-coded
timer+work usages. mod_delayed_work[_on]() are added.
These two delayed_work changes make delayed_work provide interface
and behave like timer which is executed with process context.
* A work item could be executed concurrently on multiple CPUs, which
is rather unintuitive and made flush_work() behavior confusing and
half-broken under certain circumstances. This problem doesn't
exist for non-reentrant workqueues. While non-reentrancy check
isn't free, the overhead is incurred only when a work item bounces
across different CPUs and even in simulated pathological scenario
the overhead isn't too high.
All workqueues are made non-reentrant. This removes the
distinction between flush_[delayed_]work() and
flush_[delayed_]_work_sync(). The former is now as strong as the
latter and the specified work item is guaranteed to have finished
execution of any previous queueing on return.
* In addition to the various bug fixes, Lai redid and simplified CPU
hotplug handling significantly.
* Joonsoo introduced system_highpri_wq and used it during CPU
hotplug.
There are two merge commits - one to pull in IRQ safe timer from
tip/timers/core and the other to pull in CPU hotplug fixes from
wq/for-3.6-fixes as Lai's hotplug restructuring depended on them."
Fixed a number of trivial conflicts, but the more interesting conflicts
were silent ones where the deprecated interfaces had been used by new
code in the merge window, and thus didn't cause any real data conflicts.
Tejun pointed out a few of them, I fixed a couple more.
* 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (46 commits)
workqueue: remove spurious WARN_ON_ONCE(in_irq()) from try_to_grab_pending()
workqueue: use cwq_set_max_active() helper for workqueue_set_max_active()
workqueue: introduce cwq_set_max_active() helper for thaw_workqueues()
workqueue: remove @delayed from cwq_dec_nr_in_flight()
workqueue: fix possible stall on try_to_grab_pending() of a delayed work item
workqueue: use hotcpu_notifier() for workqueue_cpu_down_callback()
workqueue: use __cpuinit instead of __devinit for cpu callbacks
workqueue: rename manager_mutex to assoc_mutex
workqueue: WORKER_REBIND is no longer necessary for idle rebinding
workqueue: WORKER_REBIND is no longer necessary for busy rebinding
workqueue: reimplement idle worker rebinding
workqueue: deprecate __cancel_delayed_work()
workqueue: reimplement cancel_delayed_work() using try_to_grab_pending()
workqueue: use mod_delayed_work() instead of __cancel + queue
workqueue: use irqsafe timer for delayed_work
workqueue: clean up delayed_work initializers and add missing one
workqueue: make deferrable delayed_work initializer names consistent
workqueue: cosmetic whitespace updates for macro definitions
workqueue: deprecate system_nrt[_freezable]_wq
workqueue: deprecate flush[_delayed]_work_sync()
...
Many regulators support a bypass mode where they simply switch their
input supply to the output. This is mainly used in low power retention
states where power consumption is extremely low so higher voltage or
less clean supplies can be used.
Support this by providing ops for the drivers and a consumer API which
allows the device to be put into bypass mode if all consumers enable it
and the machine enables permission for this.
This is not supported as a mode since the existing modes are rarely used
due to fuzzy definition and mostly redundant with modern hardware which is
able to respond promptly to load changes.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Graeme Gregory <gg@slimlogic.co.uk>
If the device doesn't have a regmap specified by the driver and we can't
find one on the device itself try its parent, providing a useful defualt
for many MFDs.
[Rewrite commit message -- broonie]
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Users (especially framework code) may end up passing in a zero deferral
time depending on runtime conditions or configuration. If they do then
just call regulator_disable() directly to save scheduling.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
If a regulator only supports a single voltage list_voltage() can be used
to report what that voltage is so add this as one of the criteria for
creating the microvolts file in sysfs.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fix regulator kernel-doc warnings:
Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev'
Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
flush[_delayed]_work_sync() are now spurious. Mark them deprecated
and convert all users to flush[_delayed]_work().
If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant and the regular flushes guarantee that the work item is
not pending or running on any CPU on return, so there's no reason to
use the sync flushes at all and they're going away.
This patch doesn't make any functional difference.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Mattia Dongili <malattia@linux.it>
Cc: Kent Yoder <key@linux.vnet.ibm.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Petr Vandrovec <petr@vandrovec.name>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Avi Kivity <avi@redhat.com>
Fix regulator kernel-doc warnings:
Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev'
Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Commit 65f735082d ("regulator: core: Add core support for GPIO controlled
enable lines") introduced enable gpio entry in regulator configuration
structure. Some drivers use '-1' as a placeholder for marking that such
gpio line is not available, because '0' is considered as a valid gpio
number. This patch fixes initialization of such drivers (like MAX8952
on UniversalC210 board), when '-1' is provided as enable gpio pin in the
regulator's platform data.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If the regulator doesn't supply a way of reading back the voltage but does
provide a list_voltage() operation then use that with a selector of zero
to read the voltage. Regulators doing this means that we have the list
operation there for consumers that want to configure themselves.
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This prevents the output of just
dummy:
in the boot log. Now it says:
regulator-dummy: no parameters
which at least doesn't make it look like an accidental printk and also doesn't
only use "dummy" which could mean anything.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is to address the following warning during compilation time: (Compile on x86_64)
CC drivers/regulator/core.o
drivers/regulator/core.c: In function '_regulator_do_set_voltage':
drivers/regulator/core.c:2183:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
This patch adds a temporary variable to avoid double cast.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When registering the regulator and setting supply for the regulator
then increment open_count to reflect correct number of users.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The most important feature of this patch set is the new async infrastructure
that makes sure async_synchronize_full() synchronizes all domains and allows
us to remove all the hacks (like having scsi_complete_async_scans() in the
device base code) and means that the async infrastructure will "just work" in
future. The rest is assorted driver updates (aacraid, bnx2fc, virto-scsi,
megaraid, bfa, lpfc, qla2xxx, qla4xxx) plus a lot of infrastructure work in
sas and FC.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJQDjDCAAoJEDeqqVYsXL0M/sMH/jVgBfF1mjR+DQuTscKyD21w
0BQLn5OmvDZDqo44iqQzNRObw7CxkBkUtHoozsknLijw+KggER653ZOAtUdIHfI/
/uo7iJQ3J3D/Ezm99HYSpZiF2juZwsBRtFBoKkGqOpMlzFUx5o4hUbH5OcINxnHR
VmvJU5K1kg8D77Q6zK+Atl14/Rfibc2IoufFmbYdplUAM/tV0BpBSSHJAJvqua76
NGMl4KJcPZnXe/4LXcxZia5A2efdFFEzaQ2mM9rUVEAgHDAxc0Zg9IoDhGd08FX4
G55NK+6+bKb9s7bgyva0T/iy817TRCzjteeYNFrb8nBRe7aQbAivaBHQFXIyvdQ=
=y2sh
-----END PGP SIGNATURE-----
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull first round of SCSI updates from James Bottomley:
"The most important feature of this patch set is the new async
infrastructure that makes sure async_synchronize_full() synchronizes
all domains and allows us to remove all the hacks (like having
scsi_complete_async_scans() in the device base code) and means that
the async infrastructure will "just work" in future.
The rest is assorted driver updates (aacraid, bnx2fc, virto-scsi,
megaraid, bfa, lpfc, qla2xxx, qla4xxx) plus a lot of infrastructure
work in sas and FC.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (97 commits)
[SCSI] Revert "[SCSI] fix async probe regression"
[SCSI] cleanup usages of scsi_complete_async_scans
[SCSI] queue async scan work to an async_schedule domain
[SCSI] async: make async_synchronize_full() flush all work regardless of domain
[SCSI] async: introduce 'async_domain' type
[SCSI] bfa: Fix to set correct return error codes and misc cleanup.
[SCSI] aacraid: Series 7 Async. (performance) mode support
[SCSI] aha152x: Allow use on 64bit systems
[SCSI] virtio-scsi: Add vdrv->scan for post VIRTIO_CONFIG_S_DRIVER_OK LUN scanning
[SCSI] bfa: squelch lockdep complaint with a spin_lock_init
[SCSI] qla2xxx: remove unnecessary reads of PCI_CAP_ID_EXP
[SCSI] qla4xxx: remove unnecessary read of PCI_CAP_ID_EXP
[SCSI] ufs: fix incorrect return value about SUCCESS and FAILED
[SCSI] ufs: reverse the ufshcd_is_device_present logic
[SCSI] ufs: use module_pci_driver
[SCSI] usb-storage: update usb devices for write cache quirk in quirk list.
[SCSI] usb-storage: add support for write cache quirk
[SCSI] set to WCE if usb cache quirk is present.
[SCSI] virtio-scsi: hotplug support for virtio-scsi
[SCSI] virtio-scsi: split scatterlist per target
...
This is in preparation for teaching async_synchronize_full() to sync all
pending async work, and not just on the async_running domain. This
conversion is functionally equivalent, just embedding the existing list
in a new async_domain type.
The .registered attribute is used in a later patch to distinguish
between domains that want to be flushed by async_synchronize_full()
versus those that only expect async_synchronize_{full|cookie}_domain to
be used for flushing.
[jejb: add async.h to scsi_priv.h for struct async_domain]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state
doesn't really apply.
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Case REGULATOR_STATUS_STANDBY -> REGULATOR_MODE_STANDBY.
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Since DT doesn't provide an idiomatic mechanism for enabling full
constraints and since it's much more natural with DT to provide them
just assume that a DT enabled system has full constraints.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
With changes introduced by commit 222cc7b (regulator: core: Allow
multiple requests of a single supply mapping) on create_regulator,
regulator_put needs a corresponding update on sysfs entry removing.
Also regulator->dev still needs to get assigned in create_regulator,
otherwise, sysfs_remove_link call in regulator_put will get bypassed.
Reported-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is very common for regulators to support having their enable signal
controlled by a GPIO. Since there are a bunch of fiddly things to get
right like handling the operations when the enable signal is tied to
a rail and it's just replicated code add support for this to the core.
Drivers should set ena_gpio in their config if they have a GPIO control,
using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for
the initial state) and ena_gpio_invert if the GPIO is active low. The
core will then override any enable and disable operations the driver has
and instead control the specified GPIO.
This will in the future also allow us to further extend the core by
identifying when several enable signals have been tied together and
handling this properly.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Create new _regulator_do_enable() and _regulator_do_disable() operations
which deal with the mechanics of performing the enable and disable, partly
to cut down on the levels of indentation and partly to support some future
work.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Many regulators have a fixed specification for their enable time. Allow
this to be set in the regulator_desc as a number to save them having to
implement an explicit operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Lots of regulator drivers have checks in their map_voltage() functions
to verify that the result of the mapping is in the range originally
specified. Factor these out in the core and provide a bit of extra
defensiveness for other drivers by doing the check in the core.
Since we're now doing a list_voltage() earlier move the current mapping
back to a voltage out into the set_voltage() call to save redoing it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently regulator_is_supported_voltage() works by enumerating the set
of voltages which can be set by the regulator but the checks we're doing
to impose constraints mean that if we can't vary the voltage we'll not
report any voltages as supported even though the regulator is actually
set at that voltage.
We could fix the voltage listing but this would mean that list_voltage()
could end up going to the hardware to get the current voltage which isn't
expected (it's supposed to be very cheap) so instead special case things
when we can't change the voltage and compare the requested range against
the current voltage.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A recursive lockdep warning occurs if you call
regulator_set_optimum_mode() on a regulator with a supply because
there is no nesting annotation for the rdev->mutex. To avoid this
warning, get the supply's load before locking the regulator's
mutex to avoid grabbing the same class of lock twice.
=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #3257 Tainted: G W
---------------------------------------------
swapper/0/1 is trying to acquire lock:
(&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38
but task is already holding lock:
(&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&rdev->mutex);
lock(&rdev->mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by swapper/0/1:
#0: (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c
#1: (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c
#2: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224
stack backtrace:
[<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080)
[<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10)
[<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8)
[<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4)
[<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38)
[<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224)
...
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
commit 222cc7b1 (regulator: core: Allow multiple requests of a single supply mapping)
removed the usage of get_device_regulator().
Remove the function definition too amd get rid of the following warning:
drivers/regulator/core.c:112:26: warning: 'get_device_regulator' defined but not used [-Wunused-function]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Sometimes it may be useful to allow a device to request a supply multiple
times, for example in order to allow framework management of some uses of
the supply with some additional driver specific management or in order to
allow multiple children of an MFD to work with the supply. Currently this
is not possible due to the creation of
Solve this by removing the requested_uA entry (we have no current users
of this feature anyway) and ignoring errors creating the symlink to the
consumer. We should do something nicer than this as this causes sysfs to
spew enormous warnings but it allows users to run for now.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
There is no need to consider waiting for the voltage to ramp if we
didn't manage to set it and looking at the return value is going to be
cheaper than is_enabled().
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJP53AxAAoJEHm+PkMAQRiGs2QH/RaqkXz96fwjhDcyiKpDqA3c
kGuS5mz5cOhnqKSmR88HFm6pwuhLux/qSJzeAmoQy1MC8a0ACx7AnANW0lfN3/qe
/HGYz8h60yCL/fhn8/bUYtdt9xsoDqoDcq/ooFl9mcsJGWbC6WeMSZU5dAUYqviE
qFrp5zjY07FG53CRGT0hFpezQNwNL+VLH30CF9LD+fJLPVEYum2zBNGXWM42rcw5
fxzGL/6SO8YqA/Upic1ht6HAd6s5LOrlST7qvnyXUMvRXN5z/Y92ueYJZefkS1Om
ohuLIKM2bv9/dJS67H8N2baSKGCzBdfSe5/5WaHdLYW9MiVju0wRl6HPJtAMrkk=
=H8t8
-----END PGP SIGNATURE-----
Merge tag 'v3.5-rc4' into regulator-drivers
Linux 3.5-rc4 contains patches which conflict with some of the
development work.
With this change, regulator_set_voltage_time_sel() can be more generic and not
limited to linear and table based mapping now.
One side-effect of this change is that list_voltage() must be implemented.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This change makes it possible to set ramp_delay with 0.xxx mV/uS without
truncation issue.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
For table based mapping, we can calculate voltage difference by below equation:
abs(rdev->desc->volt_table[new_selector] - rdev->desc->volt_table[old_selector])
Thus we can make regulator_set_voltage_time_sel work for table based mapping.
regulator_set_voltage_time_sel() only supports linear or table based mapping.
In case it is misused, also warn if neither linear nor table based mapping
is used with regulator_set_voltage_time_sel().
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
For some hardwares ramp_delay for BUCKs is a configurable parameter which can
be configured through DT or board file.This patch adds ramp_delay to regulator
constraints and allow user to configure it for regulators which supports this
feature, through DT or board file. It will provide two ways of setting the
ramp_delay for a regulator:
First, by setting it as constraints in board file(for configurable
regulators) and set_machine_constraints() will take care of setting it on
hardware by calling(the provided) .set_ramp_delay() operation(callback).
Second, by setting it as data in regulator_desc(as fixed/default
ramp_delay rate) for a regulator in driver.
regulator_set_voltage_time_sel() will give preference to
constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly
users should also take care accordingly while refering ramp_delay rate(in case
of implementing their private .set_voltage_time_sel() callbacks for different
regulators).
[Rewrote subject for 80 columns -- broonie]
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
minor optimization: move delay code to where delay is set and
thus where it is used vs in the main line path.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Acked-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The voltage being set should be passed to the call in handler
requesting the callback. Currently this is not done.
The calling handler cannot call regulator_get_voltage() to get the
information since the mutex is held by the regulator and
deadlock occurs.
Without this change the receiver of the call in cannot know what
action to take. This is used, for example, to set PAD voltages
when doing SD vccq voltage changes.
[Review and spelling fix in the commit log from Pankaj Jangra]
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
rdev->desc->uV_step * abs(new_selector - old_selector) returns uV.
The unit of ramp_delay is mV/us.
Current code multiples 1000 at wrong place.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch adds regulator_set_voltage_time_sel(), to move into core, the
commonly used code by drivers to provide the .set_voltage_time_sel callback.
It will also allow us to configure different ramp delay for different
regulators easily.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fixed voltage is a kind of linear mapping where n_voltages is 1.
This change allows [list|map]_voltage_linear to be used for fixed
voltage.
For fixed voltage, n_voltages is 1 and the only valid selector is 0.
Thus we actually don't care the uV_step setting.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Properly handle the case if the specified min_uV is less than the voltage given
by the lowest selector.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If no regmap is explicitly specified then use dev_get_regmap() to obtain
one. The driver must explicitly enable any actual usage of the regmap
so there's no concern with unwanted usage.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
devres_release() will call the destructor for the resource as well as
freeing the devres data.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
If the regulator is not on, it won't take time setting new voltage.
So only call set_voltage_time_sel() to get the necessary delay when
the regulator is on.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some regulator hardware use table based mapping can set volt_table in
regulator_desc and use regulator_list_voltage_table() for their list_voltage
callback.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The major thing here is the addition of some helpers to factor code out
of drivers, making a fair proportion of regulators much more just data
rather than code which is nice.
- Helpers in the core for regulators using regmap, providing generic
implementations of the enable and voltage selection operations which
just need data to describe them in the drivers.
- Split out voltage mapping and voltage setting, allowing many more
drivers to take advantage of the infrastructure for selectors.
- Loads and loads of cleanups from Axel Lin once again, including many
changes to take advantage of the above new framework features
- New drivers for Ricoh RC5T583, TI TPS62362, TI TPS62363, TI TPS65913,
TI TWL6035 and TI TWL6037.
Some of the registration changes to support the core refactoring caused
so many conflicts that eventually topic branches were abandoned for this
release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJPuhn4AAoJEBus8iNuMP3d6m4P/0gNiGbTwDlOgU/mPDyW2jJc
xqvABzlOIQbI28/dgFYO/nA9YWW7VxpEaAPlkg4auk4wQ9tEyEjEqlOCfzymMetY
0k6L4n8LqFsbMAeNQbFPbW7PpWp59oI97J9afJI4kEJmHmOlmlL9U82/TzUFfGrA
yiPlzue+DotKB7FjsymLMbLyeFoiMSOIjVDk8OTs0u1EqeOo4nJG2ODLa+yGo+QW
0yqQExEdIp28WXbkZQtmsOmj2V/uhkKAv2i2PDT2TmlduhNdCGxJsgZIiZCl1R4c
vwirbfb+v93HAxvADdgj8eVdLJXQ0oItxr2ohKt8AgXIBrUJBsMkCQGvulZjRb+a
/A/7Ea3o7HI+PQx4aIP0yGA/eBwbzo/cmBxU+KGzTA9Mov0fnK1kkUs6gfrYBdli
U/TcMizDa1539BrKBIF2gmlRCKx8YD9ic27Zl1x4i5cgAP1gdYgdBYBybKHMpo2+
9Xp1R9C8FvvgytIqJ3QQ34tRomZyQ5iUaIuIuAosoQ6iuF33EQ6I0FvHcIe74iOi
zcu62ZPiuSwg1di9PrTERLcbrS81lvXpOWt5+EorzqoGXWzVIGoTh1F2kWEEMhaD
Q6V5iE03VC0k3tj/MmtTiVkyhNkRElQDtekE9sfm15pdVnpu/+b+iicWJa7QFbZQ
MybS0BBFQKhJXUDttKtS
=UR7s
-----END PGP SIGNATURE-----
Merge tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"The major thing here is the addition of some helpers to factor code
out of drivers, making a fair proportion of regulators much more just
data rather than code which is nice.
- Helpers in the core for regulators using regmap, providing generic
implementations of the enable and voltage selection operations which
just need data to describe them in the drivers.
- Split out voltage mapping and voltage setting, allowing many more
drivers to take advantage of the infrastructure for selectors.
- Loads and loads of cleanups from Axel Lin once again, including many
changes to take advantage of the above new framework features
- New drivers for Ricoh RC5T583, TI TPS62362, TI TPS62363, TI
TPS65913, TI TWL6035 and TI TWL6037.
Some of the registration changes to support the core refactoring
caused so many conflicts that eventually topic branches were abandoned
for this release."
* tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (227 commits)
regulator: tps65910: use of_node of matched regulator being register
regulator: tps65910: dt: support when "regulators" node found
regulator: tps65910: add error message in case of failure
regulator: tps62360: dt: initialize of_node param for regulator register.
regulator: tps65910: use devm_* for memory allocation
regulator: tps65910: use small letter for regulator names
mfd: tpx6586x: Depend on regulator
regulator: regulator for Palmas Kconfig
regulator: regulator driver for Palmas series chips
regulator: Enable Device Tree for the db8500-prcmu regulator driver
regulator: db8500-prcmu: Separate regulator registration from probe
regulator: ab3100: Use regulator_map_voltage_iterate()
regulator: tps65217: Convert to set_voltage_sel and map_voltage
regulator: Enable the ab8500 for Device Tree
regulator: ab8500: Split up probe() into manageable pieces
regulator: max8925: Remove check_range function and max_uV from struct rc5t583_regulator_info
regulator: max8649: Remove unused check_range() function
regulator: rc5t583: Remove max_uV from struct rc5t583_regulator_info
regulator: da9052: Convert to set_voltage_sel and map_voltage
regulator: max8952: Use devm_kzalloc
...
If we fail while registering a regulator make sure we release the supply
for the regulator if there is one.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Cc: stable@vger.kernel.org
Integer division may truncate the result.
Use DIV_ROUND_UP to ensure simple linear voltage mappings falls within the
specified range.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A lot of regulator hardware maps selectors on to voltages with a simple
linear mapping function
selector = base + (selector * step size)
Provide off the shelf list_voltage() and map_voltage() operations which
use new min_uV and uV_step members in the regulator_desc to implement
this function.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
In order to allow more drivers to factor things out into data allow
drivers to provide a mapping function to convert voltages into selectors.
This allows any driver to use set_voltage_sel(). The existing mapping
based on iterating over list_voltage() is provided as an operation which
can be assigned to the new map_voltage() function though for ease of
transition it is treated as the default.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
The core really wants a struct device to be supplied for regulators and
there's no reason this should be impossible so provide one so complain
if we didn't get one.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
It turns out that (quite surprisingly) devres_destroy() only undoes the
devres mapping, it doesn't destroy the underlying resource, meaning that
anything using devm_regulator_put() would leak. While we wait for the new
devres_release() which does what we want to get merged open code it in
devm_regulator_put().
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
If a regulator is always on for any reason then cache that when the
consumer is created and use it to optimise away the need to take locks
or recurse up the supply tree when consumers do enable or disable calls.
The scheduling of asynchronous work for bulk enables is also skipped.
We don't actually check if the device physically supports control on the
basis that constraints allowing status changes on physically always on
regulators are nonsensical anyway.
This is a very common pattern in hardware - it's normal to have some
power supplies that have either no software control or are critical to
system function - so many systems should be able to benefit.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
regulator_set_optimum_mode needs set_mode to properly work.
Add checking for set_mode callback in case it may be not implemented.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Since the enable(), disable() and is_enabled() operations for most regmap
based regulators come down to reading and updating a single register bit
we can factor out the code and allow these drivers to just define which
bit to update using the enable_reg and enable_mask fields in their desc
and then use operations provided by the core.
As well as the code saving this opens the door to future optimisation of
the bulk operations - if the core can realise that we are updating a
single register for multiple regulators then it should be able to combine
these updates into a single physical operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since the voltage selector operations are intended to directly map a
bitfield in the device register map into regulator API operations the
code for implementing them is usually very standard we can save some
code by providing standard implementations for devices using the regmap
API.
Drivers using regmap can pass their regmap in in the regmap_config
struct, set vsel_reg and vsel_mask in their regulator_desc and then
use regulator_{get,set}_voltage_sel_regmap in their ops. This saves
a small amount of code from each driver.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since many regulators use regmap for register I/O and since there's quite
a few very common patterns in the code allow drivers to pass in a regmap
to the core for use in generic code.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
In current implementation, to support set_suspend_voltage and set_suspend_mode
the regulator code needs the regulator driver to implement both
set_suspend_enable and set_suspend_disable callbacks.
This patch removes this limitation. In the case set_suspend_enable and/or
set_suspend_disable are NULL, the regulator code assumes we don't need to
do any thing to enable/disable regulator when system is suspended and
then will continue to handle set_suspend_mode and set_suspend_voltage.
Currently the regulator core creates suspend state related sysfs entries only
if both set_suspend_enable and set_suspend_disable callbacks are not NULL.
A side-effect of this change is that the regulator core will create suspend
state related sysfs entries unconditionally now.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When supplied by another regulator, returns the supply regulator's output
voltage for inpu_uV.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
We don't support missing configs at all so segfaulting isn't that bad
but since we've got checks in the code move the dereference after them.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Rather than adding new arguments to regulator_register() every time we
want to add a new bit of dynamic information at runtime change the function
to take these via a struct. By doing this we avoid needing to do further
changes like the recent addition of device tree support which required each
regulator driver to be updated to take an additional parameter.
The regulator_desc which should (mostly) be static data is still passed
separately as most drivers are able to configure this statically at build
time.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
In currently implementation of _regulator_do_set_voltage, set_voltage_time_sel will
only be called if set_voltage_sel is implemented.
set_voltage_time_sel actually only needs get_voltage_sel to get old_selector.
This patch makes regulator core support set_voltage_time_sel for drivers
implement either set_voltage or set_voltage_sel.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A bunch of smallish fixes that came up during the merge window as
things got more testing - even more fixes from Axel, a fix for error
handling in more complex systems using -EPROBE_DEFER and a couple of
small fixes for the new dummy regulators.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPeDhzAAoJEBus8iNuMP3dh3sP/2i2M34Y66HkNGJCbkLgzGsu
DlwbiNdh+o/uUcALCcyt7tYF06MhsJ4n7fOBRZ+hKr3VMTguHi6B36IKxGrfzBJs
9XoYQkyO/92g3UjdWQSWKSQfx/qZhw167gmmeL8jQfEQOZZ2MhnCLbbZVsRMFGf6
PzVDyW0StDWh0uBP6P7UU64pogFfUqSO/guIAqppUI9Ll/ulx0OqY+eov2mQzlmg
Rqwjt9mF9UMZn4/Br0mQx+iUqqSugtA+2VAAiSx7K8JDjeMPh47S31p/FGCLXrmv
Lbn2vQGn23RDthdxQlcisY/rJU5WsJbgdjjoppucyYJbYUWzVVMNM0djxtpGIQ7j
x9X6ZTdG4RuphI5FDku/vKkNS4O/Y0+6bumpqFfXyBoAGOXMKdUmTymCNCogFnOy
F6vMzrtA27M5HaFaRP3xnMSNU/aBegsgCoEjyQ1b5D1TAKvc5v614cZzyrWaCd+G
gVE1lDIAo2snraRjZl9LDQwGKOkzEdLXJSzGZ7Pk9n54+QvRBJcYu3l/Wdrn4JES
jtIprAyWbY4z6n5wuucwwjFZa2UtBukRTV8ZA/jMq+eig3VdN8CSKJCJUQTG+UgV
fyCNq7WWAhK8rldcjgJhPspEbRazAEnaNwfZUWZAmmnb8bVVRO6pJOl2TiRN0DFt
8MqdrQtJFusRXgrc+Wlq
=h5VJ
-----END PGP SIGNATURE-----
Merge tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A bunch of smallish fixes that came up during the merge window as
things got more testing - even more fixes from Axel, a fix for error
handling in more complex systems using -EPROBE_DEFER and a couple of
small fixes for the new dummy regulators."
* tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Remove non-existent parameter from fixed-helper.c kernel doc
regulator: Fix setting new voltage in s5m8767_set_voltage
regulator: fix sysfs name collision between dummy and fixed dummy regulator
regulator: Fix deadlock on removal of regulators with supplies
regulator: Fix comments in include/linux/regulator/machine.h
regulator: Only update [LDOx|DCx]_HIB_MODE bits in wm8350_[ldo|dcdc]_set_suspend_disable
regulator: Fix setting low power mode for wm831x aldo
regulator: Return microamps in wm8350_isink_get_current
regulator: wm8350: Fix the logic to choose best current limit setting
regulator: wm831x-isink: Fix the logic to choose best current limit setting
regulator: wm831x-dcdc: Fix the logic to choose best current limit setting
regulator: anatop: patching to device-tree property "reg".
regulator: Do proper shift to set correct bit for DC[2|5]_HIB_MODE setting
regulator: Fix restoring pmic.dcdcx_hib_mode settings in wm8350_dcdc_set_suspend_enable
regulator: Fix unbalanced lock/unlock in mc13892_regulator_probe error path
regulator: Fix set and get current limit for wm831x_buckv
regulator: tps6586x: Fix list minimal voltage setting for LDO0
Drivers should be able to declare their descriptors const and the framework
shouldn't ever be modifying the desciptor. Make the parameter and the
pointer in regulator_dev const to enforce this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Ensure we always apply the supply mapping when doing a lookup rather than
only doing it in non-DT cases, ensuring that regulators with supplies
specified in the regulator_desc can find their supplies on non-DT systems
and generally making the code more obvious.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When using device tree if there's no binding for a supply then there's no
way that one could appear later so just fail permanently right away. This
avoids wasting time trying to reprobe when that can never work.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When cleaning up after a failed bulk_disable() we try to reenable any
supplies that we did manage to disable - complain if we fail to do that
when we try.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If a regulator with a supply is being unregistered we will call
regulator_put() to release the supply with the regulator_list_mutex held
but this deadlocks as regulator_put() takes the same lock. Fix this by
releasing the supply before we take the mutex in regulator_unregister().
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This has been a fairly quiet release from a regulator point of view, the
only real framework features added were devm support and a convenience
helper for setting up fixed voltage regulators.
We also added a couple of drivers (but will drop the BQ240022 driver via
the arm-soc tree as it's been replaced by the more generic
gpio-regulator driver) and Axel Lin continued his relentless and
generally awesome stream of fixes and cleanups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPZ2paAAoJEBus8iNuMP3d4EIP/3bUD9zVwwC5/+aedwtSoKGC
eJXqdkJFYkEqLaeU5eobT79NFwzB/7JjVw7CMc/Z+9pXGwqSdA0T/k4j0EaTZWdo
SMqPfXA2Ia7c67pixdZ32GcYuT53iiBj9ecWozM8LaOyQz0oif127e1OF6LGtQzC
aWofP58MKrzDc+hmLixswgQVBKR5EDHna9XX7KnEL5ZdfRoyFsKkj752MJD1O6QN
79+7G0D9uKYsTf5IamYdG9x/kKRvtRlFAXsb7oNY9Z25PydXnkys0SED6isgr7rr
zgP+Q644fM09H68QgHuuJfsbDSrc0PjvLoOwISrDEQs4LH6usZLlTdZPQoqPc5uV
kB5oodsz7tb8NCZW7Y8xc0rYrEwaQKpvTDoZ93V9Zp3qyzxexNxm4akBRRUsFj/0
MxzyW+F81BxA35FIiRD55yZZ/U7ddoEzjea3tSvfGwDG1jMcV18t5G3LBThTAIIF
kvo4+xM6a8TPmGdNRSoEyO9vHYob/QzQ2zb7Pujf2SQpp/ULi7DMdNnbp0K/UYxt
pxwsj9IFR1rwPoHWwSfHZHWbioCeUkXwzf0ar4ydmg1U8AxQRPI2YNqVXP/BTPj6
GJ6ksHkBK5eK/mcob1s8t7nZDTEY5fiQw3lbQwM4mJaJIO6vza8RrpAcAeICI9FX
dLZmKQlMZ7vLLP6dSPx2
=fbBu
-----END PGP SIGNATURE-----
Merge tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates for 3.4 from Mark Brown:
"This has been a fairly quiet release from a regulator point of view,
the only real framework features added were devm support and a
convenience helper for setting up fixed voltage regulators.
We also added a couple of drivers (but will drop the BQ240022 driver
via the arm-soc tree as it's been replaced by the more generic
gpio-regulator driver) and Axel Lin continued his relentless and
generally awesome stream of fixes and cleanups."
* tag 'regulator-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (93 commits)
regulator: Fix up a confusing dev_warn when DT lookup fails
regulator: Convert tps6507x to set_voltage_sel
regulator: Refactor tps6507x to use one tps6507x_pmic_ops for all LDOs and DCDCs
regulator: Make s5m8767_get_voltage_register always return correct register
regulator: s5m8767: Check pdata->buck[2|3|4]_gpiodvs earlier
regulator: tps65910: Provide settling time for DCDC voltage change
regulator: Add Anatop regulator driver
regulator: Simplify implementation of tps65912_get_voltage_dcdc
regulator: Use tps65912_set_voltage_sel for both DCDCx and LDOx
regulator: tps65910: Provide settling time for enabling rails
regulator: max8925: Use DIV_ROUND_UP macro
regulator: tps65912: Use simple equations to get register address
regulator: Fix the logic of tps65910_get_mode
regulator: Merge tps65217_pmic_ldo234_ops and tps65217_pmic_dcdc_ops to tps65217_pmic_ops
regulator: Use DIV_ROUND_CLOSEST in wm8350_isink_get_current
regulator: Use array to store dcdc_range settings for tps65912
regulator: Rename s5m8767_convert_voltage to s5m8767_convert_voltage_to_sel
regulator: tps6524x: Remove unneeded comment for N_REGULATORS
regulator: Rename set_voltage_sel callback function name to *_sel
regulator: Fix s5m8767_set_voltage_time_sel calculation value
...
