summaryrefslogtreecommitdiff
path: root/drivers/regulator/core.c
AgeCommit message (Collapse)Author
2012-08-03regulator: core: support of supply name through descLaxman Dewangan
Add support of providing the supply name through regualtor descriptor. This help to fill the supply name in device based on datasheet. This patch help to develop driver which is align with mainline. This change is small set of change in mainline --------------- commit 69511a452e6dc6b74fe4f3671a51b1b44b9c57e3 Author: Rajendra Nayak <rnayak@ti.com> regulator: map consumer regulator based on device tree --------------- Change-Id: Ia3112f29efe4f0e0c9e98f2b7943255b2eae4c49 Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-on: http://git-master/r/120883
2012-05-01regulator: add sysfs for rail enable/disableLaxman Dewangan
Added support for enable/disable rails from user space. bug 966960 Change-Id: Iae660699c60f537296f90508a78bd40959c46535 Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-on: http://git-master/r/99186 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Hunk Lin <hulin@nvidia.com> Tested-by: Hunk Lin <hulin@nvidia.com> GVS: Gerrit_Virtual_Submit
2012-01-20regulator: Fix possible nullpointer dereference in regulator_enable()Heiko Stübner
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> Cherry-pick from main stream: commit d1685e4e2c3854782272f32b71f2f3eff5c6e0d0 Change-Id: Ie4d8db9184a65e6a98964259299bfc7daa0f4048 Reviewed-on: http://git-master/r/75908 Reviewed-by: Pavan Kunapuli <pkunapuli@nvidia.com> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Reviewed-on: http://git-master/r/76462 Reviewed-by: Automatic_Commit_Validation_User
2012-01-06regulator: Enable supply regulator if child rail is enabled.Laxman Dewangan
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> Cherry-picked from linus' mainline: b2296bd43e781976743354c668a356b0df98e1da Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Change-Id: Ibfdcc8e8dc04a109905883239a7f358a1ef9d54d Reviewed-on: http://git-master/r/73176 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> Tested-by: Laxman Dewangan <ldewangan@nvidia.com>
2011-11-30regulator: Expand regulator notifier eventsAlex Frid
Add regulator enable notifications (not sent by the current code). Add voltage notifications sent only if regulator output is actually changed (keep intact existing voltage change notification that is sent unconditionally - even if voltage change was not allowed by constraints, or no actual change since regulator is disabled): PRE_ENABLE Regulator is to be enabled POST_ENABLE Regulator was enabled OUT_PRECHANGE Regulator is enabled and its voltage is to be changed OUT_POSTCHANGE Regulator is enabled and its voltage was changed Bug 853132 Original-Change-Id: I2759ada1c5d1e43f746f6c866f9b3c203b68aed6 Reviewed-on: http://git-master/r/42262 Tested-by: Aleksandr Frid <afrid@nvidia.com> Reviewed-by: Scott Williams <scwilliams@nvidia.com> Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Karan Jhavar <kjhavar@nvidia.com> Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com> Rebase-Id: Rdac9b19d1f999e889aae8e2eb72f9b60057dd05a
2011-11-30regulator: write permission for only userSachin Nikam
Write permission only for User for syncevent_regulators sysfs attribute. This is needed so as to pass FileSystemPermission CTS. Bug 840409 Original-Change-Id: Iad1ac9fc63b9471b2f7c9f2c12524512b3f5941e Signed-off-by: Sachin Nikam <snikam@nvidia.com> Reviewed-on: http://git-master/r/36897 Reviewed-by: Niket Sirsi <nsirsi@nvidia.com> Tested-by: Niket Sirsi <nsirsi@nvidia.com> Rebase-Id: Rb71c94a12e155ae630d09f30fb42df4d83cc6e7c
2011-11-30regulator: generate status events for all regulatorsPeter De Schrijver
Original-Change-Id: I6aba475047e0f1e1186bff88dfe9aedaf6a8b415 Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Reviewed-on: http://git-master/r/31532 Reviewed-by: Niket Sirsi <nsirsi@nvidia.com> Tested-by: Niket Sirsi <nsirsi@nvidia.com> Rebase-Id: R7f6a01f24db741f441c692bb95ccc2017b25344d
2011-07-22regulator: Fix argument format type errors in error printsMark Brown
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>
2011-07-22regulator: Fix memory leak in set_machine_constraints() error pathsAxel Lin
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>
2011-07-22regulator: Make core more chatty about some errorsMark Brown
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>
2011-07-04regulator: Add basic per consumer debugfsMark Brown
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>
2011-06-09regulator: Add rdev_crit() macroMark Brown
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>
2011-06-09regulator: Refactor supply implementation to work as regular consumersMark Brown
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>
2011-06-09regulator: Include the device name in the microamps_requested_ fileMark Brown
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>
2011-06-09regulator: Increase the limit on sysfs file namesMark Brown
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>
2011-05-30regulator: Do bulk enables of regulators in parallelMark Brown
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>
2011-05-27regulator: Fix _regulator_get_voltage if get_voltage callback is NULLAxel Lin
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>
2011-05-27regulator: Only apply voltage constraints from consumers that set themMark Brown
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>
2011-05-27regulator: If we can't configure optimum mode we're always in the best oneMark Brown
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>
2011-05-27regulator: Support voltage offsets to compensate for drops in systemMark Brown
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>
2011-05-27regulator: Remove supply_regulator_dev from machine configurationMark Brown
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>
2011-05-27regulator: Factor out references to rdev in regulator_force_disable()Mark Brown
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>
2011-05-27regulator: Fix the argument of calling regulator_mode_constrainAxel Lin
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)>
2011-05-27regulator: When constraining modes fall back to higher power modesMark Brown
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>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-26regulator: provide consumer interface for fall/rise timeLinus Walleij
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>
2011-03-26regulator: add set_voltage_time_sel infrastructureLinus Walleij
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>
2011-03-26Regulator: add suspend-finish API for regulator core.MyungJoo Ham
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>
2011-03-26regulator: If we fail when setting up a supply say which supplyMark Brown
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>
2011-01-12regulator: Add initial per-regulator debugfs supportMark Brown
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>
2011-01-12regulator: Make regulator_has_full_constraints a boolMark Brown
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>
2011-01-12regulator: Clean up logging a bitMark Brown
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>
2011-01-12regulator: Optimise out noop voltage changesMark Brown
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>
2011-01-12regulator: Add API to re-apply voltage to hardwareMark Brown
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>
2011-01-12regulator: Only notify voltage changes when they succeedMark Brown
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>
2011-01-12regulator: Provide a selector based set_voltage_sel() operationMark Brown
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>
2011-01-12regulator: Factor out voltage set operation into a separate functionMark Brown
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>
2011-01-12regulator: Allow drivers to report voltages as selectorsMark Brown
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>
2011-01-12regulator: Use _regulator_get_voltage() consistentlyMark Brown
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>
2011-01-12drivers/regulator: Update WARN usesJoe Perches
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>
2011-01-12regulator: Take into account the requirements of all consumersThomas Petazzoni
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>
2011-01-12regulator: Add and use rdev_<level> macrosJoe Perches
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>
2011-01-12regulator: Copy constraints from regulators when initialising themMark Brown
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>
2011-01-12regulator: Remove regulator core version announcementMark Brown
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>
2011-01-12regulator: Fix obfuscated log messagesMark Brown
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>
2011-01-12drivers: regulator: core: convert to using pr_ macrosDaniel Walker
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>
2011-01-12drivers: regulator: core: use pr_fmtDaniel Walker
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>
2011-01-12regulator: enable supply regulator only when use count is zeroBengt Jonsson
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>
2011-01-12regulator: Add basic trace facilitiesMark Brown
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>
2011-01-12regulator: Report actual configured voltage to set_voltage()Mark Brown
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>