History log of /drivers/regulator/core.c
Revision Date Author Comments
a0c7b164ad115ec0556dc0904ee2218cbc5cedfa 10-Sep-2014 Mark Brown <broonie@kernel.org> regulator: of: Provide simplified DT parsing method

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>
7179569aeb52197fd2a9909ba226c4c9cc0e2e2a 28-Aug-2014 Heiko Stübner <heiko@sntech.de> regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)

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>
39f5460d7f9cc57d3dd745301bf60ca5d65a6e7b 19-Aug-2014 Guodong Xu <guodong.xu@linaro.org> regulator: core: add const to regulator_ops and fix build error in mc13892

Commit 272e2315fac3 ("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>
871f565055ed232e5751da18a331b73e8254adaf 13-Aug-2014 Guodong Xu <guodong.xu@linaro.org> regulator: core: add guard delay between calling regulator_disable and _enable

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>
79fd114161a764dfa456191af89358b3f5201c87 13-Aug-2014 Guodong Xu <guodong.xu@linaro.org> regulator: core: factor out delay function from _regulator_do_enable

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>
272e2315fac3bfca0edfa3252b8a643c425602af 13-Aug-2014 Guodong Xu <guodong.xu@linaro.org> regulator: core: add const qualifier to ops in struct regulator_desc

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>
26988efe11b1dc44853035122927ced25578f302 29-Jul-2014 Javier Martinez Canillas <javier.martinez@collabora.co.uk> regulator: core: Allow to get voltage count and list from parent

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>
e303996e94b8705c85f3d78f3c094d05b0620c9d 29-Jul-2014 Javier Martinez Canillas <javier.martinez@collabora.co.uk> regulator: core: Get voltage from parent if not available

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>
04eca28cde52cdf9eb91e127cc358ad79a8ec53b 21-Jul-2014 Tuomas Tynkkynen <ttynkkynen@nvidia.com> regulator: Add helpers for low-level register access

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>
778b28b4348af9c72bb5ac0dc129363a706325ef 29-Jun-2014 Russell King <rmk+kernel@arm.linux.org.uk> regulator: core: convert to use gpio_desc internally

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>
69d588392b057c0cedb1ba58d7973b77a65997ec 04-Jun-2014 Nishanth Menon <nm@ti.com> regulator: core: print error value when constraints are not applied

With commit 064d5cd110f94ce41ca5681dcda8b77fa63d5b95
(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>
064d5cd110f94ce41ca5681dcda8b77fa63d5b95 20-May-2014 Alban Bedel <alban.bedel@avionic-design.de> regulator: core: Fix the init of DT defined fixed regulators

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>
fd482a3e3e20cddfb6d775ec0382f98a92b8a25e 24-Apr-2014 Saravana Kannan <skannan@codeaurora.org> regulator: core: Disable unused regulators after deferred probing is done

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>
e953583456005823d7c20fefe5212f0f60a93fb6 01-Jun-2014 Mark Brown <broonie@linaro.org> regulator: Don't disable unused regulators we don't have permission for

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>
69c3f7239e29216fbf92a39c86b4e9cc63cd6d74 28-May-2014 Stephen Boyd <sboyd@codeaurora.org> regulator: Fix regulator_get_{optional,exclusive}() documentation

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>
366986274c548261c42d5ca24391cb4eef3008c2 24-May-2014 Axel Lin <axel.lin@ingics.com> regulator: core: Use map_voltage_linear_range by default for list_voltage_linear_range

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>
9f8c0fe9542141fd0008d5c0f6ae365890f6da94 23-May-2014 Lee Jones <lee.jones@linaro.org> regulator: Constify the pointer to alias name array

Toughen-up checks for read-only regulator names.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
63c7c9e16c8e92cc069854f2babdf82d2d38e4c7 03-Apr-2014 Charles Keepax <ckeepax@opensource.wolfsonmicro.com> regulator: core: Get and put regulator of_node

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>
66fda75f47dc583f1c187556e9a2c082dd64f8c6 20-Feb-2014 Markus Pargmann <mpa@pengutronix.de> regulator: core: Replace direct ops->disable 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>
30c219710358c5cca2f8bd2e9e547c6aadf7cf8b 20-Feb-2014 Markus Pargmann <mpa@pengutronix.de> regulator: core: Replace direct ops->enable usage

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>
acc3d5cec84f82ebea535fa0bd9500ac3df2aee9 20-Feb-2014 Shuah Khan <shuah.kh@samsung.com> regulator: core: Change dummy supplies error message to a warning

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
e227867f12302633737bd2a48a10a9a72c0630cb 18-Feb-2014 Masanari Iida <standby24x7@gmail.com> treewide: Fix typo in Documentation/DocBook

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>
c00dc359e5e0b10de993651d8e73e60c41bf29cd 05-Feb-2014 Bjorn Andersson <bjorn@kryo.se> regulator: core: Allow regulator_set_voltage for fixed regulators

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>
317b5684d52269b75b4ec6480f9dac056d0d4ba8 27-Jan-2014 Mark Brown <broonie@linaro.org> regulator: core: Correct default return value for full constraints

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
0d25d09de114bffc984a03c417d4dddb53acd8d8 08-Jan-2014 Jingoo Han <jg1.han@samsung.com> regulator: core: Fix checkpatch issue

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>
0781719bd6614e60dd5fff1b5cd45dbce2f7dd2d 17-Dec-2013 Hans de Goede <hdegoede@redhat.com> regulator: core: don't print an error when no regulator is found

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>
75bc9641cadd2a3f91f9c2e7f2fdfdeb8bd4b1d6 27-Nov-2013 Mark Brown <broonie@linaro.org> regulator: core: Check for DT every time we check full constraints

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>
87b2841753e1694fc96fefb467f6aff9940b07af 27-Nov-2013 Mark Brown <broonie@linaro.org> regulator: core: Replace checks of have_full_constraints with a function

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>
f446043f1aa74c2d699db48ba4a7a075b88dc14d 13-Nov-2013 Guennadi Liakhovetski <g.liakhovetski@gmx.de> regulator: fixed: fix regulator_list_voltage() for regression

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>
a06ccd9c3785fa5550917ae036944f4e080b5749 15-Oct-2013 Charles Keepax <ckeepax@opensource.wolfsonmicro.com> regulator: core: Add ability to create a lookup alias for supply

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>
4040394e12cb1eed21d1306cacdc8a6f0464c8e2 04-Oct-2013 Mark Brown <broonie@linaro.org> regulator: core: Always warn when using a dummy regulator

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>
5df529d440aa4f0e67be9af3718e7edf05db7d02 20-Sep-2013 Thierry Reding <thierry.reding@gmail.com> regulator: core: Reduce busy-wait looping

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>
ef60abbb6b406389245225ab4acfe73f66e7d92c 23-Sep-2013 Mark Brown <broonie@linaro.org> regulator: core: Always use return value when regulator_dev_lookup() fails

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>
043c998f95036e7fc796b240ab5ba49a8de36df3 20-Sep-2013 Mark Brown <broonie@linaro.org> regulator: core: Fix return code for invalid parameters

We should be returning an error, a repeated call will never succeed.

Signed-off-by: Mark Brown <broonie@linaro.org>
9b92da1f1205bd2591487051a93624dd6c258eef 20-Sep-2013 Mark Brown <broonie@linaro.org> regulator: core: Fix default return value for _get()

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>
f8c1700dd7d2ce9b2238b20d364317b2968ac76b 20-Sep-2013 Laxman Dewangan <ldewangan@nvidia.com> regulator: core: set current constraints while setting machine constraints

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>
00c877c69ba315d6c565a4df51c71b11e82cdeb8 18-Sep-2013 Laxman Dewangan <ldewangan@nvidia.com> regulator: core: add support for configuring turn-on time through constraints

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>
4f0ac6dabf867095b31f851ba0d0ceaca2f87e2e 13-Sep-2013 Mark Brown <broonie@linaro.org> regulator: core: Remove unused regulator_use_dummy_regulator()

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>
4ddfebd3b0d5b65c69492408bb67fd1202104643 13-Sep-2013 Mark Brown <broonie@linaro.org> regulator: core: Provide a dummy regulator with full constraints

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>
0cdfcc0f9352a4c076fbb51299e2b12a35619a51 11-Sep-2013 Mark Brown <broonie@linaro.org> regulator: core: Split devres code out into a separate file

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>
cee8e355942c01f408bddf8a53596be1dff7a86b 31-Aug-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Refactor devm_regulator_get* APIs

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>
42141f22e32a452b02b3dc8764d93223505e1c10 05-Sep-2013 Sachin Kamat <sachin.kamat@linaro.org> regulator: core: Fix a trivial typo

Changed automaticall -> automatically.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
b33e46bcdc4e598d738ed12a5a7906be4e11d786 31-Aug-2013 Mark Brown <broonie@linaro.org> regulator: core: Provide managed regulator registration

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>
5a523605afa7d3b54b2e7041f8c9e6bc39872a7e 10-Sep-2013 Laxman Dewangan <ldewangan@nvidia.com> regulator: core: provide fixed voltage in desc for single voltage rail

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>
9efdd27678ef5e22c27c230a08a211b702768f3a 25-Aug-2013 Matthias Kaehlcke <matthias.list@kaehlcke.net> regulator: Add devm_regulator_get_exclusive()

Add a resource managed regulator_get_exclusive()

Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
84fcf447a99c8cc9cc906b42e590d1a3a7ed56ab 18-Aug-2013 Mark Brown <broonie@linaro.org> regulator: core: Use bool for exclusivitity flag

Just for neatness.

Signed-off-by: Mark Brown <broonie@linaro.org>
d295f7670127eb241d81e96e003b380c77c2b254 09-Aug-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Move list_voltage_{linear,linear_range,table} to helpers.c

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>
c4a54b8d54218a75b94ab9947449e688869df00d 06-Aug-2013 Mark Brown <broonie@linaro.org> regulator: core: Move helpers for drivers out into a separate file

Reduce the size of core.c a bit.

Signed-off-by: Mark Brown <broonie@linaro.org>
de1dd9fd2156874b45803299b3b27e65d5defdd9 29-Jul-2013 Mark Brown <broonie@linaro.org> regulator: core: Provide hints to the core about optional supplies

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>
587cea27e4feee7365b22935b3e19e1e8906e9cb 25-Jul-2013 Greg Kroah-Hartman <gregkh@linuxfoundation.org> regulator: core: convert class code to use dev_groups

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>
6c918d220925eeeca75b67e896eabffd061cd128 18-Jul-2013 Mark Brown <broonie@linaro.org> regulator: core: Ensure selector is mapped

Clearly the testing only covered the bottom range.

Signed-off-by: Mark Brown <broonie@linaro.org>
a56d66a2f01b172bc00d73b0b0392423c8aaae19 18-Jul-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Allow fixed voltage range in multiple linear ranges

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>
070260f07c7daec311f2466eb9d1df475d5a46f8 18-Jul-2013 Mark Brown <broonie@linaro.org> regulator: core: Use the power efficient workqueue for delayed powerdown

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>
5b175952011adae30b531ab89cc24acb173b2ce4 29-Jun-2013 Yadwinder Singh Brar <yadi.brar@samsung.com> regulator: core: Remove redundant checks

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>
1653ccf4c52df6a4abe8ec2f33f2cb2896d129ea 29-Jun-2013 Yadwinder Singh Brar <yadi.brar@samsung.com> regulator: core: Add support for disabling ramp delay

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>
94d33c02c7186b69849c292e1216a08ad1c0d99d 02-Jul-2013 Mark Brown <broonie@linaro.org> regulator: core: Add helpers for multiple linear ranges

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>
891636ea27ef42d92a420185d2ccbe190ba00a23 08-Jul-2013 Mark Brown <broonie@linaro.org> regulator: core: Drop references on supply regulator when unregistering

Signed-off-by: Mark Brown <broonie@linaro.org>
2a668a8bc2cbe7a464ab1212475a3efb23a94b1e 07-Jun-2013 Paul Walmsley <pwalmsley@nvidia.com> regulator: core: add regulator_get_linear_step()

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>
ce0d10f887cabf9f16d1cbb60ef013021befbfdf 21-May-2013 Charles Keepax <ckeepax@opensource.wolfsonmicro.com> regulator: core: Correct spelling mistake in comment

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
31d6eebf7e079cfb5e98e65d5af4c6de093e076c 02-May-2013 Robert P. J. Day <rpjday@crashcourse.ca> regulator: Fix kernel-doc generation warnings.

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>
fcf371ee5624cc87abac205cd0dad2432d7f0346 18-Apr-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Add regulator_map_voltage_ascend() API

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>
1e4b545cdd93318379c6b1fb0a99536fa3260f53 16-Apr-2013 Nishanth Menon <nm@ti.com> regulator: core: return err value for regulator_get if there is no DT binding

commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
(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>
0f7b87f0acc04e4f22ec5d3f2283a80993ca3aa8 05-Apr-2013 Andrew Bresticker <abrestic@chromium.org> regulator: core: don't require a supply when supply_name is specified

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>
167d41dce7633b70aae4175fdec734e1cdd3a190 23-Mar-2013 Maxime Ripard <maxime.ripard@free-electrons.com> regulator: Fix typo in of_get_regulator function comments

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
51dcdafcb720a9d1fd73b597d0ccf48837abc59f 05-Mar-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Add enable_is_inverted flag to indicate set enable_mask bits to disable

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>
7b74d149247c8972da1cec3e4c70b67049aaeb69 18-Feb-2013 Kim, Milo <Milo.Kim@ti.com> regulator: core: use regulator_ena_pin member

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>
967cfb18c0e331b43a29ae7f60ec1ef0dcb02f6b 18-Feb-2013 Kim, Milo <Milo.Kim@ti.com> regulator: core: manage enable GPIO list

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>
f19b00da8ed37db4e3891fe534fcf3a605a0e562 18-Feb-2013 Kim, Milo <Milo.Kim@ti.com> regulator: core: support shared enable GPIO concept

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>
fbe31057fafebdc2811a7101b8b4a0460f5417d1 01-Mar-2013 Andrzej Hajda <a.hajda@samsung.com> regulator: fixed regulator_bulk_enable unwinding code

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>
9345dfb8495aa17ce7c575e1a96e5ad64def0b3d 01-Mar-2013 Nishanth Menon <nm@ti.com> regulator: core: fix documentation error in regulator_allow_bypass

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>
9c7b4e8a8ad2624106fbf690fa97ab9c8c9bfa88 14-Feb-2013 Russ Dill <Russ.Dill@ti.com> regulator: Fix memory garbage dev_err printout.

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>
c66a566afbe6e2c94b1ae70f70cc1e3d4c73639b 06-Feb-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Optimize _regulator_do_set_voltage if voltage does not change

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>
896b65f3453d434983969e3ee7c254f4f8ba1424 01-Feb-2013 Michał Mirosław <mirq-linux@rere.qmqm.pl> regulator: show state for GPIO-controlled regulators

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
0384618a79ccfafd05ca1538867764f7c4b7916b 03-Jan-2013 Axel Lin <axel.lin@ingics.com> regulator: core: Fix comment for regulator_register()

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>
c8520b4c5d25eb7b8b54f1ae9ba7da71375f2b2c 18-Dec-2012 Axel Lin <axel.lin@ingics.com> regulator: core: Allow specify apply_[reg|bit] for regmap based voltage_sel operations

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>
19280e40714c9a3c55ab47f76df110072f6cde5e 12-Dec-2012 Axel Lin <axel.lin@ingics.com> regulator: core: Fix continuous_voltage_range case in regulator_can_change_voltage

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>
92d7a55879c01b30349045501108e775655a4b92 13-Dec-2012 Paolo Pisati <paolo.pisati@canonical.com> regulator: core: if voltage scaling fails, restore original voltage values

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>
8a23b4e03d6873ec50f7d212de78ff01e393fc1a 11-Dec-2012 Axel Lin <axel.lin@ingics.com> regulator: core: Fix logic to determinate if regulator can change voltage

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>
d1e7de3007c6e34c5e6d5e1b707b5aba4a1cd57f 04-Dec-2012 Marek Szyprowski <m.szyprowski@samsung.com> regulators: add regulator_can_change_voltage() function

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>
fff15bef48e846d2670c86c95f8dbc3f84bbe866 27-Nov-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Say what unsupportable voltage constraints are

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
dd8004af2b0e903b2ee9fce305cb615245fa12ee 28-Nov-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Log when a device causes a voltage constraint fail

Helps with figuring out when things went wrong.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
33234e791de2ac3ea915158e042907748191cabd 27-Nov-2012 Axel Lin <axel.lin@ingics.com> regulator: core: Allow specific minimal selector for starting linear mapping

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>
f0f98b19e23d4426ca185e3d4ca80e6aff5ef51b 13-Nov-2012 Marek Szyprowski <m.szyprowski@samsung.com> regulator: fix voltage check in regulator_is_supported_voltage()

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
23ff2f0f6128b4c310fbb274dbb91cc2f9b6ab06 14-Nov-2012 Charles Keepax <ckeepax@opensource.wolfsonmicro.com> regulator: core: Avoid deadlock when regulator_register fails

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>
b2da55d9441cbdaf73c12403ed801b644d5ae5e3 28-Oct-2012 Andrew Lunn <andrew@lunn.ch> Regulator: core: Unregister when gpio request fails.

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>
bd7a2b600ace90c8819495b639a744c8f5c68feb 24-Sep-2012 Pawel Moll <pawel.moll@arm.com> regulator: core: Support for continuous voltage range

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>
df36793115b4f68181877a1c89bac54feadd965d 28-Aug-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Provide regmap get/set bypass operations

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
f59c8f9fe689790248ae7aa7426579982050638c 31-Aug-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Support bypass mode

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>
52b84dac436a681fa51dad2b9e57b6ea50309cbd 07-Sep-2012 AnilKumar Ch <anilkumar@ti.com> regulator: core: Try using the parent device for the default regmap

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>
2b5a24a01df12fbfa3e702ad7efae27bcb852e33 07-Sep-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Fast path non-deferred disables

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>
f2889e650a8dbd51644997aef7bae71d6ac4d423 27-Aug-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Report microvolts in sysfs even with only list_voltage()

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>
dedae957a41b4f4523199f7a822ee4e5735640b0 19-Aug-2012 Randy Dunlap <rdunlap@xenotime.net> regulator: fix kernel-doc warnings in drivers/regulator/core.c

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>
43829731dd372d04d6706c51052b9dabab9ca356 20-Aug-2012 Tejun Heo <tj@kernel.org> workqueue: deprecate flush[_delayed]_work_sync()

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>
296c656616bd567b2849f5a8a444452c4849ac01 19-Aug-2012 Randy Dunlap <rdunlap@xenotime.net> regulator: fix kernel-doc warnings in drivers/regulator/core.c

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>
b2a1ef473b031b630a26685c91a46b9ae668d35c 09-Aug-2012 Marek Szyprowski <m.szyprowski@samsung.com> regulator: core: request only valid gpio pins for regulator enable

Commit 65f735082de3 ("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>
f7df20ec323009bd2ea8e1c65f11bb43fd526c4f 09-Aug-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Use list_voltage() to read single voltage regulators

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>
215b8b055de7dad26ab6c10f70130934309cb696 07-Aug-2012 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> regulator: make the dummy regulator's print_constraint more helpful

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>
2f6c797f84fd764efb5eeb7cbb6a80a7244bd13c 06-Aug-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Fix cast to pointer from integer of different size warning

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>
57ad526ae2c28d128fe0d9deeb428697151c849b 23-Jul-2012 Laxman Dewangan <ldewangan@nvidia.com> regulator: core: increment open_count when regulator supply is set

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>
2955b47d2c1983998a8c5915cb96884e67f7cb53 10-Jul-2012 Dan Williams <dan.j.williams@intel.com> [SCSI] async: introduce 'async_domain' type

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>
1beaf762b4ad5f53876f790bb6cfbd3bac072985 12-Jul-2012 Krystian Garbaciak <krystian.garbaciak@diasemi.com> regulator: Add REGULATOR_STATUS_UNDEFINED.

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>
03ffcf3d0838bd5e693cd4520becfb22577cf34d 12-Jul-2012 Krystian Garbaciak <krystian.garbaciak@diasemi.com> regulator: Fix a typo in regulator_mode_to_status() core function.

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>
86f5fcfc3e400b2ac1562cb0fd6aabc9f83ee3e2 06-Jul-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Mark all DT based boards as having full constraints

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>
e2c98eaf928a2a0ecaca1db9aa5dc56a36699d9f 05-Jul-2012 Shawn Guo <shawn.guo@linaro.org> regulator: core: remove sysfs entry properly in regulator_put

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>
65f735082de35aa4d44e8d0afe862798d0e09e29 27-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Add core support for GPIO controlled enable lines

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>
5c5659d0a22ec4f947ef4faa3055767572f15e74 27-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Factor out enable and disable operations some more

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>
79511ed3225a64f6b7fc749f4f9c1ed82f24f729 27-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Allow fixed enable_time to be set in the regulator_desc

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>
e113d792d56d4b720b3d84c122b6af84c3bfa094 26-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Check that the selector from map_voltage() is valid

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>
c5f3939b8fe0c358d35397982e5afdef112afc81 02-Jul-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Support fixed voltages in regulator_is_supported_voltage()

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>
d92d95b6bf2722ffa0fefa7651c51bf336743dd7 03-Jul-2012 Stephen Boyd <sboyd@codeaurora.org> regulator: Fix recursive mutex lockdep warning

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>
bf2516cd020dbf80ed2f1750ac1f4b0da3549c91 27-Jun-2012 Fabio Estevam <fabio.estevam@freescale.com> regulator: core: Remove unused get_device_regulator

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>
222cc7b1cefbab1287ed5d5e3cce1f45aec60d39 22-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Allow multiple requests of a single supply mapping

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>
5aff3a8b20c54888e199e863744848007f1f4120 26-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Check for failed voltage sets before checking for delay

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>
f11d08c3d611d6f2845677caabe13b2c58f95658 19-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: Use list_voltage() to get voltage in regulator_set_voltage_time_sel

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>
b19dbf711e8dae026f8d014eae90d766d02f4acb 23-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Add export of regulator_set_voltage_time_sel()

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
230a5a1c41464f7fe5b676c21280ae4effa222c8 15-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix double free in devm_regulator_put()

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
ea38d13fd1666bc030cb1c0feec5b0da2f89f9b2 18-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Change the unit of ramp_delay from mV/uS to uV/uS

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>
398715ab9414b3b7741c8239c254111f5016821c 18-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Support table based mapping in regulator_set_voltage_time_sel

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>
6f0b2c696ca340cc2da381fe693fda3f8fdb2149 11-Jun-2012 Yadwinder Singh Brar <yadi.brar01@gmail.com> regulator: Add ramp_delay configuration to constraints

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>
8b96de31b0cf190fb6b21c4ab1ce310c430b72ae 15-Jun-2012 Philip Rakity <prakity@marvell.com> regulator: core.c Only delay when setting voltage requires this

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>
2f7baf89d3e4ed787989168cf31f2fdc04067586 15-Jun-2012 Philip Rakity <prakity@marvell.com> regulator: core.c Pass voltage to notifier when setting voltage

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>
d8493d210b69b2965236a8a02f5f6e2835ad5e30 15-Jun-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Actually use the data in _notifier_call_chain()

Reported-by: Pankaj Jangra <jangra.pankaj9@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
578df8babf3b1895d562e1ea0d3a81d1e77e0182 11-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Return correct delay time in regulator_set_voltage_time_sel

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>
98a175b60f46a80dfa44fb0e0807f2e5a351f35f 09-Jun-2012 Yadwinder Singh Brar <yadi.brar01@gmail.com> regulator: core: Add regulator_set_voltage_time_sel to calculate ramp delay.

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>
5a6881e8e134ea636bbc8423049e84638dbb7106 07-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Handle fixed voltage in map_voltage_linear

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>
0bdc81e4e944781a2bcc971f9e3cf24ac7030939 07-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Properly handle the case min_uV < rdev->desc->min_uV in map_voltage_linear

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>
9152c36a3b37a95c1161508dc105719456d7f7d0 04-Jun-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Use map_voltage_linear() if list_voltage_linear() is in use and nothing is set

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
3a4b0a07fa69cbfbdd4bc2ebe769cf789949db46 08-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Use dev_get_regmap() to find the regmap

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>
361ff5017446605dca8b0a084c826e3d2a0d0a99 07-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Use newly added devres_release() rather than open coding

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>
8b7485ef623b9171e5a58c67eef5912a27db5822 21-May-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Call set_voltage_time_sel() only when the regulator is on

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>
cffc9592fde309deafce12362e0a285108cfa3c8 20-May-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Allow drivers to set voltage mapping table in regulator_desc

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>
b1a868310e7024650918119d292129446b2f8336 14-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Don't open code _regulator_is_enabled()

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
e81dba85c6388dfabcb76cbc2b8bd02836a53ae5 13-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Release regulator-regulator supplies on error

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
ccfcb1c3cf5616ebd9c61e6c834af3b87fe6b7f7 14-May-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Ensure simple linear voltage mappings falls within the specified range

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>
bca7bbfff37808d56355bbcf0ceec34f0cc6c85d 09-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Allow drivers to set simple linear voltage maps as data

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>
e843fc4616485bbd8b5a115f5bd4f73808656373 09-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Allow regulators to provide a voltage to selector mapping

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>
dcf701125eefea6baf72753533cb8b60fb0e3934 08-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Warn on missing struct device

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>
968c2c1707a3396ccd6e7e6c5ddaf658a6d3bd66 07-May-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Actually free the regulator in devm_regulator_put()

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>
6492bc1b1a9cb21d28cde3c70d090c7648c8b0ed 19-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Optimise enable/disable path for always on regulators

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>
854ccbaee7e48734936690a3fd4817c57e98aaad 16-Apr-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Add checking set_mode callback in regulator_set_optimum_mode

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>
cd6dffb4c6c476f5787f4df3eda7ecb16e25780d 15-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Provide standard enable operations for regmap users

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>
4ab5b3d92c863e55fa28cc41a7b005b7ae87afee 15-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Provide regmap based voltage_sel operations

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>
65b19ce6c223287ac95bbc22b12ef5a2738472d1 15-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Allow drivers to pass in a regmap

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>
8ac0e95d6467ced054565312ecdf0a55a5333c64 14-Apr-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Support setting suspend_[mode|voltage] if set_suspend_[en|dis]able is NULL

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>
3f24f5ada638dd07705bd83ebcc80044d587f374 13-Apr-2012 Axel Lin <axel.lin@gmail.com> regulator: core: Fix getting input_uV when supplied by another regulator

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>
32c8fad438200b523ec44a49b40cb8ffdf715f7c 11-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Appease smatch in regulator_register()

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>
c172708d38a401b2f3f841dfcd862b469fa0b670 04-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Use a struct to pass in regulator runtime configuration

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>
eba41a5e8c9473c24c333df288d4fd6a40e98464 04-Apr-2012 Axel Lin <axel.lin@gmail.com> regulator: Support set_voltage_time_sel for drivers implement set_voltage

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>
65f26846b90611742f3b407cc538a1cad33abde8 03-Apr-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Constify the regulator_desc passed in when registering

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>
576ca4367f291a9b240d027670fa2e344edf8c8a 30-Mar-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Pull non-DT supply mapping into regulator_dev_lookup()

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>
6d191a5fc7a969d972f1681e1c23781aecb06a61 29-Mar-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Don't defer probe if there's no DT binding for a supply

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>
01e86f4988297abb403be92bc3b6ad24e1d058de 28-Mar-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: core: Complain if we can't reenable a supply

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>
e032b376551a61662b20a2c8544fbbc568ab2e7f 28-Mar-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix deadlock on removal of regulators with supplies

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>
16fbcc3b1139e90fe560fde5619169db74dc02c2 16-Mar-2012 Rajendra Nayak <rnayak@ti.com> regulator: Fix up a confusing dev_warn when DT lookup fails

of_parse_phandle() returns NULL either if the property name
itself does not exist or if it (exists and) does not
reference a valid phandle.
Giving out a warn like the one below (that the property references
an invalid phandle) can be confusing when the property itself
does not exist in the node.
Fix it with a more sensible message and make it a dev_dbg instead
of a dev_warn.

Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
04bf30115f4ba2beda1efb6cfbae49cdc757f3a9 11-Mar-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Support driver probe deferral

If we fail to locate a requested regulator return -EPROBE_DEFER. If drivers
pass this error code through to their caller (which they really should)
then this will ensure that the probe is retried later when further devices
become available. In the unusual case where a driver doesn't want this
it can override the default behaviour.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
073512336e6333ffcaabbb2b92f8e616db3a0789 24-Feb-2012 Axel Lin <axel.lin@gmail.com> regulator: Set delay to 0 if set_voltage_time_sel callback returns error

rdev->desc->ops->set_voltage_time_sel may return negative error code.
Set delay to 0 and also show warning if set_voltage_time_sel returns error.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
247514344492a0cf602317d2089bab1301922624 21-Feb-2012 Stephen Boyd <sboyd@codeaurora.org> regulator: Remove ifdefs for debugfs code

If CONFIG_DEBUG_FS=y debugfs functions will never return an
ERR_PTR. Instead they'll return NULL. The intent is to remove
ifdefs in calling code.

Update the code to reflect this. We gain an extra dentry pointer
per struct regulator and struct regulator_dev but that should be
ok because most distros have debugfs compiled in anyway.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
f4d562c6e616bb686f43d38752b2e5b83359e1fc 20-Feb-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Clean up debugfs error handling a bit

Use IS_ERR_OR_NULL() rather than open coding it and ignore errors from
failure to create the supply map.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
b29c7690a764b9829b1034f873f97b7bbfa19565 20-Feb-2012 Axel Lin <axel.lin@gmail.com> regulator: Simplify regulator_bulk_get and regulator_bulk_enable error paths

Start unwind from the point the error happens instead of iterating over all
consumers, then unwind code can be simpler.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
5bc78015998e14bf0362a01fc47e8b63053dbfd8 18-Feb-2012 Axel Lin <axel.lin@gmail.com> regulator: Remove obsolete consumer_dev related comment

consumer_dev is remove by commit 737f36
"regulator: Remove support for supplies specified by struct device".
Thus remove the obsolete comment.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
4a682922817fde4d82fed4303dc902c29d7b2e4e 09-Feb-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Complain if a voltage range is specified but can't be used

It doesn't make much sense to specify a range of voltages consumers can
use if they haven't been given permission to change the voltage. Log if
this happens, probably the user forgot to specify CHANGE_VOLTAGE.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
43f674a322aa8a3404df5785f84dc1351a5d84b6 09-Feb-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Don't add the function name to pr_fmt

Liam pointed out via IM that since we now use the pure function name for
all regulator logging a lot of the messages such as those logging the
constraints are getting a bit noisy due to the implementation detail
that is the function name:

print_constraints: VDDARM: 1000 <--> 1300 mV at 1300 mV at 0 mA

In discussion it seemed like the best thing was to just drop the pr_fmt
and clarify individual log messages where there is an issue otherwise
we get into silly things like renaming the functions to suit the logging.

This is mostly an issue as we have a moderate amount of non-error logging
in the boot sequence to aid debug if something goes wrong since regulator
misconfiguration can kill the system pretty quickly.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
737f360d5bef5e01c6cfa755dca0b449a154c1e0 02-Feb-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Remove support for supplies specified by struct device

This has been deprecated for a very long time now.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Liam Girdwood <lrg@ti.com>
49e226323d462785582750d9f38acca5ffa5dd48 25-Jan-2012 Sylwester Nawrocki <s.nawrocki@samsung.com> regulator: Reverse the disable sequence in regulator_bulk_disable()

Often there is a need for disabling a set of regulators in order opposite
to the enable order. Currently the function regulator_bulk_disable() walks
list of regulators in same order as regulator_bulk_enable(). This may cause
trouble, especially for devices with mixed analogue and digital circuits.
So reverse the disabling sequence of regulator_bulk_disable().
While at it, also correct the comment.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
4a7cbb56fdbd92a47f57ca8b25bf5db35f0d6518 24-Jan-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix documentation for of_node parameter of regulator_register()

Commit 5bc75a886353 ("kernel-doc: fix new warning in regulator core")
added documentation for of_node to address a warning but the
documentation didn't explain what the parameter is for so would be
likely to be unhelpful for users. Clarify that.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
5bc75a886353fa5f386c5ce49a93da1756006d8f 21-Jan-2012 Randy Dunlap <rdunlap@xenotime.net> kernel-doc: fix new warning in regulator core

Fix new kernel-doc warning:

Warning(drivers/regulator/core.c:2741): No description found for parameter 'of_node'

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
e6e740304aa2a49ef09497e6c0bb906ed7987f6b 20-Jan-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Provide devm_regulator_bulk_get()

Allow drivers to benefit from both the bulk APIs and managed resources
simultaneously.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
d5ad34f7cb8b23ab165cabef69577a2a20d53195 20-Jan-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Implement devm_regulator_free()

Allow consumers to free regulators allocated using devm_regulator_get()
if they need to. This will not normally be required.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
070b9079226d4f3e3e7c9f4eb81f2e02e7d99572 17-Jan-2012 Stephen Boyd <sboyd@codeaurora.org> regulator: Add devm_regulator_get()

Add a resource managed regulator_get() to simplify regulator
usage in drivers. This allows driver authors to "get and forget"
about their regulators by automatically calling regulator_put()
when the driver is detached.

[Fixed up a couple of coding style issues -- broonie]

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
e1de2f423462a5c6ba2c902dff1f5ddd8d3dbde3 03-Jan-2012 Donggeun Kim <dg77.kim@samsung.com> regulator: add regulator_bulk_force_disable function

This patch allows consumers to forcibly disable multiple regulator
clients in a single API call.

Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
b2296bd43e781976743354c668a356b0df98e1da 02-Jan-2012 Laxman Dewangan <ldewangan@nvidia.com> regulator: Enable supply regulator if child rail is enabled.

During regulator_register, the rail is set on the provided
machine constraints and if it is enabled then it is also
require to enable the supply regulator. This will make sure
that:
1. Proper reference count for supply regulator to be maintain.
2. Supply regulator should be enable when given rail is enabled.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
32c78de8f17369def492ea3ddd785f0cc140af02 29-Dec-2011 Axel Lin <axel.lin@gmail.com> regulator: Fix checking return value of create_regulator

create_regulator() returns NULL on fail.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
bcda432194fc7c4a2dbe9d7146f00b4b21e66c8c 29-Dec-2011 Axel Lin <axel.lin@gmail.com> regulator: Fix the error handling if create_regulator fails

In the case of create_regulator() fails, goto the error path immediately.
It does not make sense to update rdev->open_count if create_regulator fails.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
a398eaa23e42b73216efbe03dc1d754b2e5d603c 28-Dec-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Export regulator_is_supported_voltage()

It's part of the driver interface so should be available to modules.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
9a8f5e07200dd80fe5979490c36b62f64f70825b 29-Nov-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow regulators to register with no init_data

This allows read-only access to the device configuration which may be
useful for diagnostics.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
58fb5cf5d1edb7e306574833ee55d732918c89e3 28-Nov-2011 Lothar Waßmann <LW@KARO-electronics.de> regulator: fix use after free bug

This is caused by dereferencing 'rdev' after device_unregister() in
the regulator_unregister() function. 'rdev' is freed by
device_unregister(), so it must not be dereferenced after this call.

[Edited commit message for legibility -- broonie]

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
69511a452e6dc6b74fe4f3671a51b1b44b9c57e3 18-Nov-2011 Rajendra Nayak <rnayak@ti.com> regulator: map consumer regulator based on device tree

Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.

For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <&regulator1>;
vpll-supply = <&regulator2>;
};

The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.

of_get_regulator() extracts the regulator node for a given
device, based on the supply name.

Use it to look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.

Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2c043bcbf287dc69848054d5c02c55c20f7a7bc5 18-Nov-2011 Rajendra Nayak <rnayak@ti.com> regulator: pass additional of_node to regulator_register()

With device tree support for regulators, its needed that the
regulator_dev->dev device has the right of_node attached.
To be able to do this add an additional parameter to the
regulator_register() api, wherein the dt-adapted driver can
then pass this additional info onto the regulator core.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
4c78899b92335af0da11e104698e329bb50810b5 02-Nov-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Don't create voltage sysfs entries if we can't read voltage

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
65602c32ee9b5500e3cb617ccec2154ee2191898 17-Jul-2011 Paul Gortmaker <paul.gortmaker@windriver.com> regulator: Add module.h to drivers/regulator users as required

Another group of drivers that are taking advantage of the implicit
presence of module.h -- and will break when we pull the carpet out
from under them during a cleanup. Fix 'em now.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
d1685e4e2c3854782272f32b71f2f3eff5c6e0d0 14-Oct-2011 Heiko Stübner <heiko@sntech.de> regulator: Fix possible nullpointer dereference in regulator_enable()

In the case where _regulator_enable returns an error it was not checked
if a supplying regulator exists before trying to disable it, leading
to a null pointer-dereference if no supplying regulator existed.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
aa59802dedac98dc95310a456121cec6a9d6b63f 03-Oct-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix return code from regulator_disable_deferred()

schedule_delayed_work() returns a bool indicating if the work was already
queued when it succeeds so we need to squash a true down to zero.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
da07ecd93b196819dcec488b7ebec69a71f3819e 11-Sep-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Implement deferred disable support

It is a reasonably common pattern for hardware to require some delay after
being quiesced before the disable has finalised, especially in mixed signal
devices. For example, an active discharge may be required to ensure that
the circuit starts up again in a known state. Avoid having to implement
such delays in the regulator API by providing regulator_deferred_disable()
which will do a regulator_disable() a specified number of milliseconds
after it is called.

Due to the reference counting done on regulators a deferred disable can
be cancelled by doing another regulator_enable().

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
ba55a9741da6c85176987c15e24383b858749aa2 23-Aug-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add debugfs file showing the supply map table

Useful for working out why things aren't getting plugged together properly.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
54abd335fda86d305845f9e62b4bc0997386eb66 21-Jul-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix argument format type errors in error prints

We need to dereference the pointers to print their values.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1a6958e79f9e191c89fe0c13f7452b0bd8097050 15-Jul-2011 Axel Lin <axel.lin@gmail.com> regulator: Fix memory leak in set_machine_constraints() error paths

Properly kfree rdev->constraints in all set_machine_constraints() error paths.
Also properly kfree rdev->constraints in regulator_register() error paths.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
89f425ed5bf3d4fd97e840296dccd75b8e0fe4c9 12-Jul-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Make core more chatty about some errors

Prevent some head scratching by making the core log about some rare but
possible errors with invalid voltage ranges and modes being set.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
5de705194e9883a39f993e2ff96028d5aab99b37 19-Jun-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add basic per consumer debugfs

Report the requested load and voltage for each consumer in debugfs when it
is enabled.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
7d51a0dbe51282f3ed13cadf6e7f13a974374be2 09-Jun-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add rdev_crit() macro

No actual users but provide the macro so there's less surprise when it's
not there.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
3801b86aa482d26a8ae460f67fca29e016491a86 09-Jun-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Refactor supply implementation to work as regular consumers

Currently the regulator supply implementation is somewhat complex and
fragile as it doesn't look like standard consumers but is instead a
parallel implementation. This causes issues with locking and reference
counting.

Move the implementation over to using standard consumers to address this.
Rather than only notifying the supply on the first enable/disable we do so
every time the regulator is enabled or disabled, simplifying locking as we
don't need to hold a lock on the consumer we are about to enable.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e0eaedefda8e14ed3f445f382c568c5d69e4223f 09-Jun-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Include the device name in the microamps_requested_ file

We may have multiple devices requesting a supply with the same name so
include the device name in the generated filename for microamps_requested
to avoid duplicate files.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
f5726ae33c382366ea1b23240d5620dcf675d81d 09-Jun-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Increase the limit on sysfs file names

With verbose filenames we can easily hit 32 characters.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
f21e0e81d81b649ad309cedc7226f1bed72982e0 24-May-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Do bulk enables of regulators in parallel

In order to reduce the impact of ramp times rather than enabling the
regulators for a device in series use async tasks to run the actual
enables. This means that the delays which the enables implement can all
run in parallel, though it does mean that the order in which the
supplies come on may be unstable.

For super bonus fun points if any of the regulators are shared between
multiple supplies on the same device (as is rather likely) then this
will test our locking. Note that in this case we only delay once for
each physical regulator so the threads shouldn't block each other while
delaying.

It'd be even nicer if we could coalesce writes to a shared enable registers
in PMICs but that's definitely future work, and it may also be useful
and is certainly more achievable to optimise out the parallelism if none
of the regulators implement ramp delays.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
cb220d16f91f8d5fa1450c7af17e028e8cb3f0f1 23-May-2011 Axel Lin <axel.lin@gmail.com> regulator: Fix _regulator_get_voltage if get_voltage callback is NULL

In the case of get_voltage callback is NULL, current implementation in
_regulator_get_voltage will return -EINVAL.

Also returns proper error if ret is negative value.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
4aa922c024b2a194d7b68b22a66dfcf86e7838b3 14-May-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Only apply voltage constraints from consumers that set them

When applying the set_voltage() requests from consumers skip over those
consumers that haven't set anything, otherwise we'll come out with a
maximum voltage of zero.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
a4b4148379ef1ad460fc1aa6bcf2cde99cd91166 14-May-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: If we can't configure optimum mode we're always in the best one

If either a regulator driver can't tell us what the optimum mode is (or
doesn't have modes in the first place) or the system doesn't allow DRMS
changes then it's more helpful for users to just say that we're in the
optimal mode, even if it's from a selection of one.

Still report errors if the process of picking and setting a mode changes as
this may indicate that we're stuck in a low power mode and unable to deliver
a higher current that the consumer just asked for.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
bf5892a8167e4aa5a9a6d72f803fde850e0c5753 08-May-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Support voltage offsets to compensate for drops in system

Some systems, particularly physically large systems used for early
prototyping, may experience substantial voltage drops between the regulator
and the consumers as a result of long traces in the system. With these
systems voltages may need to be set higher than requested in order to
ensure reliable system operation.

Allow systems to work around such hardware issues by allowing constraints
to supply an offset to be applied to any requested and reported voltages.
This is not ideal, especially since the voltage drop may be load dependant,
but is sufficient for most affected systems, it is not expected to be used
in production hardware. The offset is applied after all constraint
processing so constraints should be specified in terms of consumer values
not physically configured values.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
492c826b9facefa84995f4dea917e301b5ee0884 08-May-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Remove supply_regulator_dev from machine configuration

supply_regulator_dev (using a struct pointer) has been deprecated in favour
of supply_regulator (using a regulator name) for quite a few releases
now with a warning generated if it is used and there are no current in tree
users so just remove the code.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
82d158397b6eeb464263a6ef6a739c4118a34720 09-May-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Factor out references to rdev in regulator_force_disable()

Don't go looking up the rdev pointer every time, just use a local variable
like everything else.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
22c51b47aa7cded7e4768540ebbbfddc91e31d90 01-Apr-2011 Axel Lin <axel.lin@gmail.com> regulator: Fix the argument of calling regulator_mode_constrain

The second parameter of regulator_mode_constrain takes a pointer.

This patch fixes below warning:
drivers/regulator/core.c: In function 'regulator_set_mode':
drivers/regulator/core.c:2014: warning: passing argument 2 of 'regulator_mode_constrain' makes pointer from integer without a cast
drivers/regulator/core.c:200: note: expected 'int *' but argument is of type 'unsigned int'

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@vega.(none)>
2c6082341d1896218ca974cc2bb6876e36fcba5c 29-Mar-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: When constraining modes fall back to higher power modes

If a mode requested by a consumer is not allowed by constraints
automatically fall back to a higher power mode if possible. This
ensures that consumers get at least the output they requested while
allowing machine drivers to transparently limit lower power modes
if required.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
25985edcedea6396277003854657b5f3cb31a628 31-Mar-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
88cd222b259d62148ab8c82398498b1a01314476 17-Mar-2011 Linus Walleij <linus.walleij@linaro.org> regulator: provide consumer interface for fall/rise time

This exposes the functionality for rise/fall fime when setting
voltage to the consumers.

Cc: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
77af1b2641faf45788a0d480db94082ebee931dc 17-Mar-2011 Linus Walleij <linus.walleij@linaro.org> regulator: add set_voltage_time_sel infrastructure

This makes it possible to set the stabilization time for voltage
regulators in the same manner as enable_time(). The interface
only supports regulators that implements fixed selectors.

Cc: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
7a32b589a9c856493bccb02db55047edc04eee7b 11-Mar-2011 MyungJoo Ham <myungjoo.ham@samsung.com> Regulator: add suspend-finish API for regulator core.

The regulator core had suspend-prepare that turns off the regulators
when entering a system-wide suspend. However, it did not have
suspend-finish that pairs with suspend-prepare and the regulator core
has assumed that the regulator devices and their drivers support
autonomous recover at resume.

This patch adds regulator_suspend_finish that pairs with the
previously-existed regulator_suspend_prepare. The function
regulator_suspend_finish turns on the regulators that have always_on set
or positive use_count so that we can reset the regulator states
appropriately at resume.

In regulator_suspend_finish, if has_full_constraints, it disables
unnecessary regulators.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
--
Updates
v3
comments corrected (Thanks to Igor)
v2
disable unnecessary regulators (Thanks to Mark)
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
23c2f041efa891e6ec0706dc9ad4f776a9aa8c14 24-Feb-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: If we fail when setting up a supply say which supply

Makes it a bit easier to identify if it's a problem with the supplies,
the usual error would be omitting the supply name entirely.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1130e5b3ff4a7f3f54a48d46e9d0d81b47765bd8 22-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add initial per-regulator debugfs support

We only expose the use and open counts to userspace, providing a tiny
bit of insight into what the API is up to.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
21cf891a47ff5e7bd77fdc524a25072c447d56bb 22-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Make regulator_has_full_constraints a bool

It's a boolean value so use the type.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
13ce29f80fe3f61d3865b90244b1d1430f553e9f 17-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Clean up logging a bit

The recent introduction of standard regulator API logging macros means
that all our log messages have at least the function name in them and
logging that the constraints are for the regulator API is probably a
bit much.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
95a3c23ae620c1b4c499746e70f4034bdc067737 16-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Optimise out noop voltage changes

If a consumer sets the same voltage range as is currently configured
for that consumer there's no need to run through setting the voltage
again. This pattern may occur with some CPUfreq implementations where
the same voltage range is used for multiple frequencies.

Reported-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
606a25628187ce863b48d43ca42bc0cbe8342de9 16-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add API to re-apply voltage to hardware

When cooperating with an external control source the regulator setup
may be changed underneath the API. Currently consumers can just redo
the regulator_set_voltage() to restore a previously set configuration
but provide an explicit API for doing this as optimsations in the
regulator_set_voltage() implementation will shortly prevent that.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
ded06a5270ddd6c3c3e25d9ddcaaaa4cb8385c2f 16-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Only notify voltage changes when they succeed

Currently we notify a voltage change whenever we exit set_voltage(),
even if the change failed for some reason (eg, a constraints issue).
This shouldn't cause any substantial ill effects but is wasteful as
listeners get notified on noops. Fix this by moving the notification
into _do_set_voltage() and only notifying if we don't return an error.

Reported-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e8eef82b2c652d031bee9dff9762325672f5a1e0 12-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Provide a selector based set_voltage_sel() operation

Many regulator drivers implement voltage setting by looping through a
table of possible values, normally because the set of available voltages
can't be mapped onto selectors with simple calcuation. Factor out these
loops by providing a variant of set_voltage() which takes a selector rather
than a voltage range as an argument and implementing a loop through the
available selectors in the core.

This is not going to be suitable for use with all devices as when the
regulator voltage can be mapped onto selector values with a simple
calculation the linear scan through the available values will be more
expensive than just doing the calculation, especially for regulators
that provide fine grained voltage control.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
757902513019e6ee469791ff76f954b19ca8d036 12-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Factor out voltage set operation into a separate function

Push all the callers of the chip set_voltage() operation out into a single
function to facilitiate future refactoring.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
476c2d83c7ffb2429b2a504fbdb4326fc8a9d0e8 10-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow drivers to report voltages as selectors

Since drivers already have to provide an API for translating selectors
into voltages they may as well just report the selector values directly
to the core API rather than implement the lookup themselves. The old
interface is left in place for now, but may be removed in future.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1bf5a1f86a328122714680cd59951074b4f31e07 10-Dec-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Use _regulator_get_voltage() consistently

Rather than referencing the get_voltage() operation directly in the
ops struct use the internal _regulator_get_voltage() API call to do
so, facilitating refactoring.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
43e7ee33f2a8d20238267b789791386739247478 06-Dec-2010 Joe Perches <joe@perches.com> drivers/regulator: Update WARN uses

Align arguments.

Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
05fda3b1abc23d832144e9497fb218870927d645 03-Dec-2010 Thomas Petazzoni <t-petazzoni@ti.com> regulator: Take into account the requirements of all consumers

Extend the regulator_set_voltage() function to take into account the
voltage requirements of all consumers of the regulator being changed,
in order to set the voltage to the minimum voltage acceptable to all
consumers. The existing behaviour was that the latest
regulator_set_voltage() call would win over previous
regulator_set_voltage() calls even if setting the voltage to a
non-acceptable level from other consumers.

Signed-off-by: Thomas Petazzoni <t-petazzoni@ti.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
5da84fd99bb1ab1c7cd39d0cf7c08bb63931a59a 30-Nov-2010 Joe Perches <joe@perches.com> regulator: Add and use rdev_<level> macros

On Tue, 2010-11-30 at 10:52 +0000, Mark Brown wrote:
> On Mon, Nov 29, 2010 at 05:12:56PM -0800, Joe Perches wrote:
> > Just to please broonie...
> > Signed-off-by: Joe Perches <joe@perches.com>
> As usual when fixing review issues please revise your original patch
> rather than posting a fresh patch.

Here's an earlier comment:

On Thu, 2010-11-18 at 13:30 +0000, Mark Brown wrote:
> This looks reasonable, please rebase on top of Daniel's patches and
> submit it properly (with changelog and so on).

Sometimes it's simpler for an upstream maintainer to do
something like:

git am -s <patch1.mbox>
patch -p1 < patch2.mbox
git commit --amend file

instead of back and forthing.

Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
f8c12fe329c8da9f50d8b2b1183eeaa4d587e747 29-Nov-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Copy constraints from regulators when initialising them

Currently the regulator API uses the constraints structure passed in to
the core throughout the lifetime of the object. This means that it is not
possible to mark the constraints as __initdata so if the kernel supports
many boards the constraints for all of them are kept around throughout the
lifetime of the system, consuming memory needlessly. By copying constraints
that are actually used we allow the use of __initdata, saving memory when
multiple boards are supported.

This also means the constraints can be const.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
50ba5ca4be30674517ca33425648ec43d93f9a69 22-Nov-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Remove regulator core version announcement

The version hasn't been updated since the regulator API was merged in
2.6.27 so just remove it - now we're in mainline the kernel version is
much more useful.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
4c35508fc0b7883820923b3b8eb9fea25d35cf72 22-Nov-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix obfuscated log messages

Don't use %s to format fixed static strings into log messages, it just
makes searching for and reading the message in the kernel source
needlessly hard.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1d7372e15ebd7f56a336fabe6ee31f8e692cd9cb 18-Nov-2010 Daniel Walker <dwalker@codeaurora.org> drivers: regulator: core: convert to using pr_ macros

The regulator framework uses a lot of printks with a
specific formatting using __func__. This converts them
to use pr_ calls with a central format string.

Cc: bleong@codeaurora.org
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
c5e28ed78274468b92522e7f1e9a5e6080559100 18-Nov-2010 Daniel Walker <dwalker@codeaurora.org> drivers: regulator: core: use pr_fmt

This adds a pr_fmt line which uses the __func__ macro. I also
convert the current pr_ lines to remove their __func__ usage.

Cc: bleong@codeaurora.org
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
acaf6ffefdf65188071f88664435b86651d70e7c 10-Nov-2010 Bengt Jonsson <bengt.g.jonsson@stericsson.com> regulator: enable supply regulator only when use count is zero

Supply regulators are disabled only when the last
reference count is removed on the child regulator
(the use count goes from 1 to 0). This patch changes
the behaviour of enable so the supply regulator is
enabled only when the use count of the child
regulator goes from 0 to 1.

Signed-off-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
02fa3ec01a0df7a8ccc356d8e245a9a1423b3596 10-Nov-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add basic trace facilities

Provide some basic trace facilities to the regulator API. We generate
events on regulator enable, disable and voltage setting over the actual
hardware operations (which are assumed to be the expensive ones which
require interaction with the actual device). This is intended to facilitate
debug of the performance and behaviour with consumers allowing unified
traces to be generated including the regulator operations within the
context of the other components of the system.

For enable we log the explicit delay for the voltage ramp separately to
the interaction with the hardware to highlight the time consumed in I/O.
We should add a similar delay for voltage changes, though there the
relatively small magnitude of the changes in the context of the I/O
costs makes it much less critical for most regulators.

Only hardware interactions are currently traced as the primary focus is
on the performance and synchronisation of actual hardware interactions.
Additional tracepoints for debugging of the logical operations can be
added later if required.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
3a93f2a9f4d8f73d74c0e552feb68a10f778a219 10-Nov-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Report actual configured voltage to set_voltage()

Change the interface used by set_voltage() to report the selected value
to the regulator core in terms of a selector used by list_voltage().
This allows the regulator core to know the voltage that was chosen
without having to do an explict get_voltage(), which would be much more
expensive as it will generally access hardware.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
63cee946148821bca42be10130b061c2d0f5af7e 04-Nov-2010 Mattias Wallin <mattias.wallin@stericsson.com> regulator: lock supply in regulator enable

This patch add locks around regulator supply enable.

Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
06c63f9396133f312c5a49c2285c2c8015e80934 19-Nov-2010 Randy Dunlap <randy.dunlap@oracle.com> regulator: fix kernel-doc for set_consumer_device_supply

Fix kernel-doc warning for set_consumer_device_supply():

Warning(drivers/regulator/core.c:912): missing initial short description on line:
* set_consumer_device_supply: Bind a regulator to a symbolic supply

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
f3c18a87f3ddcfd31b16f689d01eb6adcc99de74 10-Nov-2010 Bengt Jonsson <bengt.g.jonsson@stericsson.com> regulator: enable supply regulator only when use count is zero

Supply regulators are disabled only when the last
reference count is removed on the child regulator
(the use count goes from 1 to 0). This patch changes
the behaviour of enable so the supply regulator is
enabled only when the use count of the child
regulator goes from 0 to 1.

Signed-off-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
3aa713e76e8f562c0d28faf18873c4f1836b17c9 04-Nov-2010 Mattias Wallin <mattias.wallin@stericsson.com> regulator: lock supply in regulator enable

This patch add locks around regulator supply enable.

Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
7727da22e820a96ab394db2fc0ab58f7f7ecb323 05-Nov-2010 Axel Lin <axel.lin@gmail.com> regulator: Return proper error for regulator_register()

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e36c1df8e18183ba2c691fe766a52c94020cdc5e 05-Nov-2010 Axel Lin <axel.lin@gmail.com> regulator: Ensure enough delay time for enabling regulator

Integer division will truncate the result, this patch ensures we have
enough delay time for enabling regulator.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
aa7a74040a989eeb7a9265550a2538863e842a93 05-Nov-2010 Axel Lin <axel.lin@gmail.com> regulator: Remove a redundant device_remove_file call in create_regulator

We already have device_remove_file() in error path,
no need to call it before goto link_name_err.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
b12a1e29af595d05612153bcb85258193bbf9382 02-Nov-2010 Mattias Wallin <mattias.wallin@stericsson.com> regulator: regulator disable supply fix

This patch fixes a disable failure when regulator supply is used.
A while loop in regulator disable checks for supply pointer != NULL
but the pointer is not always updated, resulting in the while loop
running too many times causing a disable failure.

Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
8cbf811dfd027bde8504e541d0009c5722b98be5 08-Oct-2010 Jeffrey Carlyle <jeff.carlyle@motorola.com> regulator: avoid deadlock when disabling regulator with supply

I have a regulator A that sets regulator B as its supply. When I call
set_supply to add B as the supply for A, regulator A gets added to the
supply_list for regulator B.

When I call regulator_disable(A), I end up with a call chain like this:

regulator_disable(A)
> mutex_lock(A)
> _regulator_disable(A)
>> _regulator_disable(B)
>>> _notifier_call_chain(B)
>>>> mutex_lock(A)

Which results in dead lock since we are trying to acquire the mutex lock
for regulator A which we already hold.

This patch addresses this issue by moving the call to disable regulator
B outside of the lock aquired inside the initial call to
regulator_disable.

This change also addresses the issue of not acquiring the mutex for
regulator B before calling _regulator_disable(B).

Signed-off-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
688fe99a439f7c9dfcc52fbf7cb347f140a2dc8b 06-Oct-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add option for machine drivers to enable the dummy regulator

Allow machine drivers to explicitly enable the use of the dummy regulator,
enabling simpler support for systems with only a few specific supplies
visible to software.

It is strongly recommended that this is not used on systems with
substantial software control over their PMICs, for maximum functionality
constrints should be as fully specified as possible.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e4a6376b3b2999d169b602a582a8819d95ff79bc 22-Sep-2010 Cyril Chemparathy <cyril@ti.com> regulator: fix typo in current units

This patch fixes a typo that incorrectly reports mA numbers as uA.

Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
ad7725cb43b8badb2fec2c2bfca07c067f2e19a7 19-Sep-2010 Vasiliy Kulikov <segooon@gmail.com> regulator: fix device_register() error handling

If device_register() fails then call put_device().
See comment to device_register.

Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
068a2782f59efe5855091860bbccbadf1c72fffd 29-Jul-2010 Guenter Roeck <guenter.roeck@ericsson.com> regulator: Remove owner field from attribute initialization in regulator core driver

Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
500b4ac90d1103a7c302d5bb16c53f4ffc45d057 17-May-2010 Sundar R Iyer <sundar.iyer@stericsson.com> regulator: return set_mode is same mode is requested

On Mon, 2010-05-17 at 17:34 +0200, Mark Brown wrote:
> This doesn't seem like the right error handling - if the driver has a
> set_mode() you'd *expect* it to have a get_mode() but there's no need
> for it to be a strict requirement.
True. In such a case, even a valid request would be lost! So now
in the updated patch:
- check if get_mode is present to avoid oops;
- if get_mode is not present, proceed anyways for the request.

Here is the updated patch:

>From bad0d5eb51ef84be5b100e3dd0f5a590ea0529b6 Mon Sep 17 00:00:00 2001
From: Sundar R Iyer <sundar.iyer@stericsson.com>
Date: Fri, 14 May 2010 15:14:17 +0530
Subject: [PATCH 1/1] regulator: return set_mode when same mode is requested

save I/O costs by returning when the same mode is
requested for the regulator

Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Sundar R Iyer <sundar.iyer@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
d4033b54fc91221b13e2850bf298683c0f2ff37d 29-Apr-2010 Jani Nikula <ext-jani.1.nikula@nokia.com> regulator: simplify regulator_register() error handling

Simply remove all consumer supplies for the regulator on errors. Remove
unset_consumer_device_supply() which is no longer used.

Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
47bd53f0e8008294ff58c5b37d713f25a8dc56aa 29-Apr-2010 Jani Nikula <ext-jani.1.nikula@nokia.com> regulator: fix unset_regulator_supplies() to remove all matches

Remove all matching consumer supplies, not just the first, to not leave
dangling pointers.

Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
23b5cc2ab6783256cf06779e1d522482b819b808 29-Apr-2010 Jani Nikula <ext-jani.1.nikula@nokia.com> regulator: prevent registration of matching regulator consumer supplies

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Pointer comparison is not sufficient for non-NULL device name matching,
so use strcmp(). Otherwise the semantics remain the same.

Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
0178f3e28e2166664916265c5d4922b1376b9fa1 26-Apr-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow regulator-regulator supplies to be specified by name

When one regulator supplies another allow the relationship to be specified
using names rather than struct regulators, in a similar manner to that
allowed for consumer supplies. This allows static configuration at compile
time, reducing the need for dynamic init code.

Also change the references to LINE supply to be system supply since line
is sometimes used for actual supplies and therefore potentially confusing.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
5a0e3ad6af8660be21ca98a971cd00f331318c05 24-Mar-2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
4f26a2abe1eed18dc6adddf2d0ae5553e51578c2 12-Mar-2010 Ameya Palande <ameya.palande@nokia.com> regulator: Get rid of lockdep warning

WARNING: at kernel/lockdep.c:2706 sysfs_add_file_mode+0x4c/0xa8()

Difference between v1 and v2:
Moved sysfs_attr_init() call as first one to access the structure.

Signed-off-by: Ameya Palande <ameya.palande@nokia.com>
CC: Liam Girdwood <lrg@slimlogic.co.uk>
CC: Mark Brown <broonie@opensource.wolfsonmicro.com>
CC: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
88393161210493e317ae391696ee8ef463cb3c23 16-Mar-2010 Thomas Weber <swirl@gmx.li> Fix typos in comments

[Ss]ytem => [Ss]ystem
udpate => update
paramters => parameters
orginal => original

Signed-off-by: Thomas Weber <swirl@gmx.li>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
34abbd68efe09765465b81dfedeee9994f13302f 12-Feb-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Provide optional dummy regulator for consumers

In order to ease transitions with drivers are boards start using regulators
provide an option to cause all regulator_get() calls to succeed, with a
dummy always on regulator being supplied where one has not been configured.
A warning is printed whenever the dummy regulator is used to aid system
development.

This regulator does not implement any regulator operations but will allow
simple consumers which only do enable() and disable() calls to run. It
is kept separate from the fixed voltage regulator to avoid Kconfig
confusion on the part of users when it is extended to allow boards to
explicitly use the dummy regulator to simplify cases where the majority
of supplies are from fixed regulators without software control.

This option is currently only effective for systems which do not specify
full constriants. If required an override could also be provided to allow
these systems to use the dummy regulator, though it is likely that
unconfigured supplies on such systems will lead to error due to
regulators being powered down more aggressively when not in use.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
9a7f6a4c6edc84748c6477c9df56691a0e61b8fd 11-Feb-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Assume regulators are enabled if they don't report anything

If a regulator driver does not provide a way to query if the driver is
enabled then assume that it is enabled. This is very likely to reflect
the actual state is more useful for callers than reporting an error.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
31aae2beeb3d601d556b6a8c39085940ad1e9f42 21-Dec-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow regulators to specify the time taken to ramp on enable

Regulators may sometimes take longer to enable than the control operation
used to do so, either because the regulator has ramp rate control used to
limit inrush current or because the control operation is very fast (GPIO
being the most common example of this). In order to ensure that consumers
do not rely on the regulator before it is enabled provide an enable_time()
operation and have the core delay for that time before returning to the
caller.

This is implemented as a function since the ramp rate may be specified in
voltage per unit time and therefore the time depend on the configuration.
In future it would be desirable to allow the bulk operations to run the
delays for multiple enables in parallel but this is not currently supported.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
84b6826306119dc3c41ef9d7ed6c408112f63301 01-Dec-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add notifier event on regulator disable

The intended use case is for drivers which disable regulators to save
power but need to do some work to restore the hardware state when
restarting. If the supplies are not actually disabled due to board
limits or sharing with other active devices this notifier allows the
driver to avoid unneeded reinitialisation, particularly when used with
runtime PM.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
973e9a2795b3b41d8408a0bb6f87b783c5efc88a 11-Feb-2010 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix display of null constraints for regulators

If the regulator constraints are empty and there is no voltage
reported then nothing will be added to the text displayed for the
constraints, leading to random stack data being printed. This is
unlikely to happen for practical regulators since most will at
least report a voltage but should still be fixed.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
eb143ac1b9f56ca9c6dc782d795acda1f60c5fd2 15-Dec-2009 Lars-Peter Clausen <lars@metafoo.de> regulator: Fix unbalanced disables/enables in regulator_bulk_{enable,disable} error path

Currently it is possible for regulator_bulk_{enable,disable} operations to
generate unbalanced regulator_{disable,enable} calls in its error path.
In case of an error only those regulators of the bulk operation which actually
had been enabled/disabled should get their original state restored.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
fa2984d4691c96367d6666694ecc6744135174c6 27-Nov-2009 Stefan Roese <sr@denx.de> regulator: core.c: Small coding style cleanup (indentation fixup)

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
638f85c54f4fed0f8f1fbc23745a8f334112e892 22-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Handle regulators without suspend mode configuration

Since some regulators in the system may not support suspend mode
configuration we need to allow some regulators to have a missing
suspend mode configuration. Do this by requiring that disabled
regulators are explicitly flagged and then skip over regulators
that have no state specified.

Try to avoid surprises by warning the if we could set the state
but no configuration is provided. This also ensures that an all
zeros configuration generates a warning rather than silently
disabling the regulator.

Reported-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1083c39346d482b9001944d05c09191027892226 22-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Factor out regulator name pretty printing

Some of the regulator API functions have code to allow the machine
constraints to override the device supplied name for the regulator
in the constraints in order to help tie logging to supplies on the
board and disambiguate when there is more than one regulator chip
in the system. Factor this code out into a new rdev_get_name()
function and use it throughout the regulator API so that we always
use the same name.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
8f031b48cd2eab5fc3e4dffa06706372e90d63fe 22-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Display actual settings with constraints

When voltage or current constraints are either missing or specify
a range display the actual setting along with the constraints if
we can. This can aid debugging of configuration problems.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
af5866c9cdc9e43ef775a14765fd8eab95c7fd20 22-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Also lift apply_uV into machine_constraints_voltage()

It makes sense to do all the voltage configuration in the one split
out function.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e79055d62ea6ca3c36962209f4c819614972c95a 19-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Factor out voltage constraint setup

This allows constraints to take effect on regulators that support
voltage setting but for which the board does not specify a voltage
range (for example, because it is fixed correctly at system startup).

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
5b307627738f1f6cbc31fad9e28a299b5fe55602 13-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Report error codes for bulk operations

If we're going to log an error we may as well log what the error
code that we're failing on is.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
60ef66fcf40f0e7bc9579981aa16bd8218942a83 13-Oct-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Handle missing constraints in _regulator_disable()

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
a7433cff9ed8e7982de8e0f210f0325d0f3d1949 26-Aug-2009 Linus Walleij <linus.walleij@stericsson.com> REGULATOR Handle positive returncode from enable

This makes _regulator_enable() properly handle the case where
a regulator is already on when you try to enable it. Currently
it will erroneously handle positive return values as an error.

Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
9a2372fa7a403ba327873d0208a619d781a8a150 03-Aug-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: regulator_enable() permission checking

The regulator_enable() code wasn't actually checking that the
machine constraints had given permission to enable the regulator.
Add code to do that, but only if the regulator is not already on
due to something like always_on or being left on at startup since
in those cases there's no physical change being introduced and the
constraint wouldn't make any sense.

Also add matching code for disable(). We need to do less there since
either regulator_enable() should have succeeded first or the board
setup makes no sense.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
9332546fe88fa88bf6a7d9b1dce53ff5d314934e 03-Aug-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Push locking for regulator_is_enabled() out

Allows use by more of the internal regulator API code.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
f25e0b4fcc38d120e704c377791158c4b2a54daa 03-Aug-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Check for constraints in regulator_init_complete()

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
b39480ac37951de126455991744c9dbb61bbb839 03-Aug-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Check for constraints before using them for name

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
9ed2099edca26d07947beb42c12bd1d6669e82bc 21-Jul-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix support for deviceless supply mappings

The patch to add support for looking up consumers by device name
had the side effect of causing us to require a device which is
at best premature since at least cpufreq still operates outside
the device model. Remove that requirement.

Reported-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
6bf87d17c9f5b855e9dde7b3d6f726385b966814 21-Jul-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Warn when unregistering an in-use regulator

We're probably going to start oopsing fairly soon after this happens.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
a7a1ad9066e0266c8a4357ba3dbaeebfb80f531d 21-Jul-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add regulator voltage range check API

Simplify checking of support for voltage ranges by providing an API which
wraps the existing count and list operations.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
5ffbd136e6c51c8d1eec7a4a0c5d2180c81aea30 21-Jul-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add regulator_get_exclusive() API

Some consumers require complete control of the regulator and can't
tolerate sharing it with other consumers, most commonly because they need
to have the regulator actually disabled so can't have other consumers
forcing it on. This new regulator_get_exclusive() API call allows these
consumers to explicitly request this, documenting the assumptions that
they are making.

In order to simplify coding of such consumers the use count for regulators
they request is forced to match the enabled state of the regulator when
it is requested. This is not possible for consumers which can share
regulators due to the need to keep track of the ownership of use counts.

A new API call is used rather than an additional argument to the existing
regulator_get() in order to avoid merge headaches with driver code in
other trees.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
40f9244f4da8976eeb6d5ed6313c635ba238a9d3 17-Jun-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow consumer supplies to be set up with dev_name()

Follow the approach suggested by Russell King and implemented by him in
the clkdev API and allow consumer device supply mapings to be set up
using the dev_name() for the consumer instead of the struct device.
In order to avoid making existing machines instabuggy and creating merge
issues the use of struct device is still supported for the time being.

This resolves problems working with buses such as I2C which make the
struct device available late providing that the final device name is
known, which is the case for most embedded systems with fixed setups.

Consumers must still use the struct device when calling regulator_get().

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
be721979dd6b335e4ab6f83abb5cc11c33662aa8 04-Aug-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Provide mode to status conversion function

This is useful for implementing get_status() in terms of get_mode().

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
3e59091828ed5406c879b899b4257fcef7271e2c 28-Apr-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix default constraints for fixed voltage regulators

Default voltage constraints were being provided for fixed voltage
regulator where board constraints were not provided but these constraints
used INT_MIN as the default minimum voltage which is not a valid value
since it is less than zero. Use 1uV instead.

Also set the default values we set in the constraints themselves since
otherwise the max_uV constraint we determine will not be stored in the
actual constraint strucutre and will therefore not be used.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
53032dafc6b93ac178ca2340ff8eb4ee2b3d1a92 25-Apr-2009 Paul Walmsley <paul@pwsan.com> regulator core: fix double-free in regulator_register() error path

During regulator registration, any error after device_register() will
cause a double-free on the struct regulator_dev 'rdev'. The bug is in
drivers/regulator/core.c:regulator_register():

...
scrub:
device_unregister(&rdev->dev);
clean:
kfree(rdev); <---
rdev = ERR_PTR(ret);
goto out;
...

device_unregister() calls regulator_dev_release() which frees rdev. The
subsequent kfree corrupts memory and causes some OMAP3 systems to oops on
boot in regulator_get().

Applies against 2.6.30-rc3.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
cd78dfc6c6e321a310a73ef7b0df3d262704dd55 14-Apr-2009 Diego Liziero <diegoliz@gmail.com> drivers/regulator: fix when type is different from REGULATOR_VOLTAGE or REGULATOR_CURRENT

When regulator_desc->type is something different from REGULATOR_VOLTAGE or REGULATOR_CURRENT
the if should probably return ERR_PTR(-EINVAL)

The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

@@ expression E; constant C; @@
(
- !E == C
+ E != C
)

Signed-off-by: Diego Liziero <diegoliz@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
036de8efae4b81f8e1504fab654070cecce6dfa9 08-Apr-2009 Dan Carpenter <error27@gmail.com> unreachable code in drms_uA_update()

I removed the extra semi-colon and indented the return statement.

The unreachable code was found by smatch (http://repo.or.cz/w/smatch.git).
The patch was compile tested.

regards,
dan carpenter

Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
ca7255614e0861e36480103f4a402a115803d7b5 16-Mar-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Support disabling of unused regulators by machines

At present it is not possible for machine constraints to disable
regulators which have been left on when the system starts, for example
as a result of fixed default configurations in hardware. This means that
power may be wasted by these regulators if they are not in use.

Provide intial support for this with a late_initcall which will disable
any unused regulators if the machine has enabled this feature by calling
regulator_has_full_constraints(). If this has not been called then print
a warning to encourage users to fully specify their constraints so that
we can change this to be the default behaviour in future.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
50f075963f127d713ff0c30359baefc0f89d9ae2 16-Mar-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Don't increment use_count for boot_on regulators

Don't set use_count for regulators that are enabled at boot since this
stops the supply being disabled by well-behaved consumers which do
balanced enables and disabled. Any consumers which don't do disables
which are not matched by enables are unable to share regulators - shared
regulators are the common case so the API should facilitate them.

Consumers that want to disable regulators that are enabled when they
start have two options:

- Do a regulator_enable() prior to the disable to bring the use count
in sync with the hardware state; this will ensure that if the
regulator was enabled by another driver then this consumer will play
nicely with it.
- Use regulator_force_disable(); this explicitly bypasses any checks
done by the core and documents the inability of the driver to share
the supply.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
cd94b5053081963614f6ad77b9b66a7968056c84 12-Mar-2009 David Brownell <dbrownell@users.sourceforge.net> regulator: refcount fixes

Fix some refcounting issues in the regulator framework, supporting
regulator_disable() for regulators that were enabled at boot time
via machine constraints:

- Update those regulators' usecounts after enabling, so they
can cleanly be disabled at that level.

- Remove the problematic per-consumer usecount, so there's
only one level of enable/disable.

Buggy consumers could notice different bug symptoms. The main
example would be refcounting bugs; also, any (out-of-tree) users
of the experimental regulator_set_optimum_mode() stuff which
don't call it when they're done using a regulator.

This is a net minor codeshrink.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1dc60343f874ce4bfbbc2c3d2f7865fc897df479 12-Mar-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Don't warn if we failed to get a regulator

The consumer can print a message if required, some consumers may have
optional regulators and wish to downgrade the logging for them or ignore
their absence.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
cacf90f24e80cec9334f98e0377149f943fe9f16 02-Mar-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow boot_on regulators to be disabled by clients

Rather than incrementing the reference count for boot_on regulators
(which prevents them being disabled later on) simply force the
regulator to be enabled when applying the constraints. Previously
boot_on was essentially equivalent to always_on.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
3e2b9abda554e9f6105996dca77cca9ef98de17a 10-Mar-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Don't warn on omitted voltage constraints

Specifying voltage constraints is optional (and only needed if the
consumer is allowed to change the voltage) so don't complain unless
a voltage has been specified.

Also avoid surprises with a dangling else while we're here.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
4367cfdc7c657ad8a797f51b9ffd3c64b31910e7 26-Feb-2009 David Brownell <dbrownell@users.sourceforge.net> regulator: enumerate voltages (v2)

Add a basic mechanism for regulators to report the discrete
voltages they support: list_voltage() enumerates them using
selectors numbered from 0 to an upper bound.

Use those methods to force machine-level constraints into bounds.
(Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ... so the range of
voltages is then 2.4V to 3.3V on this board.)

Export those voltages to the regulator consumer interface, so for
example regulator hooked up to an MMC/SD/SDIO slot can report the
actual voltage options available to cards connected there.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
a308466c24b4f42bab6945026e938874d22cde50 26-Feb-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Allow regulators to set the initial operating mode

This is useful when wishing to run in a fixed operating mode that isn't
the default.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
fe203ddfa5451a13589b1c7da9edab80b7fc06d1 11-Feb-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Suggest use of datasheet supply or pin names for consumers

Update the documentation to suggest the use of datasheet names for
the supplies requested by regulator consumers. Doing this makes it
easier to tie the design for a given platform up with the requirements
of the driver for a consumer.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
0f1d747bfa89de4ca52dc1dffdcce35a2b8a1532 22-Jan-2009 Mike Rapoport <mike@compulab.co.il> regulator: add unset_regulator_supplies to fix regulator_unregister

Currently regulator_unregister does not clear regulator <--> consumer
mapping.
This patch introduces unset_regulator_supplies that clear the map.

Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
1fa9ad52b07811ebf258f3f6907de8dbf020ec2d 21-Jan-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Hoist struct regulator_dev out of core to fix notifiers

Commit 872ed3fe176833f7d43748eb88010da4bbd2f983 caused regulator drivers
to take the struct regulator_dev lock themselves which requires that the
struct be visible to them. Band aid this by making the struct visible.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
0527100fd11d9710c7e153d791da78824b7b46fa 19-Jan-2009 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Pass regulator init data as explict argument when registering

Rather than having the regulator init data read from the platform_data
member of the struct device that is registered for the regulator make
the init data an explict argument passed in when registering. This
allows drivers to use the platform data for their own purposes if they
wish.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
b136fb4463d13eea129bf090a8a465bba6bf0003 19-Jan-2009 Jonathan Cameron <jic23@cam.ac.uk> Regulator: Push lock out of _notifier_call_chain + add voltage change event.

Regulator: Push lock out of _notifier_call_chain and into caller functions
(side effect of fixing deadlock in regulator_force_disable)
+ Add a voltage changed event.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
853116a10544206b6b2cf42ebc9d78fba2668888 15-Jan-2009 David Brownell <dbrownell@users.sourceforge.net> regulator: add get_status()

Based on previous LKML discussions:

* Update docs for regulator sysfs class attributes to highlight
the fact that all current attributes are intended to be control
inputs, including notably "state" and "opmode" which previously
implied otherwise.

* Define a new regulator driver get_status() method, which is the
first method reporting regulator outputs instead of inputs.
It can report on/off and error status; or instead of simply
"on", report the actual operating mode.

For the moment, this is a sysfs-only interface, not accessible to
regulator clients. Such clients can use the current notification
interfaces to detect errors, if the regulator reports them.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
6001e13c5f708eb68c744a69df3c2c281156030d 31-Dec-2008 David Brownell <dbrownell@users.sourceforge.net> regulator: catch some registration errors

Prevent registration of duplicate "struct regulator" names.
They'd be unavailable, and clearly indicate something wrong.

[Edited to remove check for NULL consumer device until we have a
solution for things like cpufreq -- broonie]

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
cf7bbcdf4d267eff580cb7ce6cf4fe16a940a005 31-Dec-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Fix some kerneldoc rendering issues

There are some minor textual changes in here as well, mostly to enable()
and disable() but the primary goal of these changes is to fix
misrenderings of the kerneldoc documentation for the regulator API.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
c8e7e4640facbe99d10a6e262523b25be129b9b9 31-Dec-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Add missing kerneldoc

This is only the documentation that the kerneldoc system warns about.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
69279fb9a95051971ac03e558c4d46e7ba84ab3a 31-Dec-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Clean up kerneldoc warnings

Remove kerneldoc warnings that don't relate to missing documentation,
mostly by renaming parameters in the documentation to match their
actual names.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
8dc5390d4f3fd8acc73773a56fea13544e7924dc 31-Dec-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Remove extraneous kerneldoc annotations

Some of the internal structures have no kerneldoc but the ** at the start
of the comment marking them for documentation. Remove the annotation
until some is added.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
74f544c1fc0339acf6f66ff438b8543b1f9faf10 25-Nov-2008 Mike Rapoport <mike@compulab.co.il> regulator: move set_machine_constraints after regulator device initialization

Calling set_machine_constraints before regulator device initialization
causes crash when constraints have apply_uV set.

Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
7ad68e2f970fd84d15ad67ce3216aed05f944a9c 12-Nov-2008 David Brownell <dbrownell@users.sourceforge.net> regulator: sysfs attribute reduction (v2)

Clean up the sysfs interface to regulators by only exposing the
attributes that can be properly displayed. For example: when a
particular regulator method is needed to display the value, only
create that attribute when that method exists.

This cleaned-up interface is much more comprehensible. Most
regulators only support a subset of the possible methods, so
often more than half the attributes would be meaningless. Many
"not defined" values are no longer necessary. (But handling
of out-of-range values still looks a bit iffy.)

Documentation is updated to reflect that few of the attributes
are *always* present, and to briefly explain why a regulator may
not have a given attribute.

This adds object code, about a dozen bytes more than was removed
by the preceding patch, but saves a bunch of per-regulator data
associated with the now-removed attributes. So there's a net
reduction in memory footprint.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
4fca9545d17b99cdb2774716b034c62a70151bcd 12-Nov-2008 David Brownell <dbrownell@users.sourceforge.net> regulator: code shrink (v2)

Shrink regulator core by removing duplication in attribute printing
and probe() cleanup paths. Saves about 340 bytes (object) on ARM.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e573520b171095c106ffbbbf4f9cbed6d9bff576 16-Nov-2008 David Brownell <dbrownell@users.sourceforge.net> regulator: improved mode error checks

Minor bugfixes in handling of regulator modes:

- have the routine verifying regulator modes check against
the set of legal modes (!);

- have regulator_set_optimum_mode() verify the return value
of regulator_ops.get_optimum_mode(), like drms_uA_update();

- one call to regulator_ops.set_mode() treated zero as a
failure code; make this consistent with other callers.

Both regulator_set_mode() and regulator_set_optimum_mode() now
require valid_ops_mask to include REGULATOR_CHANGE_MODE; that
seems like a bugfix too.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
412aec610559bdb602a0a21ce149ba8ffbb6f983 16-Nov-2008 David Brownell <dbrownell@users.sourceforge.net> regulator: enable/disable refcounting

Make the <linux/regulator.h> framework treat enable/disable call
pairs like the <linux/clk.h> and <linux/interrupt.h> frameworks do:
they're refcounted, so that different parts of a driver don't need
to put work into coordination that frameworks normally handle.
It's a minor object code shrink.

It also makes the regulator_is_disabled() kerneldoc say what it's
actually returning: return value is not a refcount, and may report
an error (e.g. I/O error from I2C).

It also fixes some minor regulator_put() goofage: removing unlocked
access to the enable state. (But still not making regulator put/get
match the refcounting pattern they invoke.)

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
812460a927c1d0dc1fbdbec9aa07de1b04043d83 02-Nov-2008 Kay Sievers <kay.sievers@vrfy.org> regulator: struct device - replace bus_id with dev_name(), dev_set_name()

This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".

To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.

We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.

We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.

Thanks,
Kay

From: Kay Sievers <kay.sievers@vrfy.org>
Subject: regulator: struct device - replace bus_id with dev_name(), dev_set_name()

Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>

Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
bc558a60b58f638ee0188affb627d4894a97b1c7 10-Oct-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Export regulator name via sysfs

Provide a new file 'name' in the regulator sysfs class with a human
readable name for the regulator for use in applications.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e5fda26c7ea9430d7d953364f900bafdce2be67b 09-Sep-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Enable regulators marked as always_on

If the machine constraints mark a regulator as always_on but this was
not done by the bootloader then enable the regulator when applying
constraints.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
e06f5b4fea243b152c79fe5d9552a852069de483 09-Sep-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: Additional diagnostics for machine constraints

Try to find a human readable name for the regulator we're failing on and
print a specific diagnostic when we fail to set the suspend state.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
46fabe1edd44a8893d88d7982f88d01ccf77f0bb 09-Sep-2008 Mark Brown <broonie@opensource.wolfsonmicro.com> regulator: check for init_data on registration

Since it is now mandatory to supply constraints via init_data on device
registration check for that when registering, saving us from oopsing
later on.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
a5766f11cfd3a0c03450d99c8fe548c2940be884 10-Oct-2008 Liam Girdwood <lrg@slimlogic.co.uk> regulator: core - Rework machine API to remove string based functions.

This improves the machine level API in order to configure
regulator constraints and consumers as platform data and removes the
old string based API that required several calls to set up each regulator.

The intention is to create a struct regulator_init_data, populate
it's fields with constraints, consumers devices, etc and then register
the regulator device from board.c in the standard Linux way.

e.g. regulator LDO2 (supplying codec and sim) platform data.

/* regulator LDO2 consumer devices */
static struct regulator_consumer_supply ldo2_consumers[] = {
{
.dev = &platform_audio_device.dev,
.supply = "codec_avdd",
},
{
.dev = &platform_sim_device.dev,
.supply = "sim_vcc",
}
};

/* regulator LDO2 constraints */
static struct regulator_init_data ldo2_data = {
.constraints = {
.min_uV = 3300000,
.max_uV = 3300000,
.valid_modes_mask = REGULATOR_MODE_NORMAL,
.apply_uV = 1,
},
.num_consumer_supplies = ARRAY_SIZE(ldo2_consumers),
.consumer_supplies = ldo2_consumers,
};

/* machine regulator devices with thier consumers and constraints */
static struct platform_device wm8350_regulator_devices[] = {
{
.name = "wm8350-regulator",
.id = WM8350_LDO_2,
.dev = {
.platform_data = &ldo2_data,
},
},
};

Changes in detail:-

o Removed all const char* regulator config functions in machine API.
o Created new struct regulator_init_data to contain regulator
machine configuration constraints and consmuers.
o Changed set_supply(), set_machine_constraints(),
set_consumer_device_supply() to remove their string identifier
parameters. Also made them static and moved functions nearer top of
core.c.
o Removed no longer used inline func to_rdev()
o Added regulator_get_init_drvdata() to retrieve init data.
o Added struct device* as parameter to regulator_register().
o Changed my email address.

Signed-off-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
414c70cb91c445ec813b61e16fe4882807e40240 30-Apr-2008 Liam Girdwood <lg@opensource.wolfsonmicro.com> regulator: regulator framework core

This adds the regulator framework core.

This framework is designed to provide a generic interface to voltage
and current regulators within the Linux kernel. It's intended to
provide voltage and current control to client or consumer drivers and
also provide status information to user space applications through a
sysfs interface.

The intention is to allow systems to dynamically control regulator
output in order to save power and prolong battery life. This applies
to both voltage regulators (where voltage output is controllable) and
current sinks (where current output is controllable).

This framework safely compiles out if not selected so that client
drivers can still be used in systems with no software controllable
regulators.

Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>