| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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 9b92da1f1205bd25 "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: 9b92da1f1205bd25 "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 c368e5fc2a190923b786f2de3e79430ea3566a25 "regulator: fixed:
get rid of {get|list}_voltage()" broke regulator_list_voltage() for
the fixed regulator, because an earlier commit
5a523605afa7d3b54b2e7041f8c9e6bc39872a7e "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>
|
|
We should be returning an error, a repeated call will never succeed.
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>
|
|
Changed automaticall -> automatically.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
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>
|
|
Just for neatness.
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>
|
|
Reduce the size of core.c a bit.
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
regulator-helpers
|
|
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>
|
|
Clearly the testing only covered the bottom range.
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>
|
|
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>
|
