Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This problem was introduced by:
commit daad134d66 ("regulator: core: Request GPIO before creating
sysfs entries")
The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.
This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:
[ 1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[ 1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[ 1.130894] pgd = c0004000
[ 1.133598] [00000044] *pgd=00000000
[ 1.137205] Internal error: Oops: 5 [#1] SMP ARM
and here's backtrace from KDB:
Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0: 00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.
Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we now free the constraints in regulator_dev_release we will still
call free on the constraints pointer even if we went down an error
path in regulator_register, because it is only allocated after the
device_register. As such we no longer need to free rdev->constraints
on the error paths, so this patch removes said frees.
Fixes: 29f5f4860a ("regulator: core: Move more deallocation into class unregister")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Originally queue_delayed_work() used to negative error codes or 0 and 1
on success depending if the work was queued or not. It caused a lot of
bugs where people treated all non-zero returns as failures so we changed
it to return bool instead in d4283e9378 ('workqueue: make queueing
functions return bool'). Now it never returns failure.
Checking for negative values causes a static checker warning since it is
impossible based on the bool type.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit fa731ac7ea ("regulator: core: avoid unused variable warning")
introduced a subtle change in how supplies are locked. Where previously
code was always locking the regulator of the current iteration, the new
implementation only locks the regulator if it has a supply. For any
given power tree that means that the root will never get locked.
On the other hand the regulator_unlock_supply() will still release all
the locks, which in turn causes the lock debugging code to warn about a
mutex being unlocked which wasn't locked.
Cc: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Fixes: Fixes: fa731ac7ea ("regulator: core: avoid unused variable warning")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The latest workaround for the lockdep interface's not using the second
argument of mutex_lock_nested() changed the loop missed locking the last
regulator due to a thinko with the loop termination condition exiting
one regulator too soon.
Reported-by: Tyler Baker <tyler.baker@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
As noticed by Geert Uytterhoeven, my patch to avoid a harmless build warning
in regulator_lock_supply() was total crap and introduced a real bug:
> [ BUG: bad unlock balance detected! ]
> kworker/u4:0/6 is trying to release lock (&rdev->mutex) at:
> [<c0247b84>] regulator_set_voltage+0x38/0x50
we still lock the regulator supplies, but not the actual regulators,
so we are missing a lock, and the unlock is unbalanced.
This rectifies it by first locking the regulator device itself before
using the same loop as before to lock its supplies.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 716fec9d1965 ("[SUBMITTED] regulator: core: avoid unused variable warning")
Signed-off-by: Mark Brown <broonie@kernel.org>
The second argument of the mutex_lock_nested() helper is only
evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we
get this build warning for the new regulator_lock_supply
function:
drivers/regulator/core.c: In function 'regulator_lock_supply':
drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable]
To avoid the warning, this restructures the code to make it
both simpler and to move the 'i++' outside of the mutex_lock_nested
call, where it is now always used and the variable is not
flagged as unused.
We had some discussion about changing mutex_lock_nested to an
inline function, which would make the code do the right thing here,
but in the end decided against it, in order to guarantee that
mutex_lock_nested() does not introduced overhead without
CONFIG_DEBUG_LOCK_ALLOC.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 9f01cd4a91 ("regulator: core: introduce function to lock regulators and its supplies")
Link: http://permalink.gmane.org/gmane.linux.kernel/2068900
Signed-off-by: Mark Brown <broonie@kernel.org>
Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since we need to read voltages of parents as part of setting supply
voltages we need to be able to do get_voltage() internally without
taking locks so reorganize the locking to take locks on the full tree on
entry rather than as we recurse when called externally.
Reported-by: John Stultz <john.stultz@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Until now changing the voltage of a regulator only ever effected the
regulator itself, but never its supplies. It's a common pattern though
to put LDO regulators behind switching regulators. The switching
regulators efficiently drop the input voltage but have a high ripple on
their output. The output is then cleaned up by the LDOs. For higher
energy efficiency the voltage drop at the LDOs should be minimized. For
this scenario we need to propagate the voltage change to the supply
regulators. Another scenario where voltage propagation is desired is
a regulator which only consists of a switch and thus cannot regulate
voltages itself. In this case we can pass setting voltages to the
supply.
This patch adds support for voltage propagation. We do voltage
propagation when the current regulator has a minimum dropout voltage
specified or if the current regulator lacks a get_voltage operation
(indicating it's a switch and not a regulator).
Changing the supply voltage must be done carefully. When we are
increasing the current regulators output we must first increase the
supply voltage and then the regulator itself. When we are decreasing the
current regulators voltage we must decrease the supply voltage after
changing the current regulators voltage.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
_regulator_call_set_voltage has code to translate a minimum/maximum
voltage pair into a selector. This code is useful for others aswell,
so create a regulator_map_voltage function.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Each regulator_dev is locked with its own mutex. This is fine as long
as only one regulator_dev is locked, but makes lockdep unhappy when we
have to walk up the supply chain like it can happen in
regulator_get_voltage:
regulator_get_voltage ->
mutex_lock(®ulator->rdev->mutex) ->
_regulator_get_voltage(regulator->rdev) ->
regulator_get_voltage(rdev->supply) ->
mutex_lock(®ulator->rdev->mutex);
This causes lockdep to issue a possible deadlock warning.
There are at least two ways to work around this:
- We can always lock the whole supply chain using the functions
introduced with this patch.
- We could store the current voltage in struct regulator_rdev so
that we do not have to walk up the supply chain for the
_regulator_get_voltage case.
Anyway, regulator_lock_supply/regulator_unlock_supply will be needed
once we allow regulator_set_voltage to optimize the supply voltages.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
When resolving regulator-regulator supplies we ignore probe deferral
returns from regulator_dev_lookup() (such as are generated for DT when
we can see a supply is registered) and just fall back to the dummy
regulator if there are full constraints (as is the case for DT). This
means that probe deferral is broken for DT systems, fix that by paying
attention to -EPROBE_DEFER return codes like we do -ENODEV.
A further patch will simplify this further, this is a minimal fix for
the specific issue.
Fixes: 9f7e25edb1 (regulator: core: Handle full constraints systems when resolving supplies)
Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonnie@kernel.org>
Cc: stable@vger.kernel.org
As we are already registering a device with regulator_class for each
regulator device, regulator_list is redundant and can be replaced with
calls to class_find_device() and class_for_each_device().
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The ret pointer passed to regulator_dev_lookup is only filled with a
valid error code if regulator_dev_lookup returned NULL. Currently
regulator_resolve_supply checks this ret value before it checks if a
regulator was returned, this can result in valid regulator lookups being
ignored.
Fixes: 6261b06de5 ("regulator: Defer lookup of supply to regulator_get")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The same error print exists 4 times in the regulator core
<rdev>: operation not allowed
Unfortunately, seeing this in the dmesg is not very informative.
Add what type of operation is not allowed to the message so that
these errors are unique, hopefully pointing developers in the
right direction
<rdev>: drms operation not allowed
<rdev>: voltage operation not allowed
<rdev>: current operation not allowed
<rdev>: mode operation not allowed
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This has been a busy release for regmap. By far the biggest set of
changes here are those from Markus Pargmann which implement support for
block transfers in smbus devices. This required quite a bit of
refactoring but leaves us better able to handle odd restrictions that
controllers may have and with better performance on smbus.
Other new features include:
- Fix interactions with lockdep for nested regmaps (eg, when a device
using regmap is connected to a bus where the bus controller has a
separate regmap). Lockdep's default class identification is too
crude to work without help.
- Support for must write bitfield operations, useful for operations
which require writing a bit to trigger them from Kuniori Morimoto.
- Support for delaying during register patch application from Nariman
Poushin.
- Support for overriding cache state via the debugfs implementation
from Richard Fitzgerald.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJV6cZyAAoJECTWi3JdVIfQM3sH/RSygzRIOoOuvro0U3qd4+nM
qLzpuZNtuAP7xNc5yJZiixz1S6PqUNl+pK/u58s6x10GWDGsWZY6E0Lg94lYmfhA
26jqWSzrMHp42x+ZN7btLExzPTVnvRerrjtj4mqz6t4yun9SzqVymaZTUZ1hqPHB
qxSNHs3rHPiqiEWpQKJXb+5dazYYJCbOUrlivxJCk60+ns1N88cA71aY+5/zq5uy
36e0iYe3s+lv0lptedarFCf9p7o1E6EQzhvEMfyquGXtvq8fl7Qdeo7riRFQ8Iiy
sygCb3AYuZIiqnOC7+90xkr2Oq0iwdJUD91A9sl/SRiwgItG9jW03bWNHYIhQyk=
=CbGt
-----END PGP SIGNATURE-----
Merge tag 'regmap-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap updates from Mark Brown:
"This has been a busy release for regmap.
By far the biggest set of changes here are those from Markus Pargmann
which implement support for block transfers in smbus devices. This
required quite a bit of refactoring but leaves us better able to
handle odd restrictions that controllers may have and with better
performance on smbus.
Other new features include:
- Fix interactions with lockdep for nested regmaps (eg, when a device
using regmap is connected to a bus where the bus controller has a
separate regmap). Lockdep's default class identification is too
crude to work without help.
- Support for must write bitfield operations, useful for operations
which require writing a bit to trigger them from Kuniori Morimoto.
- Support for delaying during register patch application from Nariman
Poushin.
- Support for overriding cache state via the debugfs implementation
from Richard Fitzgerald"
* tag 'regmap-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: (25 commits)
regmap: fix a NULL pointer dereference in __regmap_init
regmap: Support bulk reads for devices without raw formatting
regmap-i2c: Add smbus i2c block support
regmap: Add raw_write/read checks for max_raw_write/read sizes
regmap: regmap max_raw_read/write getter functions
regmap: Introduce max_raw_read/write for regmap_bulk_read/write
regmap: Add missing comments about struct regmap_bus
regmap: No multi_write support if bus->write does not exist
regmap: Split use_single_rw internally into use_single_read/write
regmap: Fix regmap_bulk_write for bus writes
regmap: regmap_raw_read return error on !bus->read
regulator: core: Print at debug level on debugfs creation failure
regmap: Fix regmap_can_raw_write check
regmap: fix typos in regmap.c
regmap: Fix integertypes for register address and value
regmap: Move documentation to regmap.h
regmap: Use different lockdep class for each regmap init call
thermal: sti: Add parentheses around bridge->ops->regmap_init call
mfd: vexpress: Add parentheses around bridge->ops->regmap_init call
regmap: debugfs: Fix misuse of IS_ENABLED
...
We were checking rdev->supply for NULL after dereferencing it. Lets
check for rdev->supply along with _regulator_is_enabled() and call
regulator_enable() only if rdev->supply is not NULL.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When calling regulator_set_load, regulator_check_drms prints and returns
an error if the regulator device's flag REGULATOR_CHANGE_DRMS isn't set.
drms_uA_update, however, bails out without reporting an error.
Replace the error print with a debug level print so that we don't get
such prints when the underlying regulator doesn't support DRMS.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Failure to create a debugfs node is not an error, but we print a
warning upon failure to create the node. Downgrade this to a
debug printk so that we're quiet here. This allows multiple
drivers to request a CPU's regulator so that CPUfreq and AVSish
drivers can coexist.
The downside of this approach is that whoever gets to debugfs first
the others who come later to not have any debugfs attributes associated
with them.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_list has exactly the same contents as the list that the
driver core maintains of regulator_class members so is redundant. As a
first step in converting over to use the class device list convert our
iteration in late_initcall() to use the class device iterator.
Signed-off-by: Mark Brown <broonie@kernel.org>
We really ought to be using the class dvice lifetime management features
more than we are rather than open coding them so take a step towards that
by moving some of the simplest deallocations to the dev_release() function.
Signed-off-by: Mark Brown <broonie@kernel.org>
When we release a regulator we need to remove references to it from the
rdev which means locking the rdev. Currently we also free resources
associated with the regulator inside the rdev lock but there is no need
to do this, we can reduce the region the lock is held by restricting it
to just actions that affect the rdev.
Signed-off-by: Mark Brown <broonie@kernel.org>
When removing a regulator we hold regulator_list_mutex in order to
ensure the regualtor doesn't become removed again. However we only need
to protect the list until we remove the regulator from the list so move
the unlock earlier to reduce the locked region.
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators can automatically shut down when they detect an
over current event. Add an op (set_over_current_protection) and a
DT property + constraint to support this capability.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
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 [39f802d6b6d9: 'regulator: Build sysfs entries with static
attribute groups'] converted the sysfs entry creation to static
attribute groups, but this resulted in a regression due to the NULL
check of rdev->constraints. At the point where the device is
registered, rdev->constraints isn't set, so the attributes depending
on it are missing.
We may fix it by shuffling the code order in regulator_register(), but
a quicker fix is to just remove this NULL check. rdev->constraints is
in anyway always set to non-NULL in set_machine_constraints(), thus
the check there is basically superfluous.
Fixes: 39f802d6b6 ('regulator: Build sysfs entries with static attribute groups')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reportded-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Mark Brown