summaryrefslogtreecommitdiff
path: root/drivers/regulator/core.c
AgeCommit message (Collapse)Author
2010-08-05regulator: Remove owner field from attribute initialization in regulator ↵Guenter Roeck
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>
2010-05-25regulator: return set_mode is same mode is requestedSundar R Iyer
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>
2010-05-25regulator: simplify regulator_register() error handlingJani Nikula
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>
2010-05-25regulator: fix unset_regulator_supplies() to remove all matchesJani Nikula
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>
2010-05-25regulator: prevent registration of matching regulator consumer suppliesJani Nikula
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>
2010-05-25regulator: Allow regulator-regulator supplies to be specified by nameMark Brown
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>
2010-04-23Merge branch 'master' into for-nextJiri Kosina
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
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>
2010-03-22regulator: Get rid of lockdep warningAmeya Palande
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>
2010-03-16Fix typos in commentsThomas Weber
[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>
2010-03-03regulator: Provide optional dummy regulator for consumersMark Brown
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>
2010-03-03regulator: Assume regulators are enabled if they don't report anythingMark Brown
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>
2010-03-03regulator: Allow regulators to specify the time taken to ramp on enableMark Brown
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>
2010-03-03regulator: Add notifier event on regulator disableMark Brown
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>
2010-02-12regulator: Fix display of null constraints for regulatorsMark Brown
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>
2009-12-17regulator: Fix unbalanced disables/enables in ↵Lars-Peter Clausen
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>
2009-12-17regulator: core.c: Small coding style cleanup (indentation fixup)Stefan Roese
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>
2009-12-17regulator: Handle regulators without suspend mode configurationMark Brown
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>
2009-12-17regulator: Factor out regulator name pretty printingMark Brown
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>
2009-12-17regulator: Display actual settings with constraintsMark Brown
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>
2009-12-17regulator: Also lift apply_uV into machine_constraints_voltage()Mark Brown
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>
2009-12-17regulator: Factor out voltage constraint setupMark Brown
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>
2009-12-17regulator: Report error codes for bulk operationsMark Brown
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>
2009-11-16regulator: Handle missing constraints in _regulator_disable()Mark Brown
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2009-09-22REGULATOR Handle positive returncode from enableLinus Walleij
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>
2009-09-22regulator: regulator_enable() permission checkingMark Brown
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>
2009-09-22regulator: Push locking for regulator_is_enabled() outMark Brown
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>
2009-09-22regulator: Check for constraints in regulator_init_complete()Mark Brown
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2009-09-22regulator: Check for constraints before using them for nameMark Brown
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2009-09-22regulator: Fix support for deviceless supply mappingsMark Brown
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>
2009-09-22regulator: Warn when unregistering an in-use regulatorMark Brown
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>
2009-09-22regulator: Add regulator voltage range check APIMark Brown
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>
2009-09-22regulator: Add regulator_get_exclusive() APIMark Brown
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>
2009-09-22regulator: Allow consumer supplies to be set up with dev_name()Mark Brown
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>
2009-09-17regulator: Provide mode to status conversion functionMark Brown
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>
2009-04-28regulator: Fix default constraints for fixed voltage regulatorsMark Brown
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>
2009-04-28regulator core: fix double-free in regulator_register() error pathPaul Walmsley
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>
2009-04-28drivers/regulator: fix when type is different from REGULATOR_VOLTAGE or ↵Diego Liziero
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>
2009-04-28unreachable code in drms_uA_update()Dan Carpenter
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>
2009-03-31regulator: Support disabling of unused regulators by machinesMark Brown
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>
2009-03-31regulator: Don't increment use_count for boot_on regulatorsMark Brown
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>
2009-03-31regulator: refcount fixesDavid Brownell
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>
2009-03-31regulator: Don't warn if we failed to get a regulatorMark Brown
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>
2009-03-31regulator: Allow boot_on regulators to be disabled by clientsMark Brown
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>
2009-03-31regulator: Don't warn on omitted voltage constraintsMark Brown
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>
2009-03-31regulator: enumerate voltages (v2)David Brownell
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>
2009-03-31regulator: Allow regulators to set the initial operating modeMark Brown
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>
2009-03-31regulator: Suggest use of datasheet supply or pin names for consumersMark Brown
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>
2009-03-31regulator: add unset_regulator_supplies to fix regulator_unregisterMike Rapoport
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>
2009-03-31regulator: Hoist struct regulator_dev out of core to fix notifiersMark Brown
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>