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>
This seems to be fallout from last October's regulator core rework.
It got noticed only because of recent regulator framework changes.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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>
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>
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>
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>
Add VPLL2 to the set of twl4030-family regulators exposed for
use by various drivers. It's commonly used to power the digital
video outputs (e.g. LCD or DVI displays) on OMAP3 systems.
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>
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>
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>
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>
Implement the recently added voltage step listing API for the WM835x
DCDCs and LDOs. DCDCs can use values up to 0x66, LDOs can use the full
range of values in the mask. Both masks are the lower bits of the
register.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The VAUX4 voltage table scrolls onto a second page in many versions
of the TWL4030 family manuals. This doesn't mean we should ignore
those values! Some boards use the (fully supported) 2.8V setting.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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>
Support most of the LDO regulators in the twl4030 family chips.
In the case of LDOs supporting MMC/SD, the voltage controls are
used; but in most other cases, the regulator framework is only
used to enable/disable a supplies, conserving power when a given
voltage rail is not needed.
The drivers/mfd/twl4030-core.c code already sets up the various
regulators according to board-specific configuration, and knows
that some chips don't provide the full set of voltage rails.
The omitted regulators are intended to be under hardware control,
such as during the hardware-mediated system powerup, powerdown,
and suspend states. Unless/until software hooks are known to
be safe, they won't be exported here.
These regulators implement the new get_status() operation, but
can't realistically implement get_mode(); the status output is
effectively the result of a vote, with the relevant hardware
inputs not exposed.
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>
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>
The WM835x regulators need a different register checking for force
mode on each DCDC. Previously the force mode status for DCDC1 was
checked.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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>
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>
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>
