UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/include/linux/regulator/consumer.h

634 lines
18 KiB
C
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04 16:11:33 +08:00
/* SPDX-License-Identifier: GPL-2.0-only */
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
/*
* consumer.h -- SoC Regulator consumer support.
*
* Copyright (C) 2007, 2008 Wolfson Microelectronics PLC.
*
regulator: email - update email address and regulator webpage. Remove deceased email address and update to new address. Also update website details in MAINTAINERS with correct page. Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2009-02-03 05:43:31 +08:00
* Author: Liam Girdwood <lrg@slimlogic.co.uk>
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
*
* Regulator Consumer Interface.
*
* A Power Management Regulator framework for SoC based devices.
* Features:-
* o Voltage and current level control.
* o Operating mode control.
* o Regulator status.
* o sysfs entries for showing client devices and status
*
* EXPERIMENTAL FEATURES:
* Dynamic Regulator operating Mode Switching (DRMS) - allows regulators
* to use most efficient operating mode depending upon voltage and load and
* is transparent to client drivers.
*
* e.g. Devices x,y,z share regulator r. Device x and y draw 20mA each during
* IO and 1mA at idle. Device z draws 100mA when under load and 5mA when
* idling. Regulator r has > 90% efficiency in NORMAL mode at loads > 100mA
* but this drops rapidly to 60% when below 100mA. Regulator r has > 90%
* efficiency in IDLE mode at loads < 10mA. Thus regulator r will operate
* in normal mode for loads > 10mA and in IDLE mode for load <= 10mA.
*/
#ifndef __LINUX_REGULATOR_CONSUMER_H_
#define __LINUX_REGULATOR_CONSUMER_H_
regulator: Include err.h from consumer.h to fix build failure sh:sh2007_defconfig fails to build with the following error: In file included from include/linux/regulator/machine.h:18:0, from arch/sh/boards/board-sh2007.c:10: include/linux/regulator/consumer.h: In function 'regulator_get_optional': include/linux/regulator/consumer.h:271:2: error: implicit declaration of function 'ERR_PTR' include/linux/err.h: At top level: include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR' include/linux/regulator/consumer.h:271:9: note: previous implicit declaration of 'ERR_PTR' was here Since consumer.h uses ERR_PTR, it should include err.h. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-10-10 03:43:27 +08:00
#include <linux/err.h>
device.h: audit and cleanup users in main include dir The <linux/device.h> header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-01-31 00:46:54 +08:00
struct device;
struct notifier_block;
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>
2014-07-21 23:38:48 +08:00
struct regmap;
regulator: consumer.h - fix build when consumer.h is #included first. consumer.h requires device.h for stand alone build. Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2009-11-11 22:16:10 +08:00
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
/*
* Regulator operating modes.
*
* Regulators can run in a variety of different operating modes depending on
* output load. This allows further system power savings by selecting the
* best (and most efficient) regulator mode for a desired load.
*
* Most drivers will only care about NORMAL. The modes below are generic and
* will probably not match the naming convention of your regulator data sheet
* but should match the use cases in the datasheet.
*
* In order of power efficiency (least efficient at top).
*
* Mode Description
* FAST Regulator can handle fast changes in it's load.
* e.g. useful in CPU voltage & frequency scaling where
* load can quickly increase with CPU frequency increases.
*
* NORMAL Normal regulator power supply mode. Most drivers will
* use this mode.
*
* IDLE Regulator runs in a more efficient mode for light
* loads. Can be used for devices that have a low power
* requirement during periods of inactivity. This mode
* may be more noisy than NORMAL and may not be able
* to handle fast load switching.
*
* STANDBY Regulator runs in the most efficient mode for very
* light loads. Can be used by devices when they are
* in a sleep/standby state. This mode is likely to be
* the most noisy and may not be able to handle fast load
* switching.
*
* NOTE: Most regulators will only support a subset of these modes. Some
* will only just support NORMAL.
*
* These modes can be OR'ed together to make up a mask of valid register modes.
*/
regulator: Don't return or expect -errno from of_map_mode() In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be unsigned int) because they needed to signal an error back to of_get_regulation_constraints(). In general in the regulator framework the mode is always referred to as an unsigned int. While we could fix this to be a signed int (the highest value we store in there right now is 0x8), it's actually pretty clean to just define the regulator mode 0x0 (the lack of any bits set) as an invalid mode. Let's do that. Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and suspend modes") Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-18 23:54:18 +08:00
#define REGULATOR_MODE_INVALID 0x0
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
#define REGULATOR_MODE_FAST 0x1
#define REGULATOR_MODE_NORMAL 0x2
#define REGULATOR_MODE_IDLE 0x4
#define REGULATOR_MODE_STANDBY 0x8
/*
* Regulator notifier events.
*
* UNDER_VOLTAGE Regulator output is under voltage.
* OVER_CURRENT Regulator output current is too high.
* REGULATION_OUT Regulator output is out of regulation.
* FAIL Regulator output has failed.
* OVER_TEMP Regulator over temp.
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>
2009-12-02 05:12:27 +08:00
* FORCE_DISABLE Regulator forcibly shut down by software.
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>
2009-01-20 02:20:58 +08:00
* VOLTAGE_CHANGE Regulator voltage changed.
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>
2014-08-29 03:36:04 +08:00
* Data passed is old voltage cast to (void *).
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>
2009-12-02 05:12:27 +08:00
* DISABLE Regulator was disabled.
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>
2014-08-29 03:36:04 +08:00
* PRE_VOLTAGE_CHANGE Regulator is about to have voltage changed.
* Data passed is "struct pre_voltage_change_data"
* ABORT_VOLTAGE_CHANGE Regulator voltage change failed for some reason.
* Data passed is old voltage cast to (void *).
regulator: core: Add PRE_DISABLE notification Add a PRE_DISABLE notification so that consumers can use a notifier to run any steps required to prepare for the regulator being switched off. Since the regulator disable can fail an abort notification is also added. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-11-24 22:10:52 +08:00
* PRE_DISABLE Regulator is about to be disabled
* ABORT_DISABLE Regulator disable failed for some reason
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
*
* NOTE: These events can be OR'ed together when passed into handler.
*/
#define REGULATOR_EVENT_UNDER_VOLTAGE 0x01
#define REGULATOR_EVENT_OVER_CURRENT 0x02
#define REGULATOR_EVENT_REGULATION_OUT 0x04
#define REGULATOR_EVENT_FAIL 0x08
#define REGULATOR_EVENT_OVER_TEMP 0x10
#define REGULATOR_EVENT_FORCE_DISABLE 0x20
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>
2009-01-20 02:20:58 +08:00
#define REGULATOR_EVENT_VOLTAGE_CHANGE 0x40
regulator: core: Fix space before TAB Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-24 00:10:03 +08:00
#define REGULATOR_EVENT_DISABLE 0x80
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>
2014-08-29 03:36:04 +08:00
#define REGULATOR_EVENT_PRE_VOLTAGE_CHANGE 0x100
#define REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE 0x200
regulator: core: Add PRE_DISABLE notification Add a PRE_DISABLE notification so that consumers can use a notifier to run any steps required to prepare for the regulator being switched off. Since the regulator disable can fail an abort notification is also added. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-11-24 22:10:52 +08:00
#define REGULATOR_EVENT_PRE_DISABLE 0x400
#define REGULATOR_EVENT_ABORT_DISABLE 0x800
regulator: core: Add new notification for enabling of regulator This is useful for devices, which need some time to start up, to help the drivers track how long the supply has been up already. Ie whether it can safely talk to the HW or needs to wait. Signed-off-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-02-24 01:06:52 +08:00
#define REGULATOR_EVENT_ENABLE 0x1000
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>
2014-08-29 03:36:04 +08:00
regulator: core: Add new API to poll for error conditions Regulator consumers can receive event notifications when errors are reported to the driver, but currently, there is no way for a regulator consumer to know when the error is over. To allow a regulator consumer to poll for error conditions add a new API: regulator_get_error_flags. Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-11-03 19:11:42 +08:00
/*
* Regulator errors that can be queried using regulator_get_error_flags
*
* UNDER_VOLTAGE Regulator output is under voltage.
* OVER_CURRENT Regulator output current is too high.
* REGULATION_OUT Regulator output is out of regulation.
* FAIL Regulator output has failed.
* OVER_TEMP Regulator over temp.
*
* NOTE: These errors can be OR'ed together.
*/
#define REGULATOR_ERROR_UNDER_VOLTAGE BIT(1)
#define REGULATOR_ERROR_OVER_CURRENT BIT(2)
#define REGULATOR_ERROR_REGULATION_OUT BIT(3)
#define REGULATOR_ERROR_FAIL BIT(4)
#define REGULATOR_ERROR_OVER_TEMP BIT(5)
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>
2014-08-29 03:36:04 +08:00
/**
* struct pre_voltage_change_data - Data sent with PRE_VOLTAGE_CHANGE event
*
* @old_uV: Current voltage before change.
* @min_uV: Min voltage we'll change to.
* @max_uV: Max voltage we'll change to.
*/
struct pre_voltage_change_data {
unsigned long old_uV;
unsigned long min_uV;
unsigned long max_uV;
};
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
struct regulator;
/**
* struct regulator_bulk_data - Data used for bulk regulator operations.
*
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>
2008-12-31 20:52:41 +08:00
* @supply: The name of the supply. Initialised by the user before
* using the bulk regulator APIs.
* @consumer: The regulator consumer for the supply. This will be managed
* by the bulk API.
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
*
* The regulator APIs provide a series of regulator_bulk_() API calls as
* a convenience to consumers which require multiple supplies. This
* structure is used to manage data for these calls.
*/
struct regulator_bulk_data {
const char *supply;
struct regulator *consumer;
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>
2011-05-24 08:12:40 +08:00
regulator: fix kernel-doc warning in consumer.h Fix kernel-doc warning about internal/private data by marking it as "private:" so that kernel-doc will ignore it. Warning(include/linux/regulator/consumer.h:128): No description found for parameter 'ret' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-09 01:16:47 +08:00
/* private: Internal use */
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>
2011-05-24 08:12:40 +08:00
int ret;
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
};
#if defined(CONFIG_REGULATOR)
/* regulator get and put */
struct regulator *__must_check regulator_get(struct device *dev,
const char *id);
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>
2012-01-17 11:39:58 +08:00
struct regulator *__must_check devm_regulator_get(struct device *dev,
const char *id);
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>
2009-07-21 23:00:23 +08:00
struct regulator *__must_check regulator_get_exclusive(struct device *dev,
const char *id);
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>
2013-08-25 23:54:13 +08:00
struct regulator *__must_check devm_regulator_get_exclusive(struct device *dev,
const char *id);
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>
2013-07-30 04:42:42 +08:00
struct regulator *__must_check regulator_get_optional(struct device *dev,
const char *id);
struct regulator *__must_check devm_regulator_get_optional(struct device *dev,
const char *id);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
void regulator_put(struct regulator *regulator);
regulator: Add devm_regulator_put in consumer.h Commit d5ad34f7cb "regulator: Implement devm_regulator_free()" actually implements devm_regulator_put. Thus rename devm_regulator_free to devm_regulator_put. Also add empty devm_regulator_put for !CONFIG_REGULATOR Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-29 17:52:37 +08:00
void devm_regulator_put(struct regulator *regulator);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
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>
2013-10-16 03:14:20 +08:00
int regulator_register_supply_alias(struct device *dev, const char *id,
struct device *alias_dev,
const char *alias_id);
void regulator_unregister_supply_alias(struct device *dev, const char *id);
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>
2014-05-23 23:44:10 +08:00
int regulator_bulk_register_supply_alias(struct device *dev,
const char *const *id,
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>
2013-10-16 03:14:20 +08:00
struct device *alias_dev,
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>
2014-05-23 23:44:10 +08:00
const char *const *alias_id,
int num_id);
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>
2013-10-16 03:14:20 +08:00
void regulator_bulk_unregister_supply_alias(struct device *dev,
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>
2014-05-23 23:44:10 +08:00
const char * const *id, int num_id);
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>
2013-10-16 03:14:20 +08:00
int devm_regulator_register_supply_alias(struct device *dev, const char *id,
struct device *alias_dev,
const char *alias_id);
void devm_regulator_unregister_supply_alias(struct device *dev,
const char *id);
int devm_regulator_bulk_register_supply_alias(struct device *dev,
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>
2014-05-23 23:44:10 +08:00
const char *const *id,
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>
2013-10-16 03:14:20 +08:00
struct device *alias_dev,
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>
2014-05-23 23:44:10 +08:00
const char *const *alias_id,
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>
2013-10-16 03:14:20 +08:00
int num_id);
void devm_regulator_bulk_unregister_supply_alias(struct device *dev,
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>
2014-05-23 23:44:10 +08:00
const char *const *id,
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>
2013-10-16 03:14:20 +08:00
int num_id);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
/* regulator output control and status */
regulator: core: Mark all get and enable calls as __must_check It's generally important that devices have power when they expect it so drivers really ought to be checking for errors on the power up paths. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-20 00:35:48 +08:00
int __must_check regulator_enable(struct regulator *regulator);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
int regulator_disable(struct regulator *regulator);
int regulator_force_disable(struct regulator *regulator);
int regulator_is_enabled(struct regulator *regulator);
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>
2011-09-11 16:53:50 +08:00
int regulator_disable_deferred(struct regulator *regulator, int ms);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
regulator: core: Mark all get and enable calls as __must_check It's generally important that devices have power when they expect it so drivers really ought to be checking for errors on the power up paths. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-03-20 00:35:48 +08:00
int __must_check regulator_bulk_get(struct device *dev, int num_consumers,
struct regulator_bulk_data *consumers);
int __must_check devm_regulator_bulk_get(struct device *dev, int num_consumers,
struct regulator_bulk_data *consumers);
int __must_check regulator_bulk_enable(int num_consumers,
struct regulator_bulk_data *consumers);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
int regulator_bulk_disable(int num_consumers,
struct regulator_bulk_data *consumers);
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>
2012-01-03 15:22:03 +08:00
int regulator_bulk_force_disable(int num_consumers,
struct regulator_bulk_data *consumers);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
void regulator_bulk_free(int num_consumers,
struct regulator_bulk_data *consumers);
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>
2009-02-27 03:48:36 +08:00
int regulator_count_voltages(struct regulator *regulator);
int regulator_list_voltage(struct regulator *regulator, unsigned selector);
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>
2009-07-21 23:00:24 +08:00
int regulator_is_supported_voltage(struct regulator *regulator,
int min_uV, int max_uV);
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>
2013-06-07 16:06:56 +08:00
unsigned int regulator_get_linear_step(struct regulator *regulator);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV);
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>
2011-03-17 20:24:52 +08:00
int regulator_set_voltage_time(struct regulator *regulator,
int old_uV, int new_uV);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
int regulator_get_voltage(struct regulator *regulator);
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>
2010-12-16 23:49:36 +08:00
int regulator_sync_voltage(struct regulator *regulator);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
int regulator_set_current_limit(struct regulator *regulator,
int min_uA, int max_uA);
int regulator_get_current_limit(struct regulator *regulator);
int regulator_set_mode(struct regulator *regulator, unsigned int mode);
unsigned int regulator_get_mode(struct regulator *regulator);
regulator: core: Add new API to poll for error conditions Regulator consumers can receive event notifications when errors are reported to the driver, but currently, there is no way for a regulator consumer to know when the error is over. To allow a regulator consumer to poll for error conditions add a new API: regulator_get_error_flags. Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-11-03 19:11:42 +08:00
int regulator_get_error_flags(struct regulator *regulator,
unsigned int *flags);
regulator: Rename regulator_set_optimum_mode Rename the regulator_set_optimum_mode() function regulator_set_load() to better represent what's going on. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-12 11:35:27 +08:00
int regulator_set_load(struct regulator *regulator, int load_uA);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
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>
2012-09-01 01:36:37 +08:00
int regulator_allow_bypass(struct regulator *regulator, bool allow);
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>
2014-07-21 23:38:48 +08:00
struct regmap *regulator_get_regmap(struct regulator *regulator);
int regulator_get_hardware_vsel_register(struct regulator *regulator,
unsigned *vsel_reg,
unsigned *vsel_mask);
int regulator_list_hardware_vsel(struct regulator *regulator,
unsigned selector);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
/* regulator notifier block */
int regulator_register_notifier(struct regulator *regulator,
struct notifier_block *nb);
regulator: core: Add devres versions of notifier registration Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05 23:39:20 +08:00
int devm_regulator_register_notifier(struct regulator *regulator,
struct notifier_block *nb);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
int regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb);
regulator: core: Add devres versions of notifier registration Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05 23:39:20 +08:00
void devm_regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
/* driver data - core doesn't touch */
void *regulator_get_drvdata(struct regulator *regulator);
void regulator_set_drvdata(struct regulator *regulator, void *data);
regulator: provide regulator_bulk_set_supply_names() There are many regulator consumers who - before using the regulator bulk functions - set the supply names in regulator_bulk_data using a for loop. Let's provide a simple helper in the consumer API that allows users to do the same with a single function call. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190830071740.4267-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30 15:17:37 +08:00
/* misc helpers */
void regulator_bulk_set_supply_names(struct regulator_bulk_data *consumers,
const char *const *supply_names,
unsigned int num_supplies);
tkernel: add base tlinux kernel interfaces Sync kernel codes to the same with 590eaf1fec75 ("Init Repo base on linux 5.4.32 long term, and add base tlinux kernel interfaces."), which is from tk4, and it is the base of tk4. Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
2024-06-11 20:08:33 +08:00
bool regulator_is_equal(struct regulator *reg1, struct regulator *reg2);
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
#else
/*
* Make sure client drivers will still build on systems with no software
* controllable voltage or current regulators.
*/
static inline struct regulator *__must_check regulator_get(struct device *dev,
const char *id)
{
/* Nothing except the stubbed out regulator API should be
* looking at the value except to check if it is an error
regulator: Let drivers know when they use the stub API Have the stub variant of regulator_get() return NULL, so that drivers can (but still don't have to) handle this case specifically. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Jerome Oufella <jerome.oufella@savoirfairelinux.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-04-03 23:37:45 +08:00
* value. Drivers are free to handle NULL specifically by
* skipping all regulator API calls, but they don't have to.
* Drivers which don't, should make sure they properly handle
* corner cases of the API, such as regulator_get_voltage()
* returning 0.
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
*/
regulator: Let drivers know when they use the stub API Have the stub variant of regulator_get() return NULL, so that drivers can (but still don't have to) handle this case specifically. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Jerome Oufella <jerome.oufella@savoirfairelinux.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-04-03 23:37:45 +08:00
return NULL;
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
}
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>
2012-01-17 11:39:58 +08:00
static inline struct regulator *__must_check
devm_regulator_get(struct device *dev, const char *id)
{
return NULL;
}
regulator: core: Add missing stub for regulator_get_exclusive() Signed-off-by: Mark Brown <broonie@linaro.org>
2013-07-30 04:00:53 +08:00
static inline struct regulator *__must_check
regulator_get_exclusive(struct device *dev, const char *id)
{
regulator: Return an error from stubbed regulator_get_exclusive() The user hasn't got a regulator and shouldn't be mislead into thinking they have one; really we should probably remove this stub entirely (and may well before the next merge window). Signed-off-by: Mark Brown <broonie@kernel.org>
2014-10-25 04:56:58 +08:00
return ERR_PTR(-ENODEV);
regulator: core: Add missing stub for regulator_get_exclusive() Signed-off-by: Mark Brown <broonie@linaro.org>
2013-07-30 04:00:53 +08:00
}
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>
2013-07-30 04:42:42 +08:00
static inline struct regulator *__must_check
regulator_get_optional(struct device *dev, const char *id)
{
regulator: core: Return error in get optional stub Drivers that call regulator_get_optional are tolerant to the absence of that regulator. By modifying the value returned from the stub function to match that seen when a regulator isn't present, callers can wrap the regulator logic with an IS_ERR based conditional even if they happen to call regulator_is_supported_voltage. This improves efficiency as well as eliminates the possibility for a very subtle bug. Signed-off-by: Tim Kryger <tim.kryger@linaro.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-04-18 02:55:24 +08:00
return ERR_PTR(-ENODEV);
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>
2013-07-30 04:42:42 +08:00
}
regulator: core: Add missing stub for regulator_get_exclusive() Signed-off-by: Mark Brown <broonie@linaro.org>
2013-07-30 04:00:53 +08:00
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>
2012-01-17 11:39:58 +08:00
static inline struct regulator *__must_check
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>
2013-07-30 04:42:42 +08:00
devm_regulator_get_optional(struct device *dev, const char *id)
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>
2012-01-17 11:39:58 +08:00
{
regulator: core: Return error in get optional stub Drivers that call regulator_get_optional are tolerant to the absence of that regulator. By modifying the value returned from the stub function to match that seen when a regulator isn't present, callers can wrap the regulator logic with an IS_ERR based conditional even if they happen to call regulator_is_supported_voltage. This improves efficiency as well as eliminates the possibility for a very subtle bug. Signed-off-by: Tim Kryger <tim.kryger@linaro.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-04-18 02:55:24 +08:00
return ERR_PTR(-ENODEV);
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>
2012-01-17 11:39:58 +08:00
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline void regulator_put(struct regulator *regulator)
{
}
regulator: Add devm_regulator_put in consumer.h Commit d5ad34f7cb "regulator: Implement devm_regulator_free()" actually implements devm_regulator_put. Thus rename devm_regulator_free to devm_regulator_put. Also add empty devm_regulator_put for !CONFIG_REGULATOR Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-29 17:52:37 +08:00
static inline void devm_regulator_put(struct regulator *regulator)
{
}
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>
2013-10-16 03:14:20 +08:00
static inline int regulator_register_supply_alias(struct device *dev,
const char *id,
struct device *alias_dev,
const char *alias_id)
{
return 0;
}
static inline void regulator_unregister_supply_alias(struct device *dev,
const char *id)
{
}
static inline int regulator_bulk_register_supply_alias(struct device *dev,
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>
2014-05-23 23:44:10 +08:00
const char *const *id,
struct device *alias_dev,
const char * const *alias_id,
int num_id)
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>
2013-10-16 03:14:20 +08:00
{
return 0;
}
static inline void regulator_bulk_unregister_supply_alias(struct device *dev,
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>
2014-05-23 23:44:10 +08:00
const char * const *id,
int num_id)
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>
2013-10-16 03:14:20 +08:00
{
}
static inline int devm_regulator_register_supply_alias(struct device *dev,
const char *id,
struct device *alias_dev,
const char *alias_id)
{
return 0;
}
static inline void devm_regulator_unregister_supply_alias(struct device *dev,
const char *id)
{
}
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>
2014-05-23 23:44:10 +08:00
static inline int devm_regulator_bulk_register_supply_alias(struct device *dev,
const char *const *id,
struct device *alias_dev,
const char *const *alias_id,
int num_id)
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>
2013-10-16 03:14:20 +08:00
{
return 0;
}
static inline void devm_regulator_bulk_unregister_supply_alias(
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>
2014-05-23 23:44:10 +08:00
struct device *dev, const char *const *id, int num_id)
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>
2013-10-16 03:14:20 +08:00
{
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_enable(struct regulator *regulator)
{
return 0;
}
static inline int regulator_disable(struct regulator *regulator)
{
return 0;
}
regulator: add regulator_force_disable() definition for !CONFIG_REGULATOR regulator_force_disable() was omitted in consumer.h for !CONFIG_REGULATOR case. 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>
2012-01-02 17:49:32 +08:00
static inline int regulator_force_disable(struct regulator *regulator)
{
return 0;
}
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>
2011-09-11 16:53:50 +08:00
static inline int regulator_disable_deferred(struct regulator *regulator,
int ms)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_is_enabled(struct regulator *regulator)
{
return 1;
}
static inline int regulator_bulk_get(struct device *dev,
int num_consumers,
struct regulator_bulk_data *consumers)
{
return 0;
}
regulator: Add empty devm_regulator_bulk_get for !CONFIG_REGULATOR This fixes below build error if CONFIG_REGULATOR is disabled. CC sound/soc/codecs/wm5100.o sound/soc/codecs/wm5100.c: In function ‘wm5100_i2c_probe’: sound/soc/codecs/wm5100.c:2462: error: implicit declaration of function ‘devm_regulator_bulk_get’ make[3]: *** [sound/soc/codecs/wm5100.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-27 12:55:28 +08:00
static inline int devm_regulator_bulk_get(struct device *dev, int num_consumers,
struct regulator_bulk_data *consumers)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_bulk_enable(int num_consumers,
struct regulator_bulk_data *consumers)
{
return 0;
}
static inline int regulator_bulk_disable(int num_consumers,
struct regulator_bulk_data *consumers)
{
return 0;
}
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>
2012-01-03 15:22:03 +08:00
static inline int regulator_bulk_force_disable(int num_consumers,
struct regulator_bulk_data *consumers)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline void regulator_bulk_free(int num_consumers,
struct regulator_bulk_data *consumers)
{
}
static inline int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
return 0;
}
regulators: Add definition of regulator_set_voltage_time() for !CONFIG_REGULATOR We already have dummy implementation for most of the regulators APIs for !CONFIG_REGULATOR case and were missing it for regulator_set_voltage_time(). Found this issue while compiling cpufreq-cpu0 driver without regulators support in kernel. drivers/cpufreq/cpufreq-cpu0.c: In function ‘cpu0_cpufreq_probe’: drivers/cpufreq/cpufreq-cpu0.c:186:3: error: implicit declaration of function ‘regulator_set_voltage_time’ [-Werror=implicit-function-declaration] Fix this by adding dummy definition for regulator_set_voltage_time(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-27 20:07:29 +08:00
static inline int regulator_set_voltage_time(struct regulator *regulator,
int old_uV, int new_uV)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_get_voltage(struct regulator *regulator)
{
regulator: stubs: Make stub regulator_get_voltage() return an error Returning 0 isn't useful, it's not even meaningful if there is a real regulator there. Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-11 20:14:24 +08:00
return -EINVAL;
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
}
regulator: add missing defintion regulator_is_supported_voltage This definition is missing when CONFIG_REGULATOR is not defined. This causes compiler errors when compiling sdhci.c. This can be worked around by adding #ifdef CONFIG_REGULATOR .. #endif but since other definitions are there we have defined the missing definition Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-01 07:05:36 +08:00
static inline int regulator_is_supported_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
return 0;
}
regulator: add regulator_get_linear_step() stub helper The regulator header has empty inline functions for most interfaces, but not regulator_get_linear_step(), which has just grown a user that does not depend on regulators otherwise: drivers/clk/tegra/clk-tegra124-dfll-fcpu.c: In function 'get_alignment_from_regulator': drivers/clk/tegra/clk-tegra124-dfll-fcpu.c:555:19: error: implicit declaration of function 'regulator_get_linear_step'; did you mean 'regulator_get_drvdata'? [-Werror=implicit-function-declaration] align->step_uv = regulator_get_linear_step(reg); ^~~~~~~~~~~~~~~~~~~~~~~~~ regulator_get_drvdata cc1: all warnings being treated as errors scripts/Makefile.build:278: recipe for target 'drivers/clk/tegra/clk-tegra124-dfll-fcpu.o' failed Add the missing stub along the others. Fixes: b3cf8d069505 ("clk: tegra: dfll: CVB calculation alignment with the regulator") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-03-05 03:38:29 +08:00
static inline unsigned int regulator_get_linear_step(struct regulator *regulator)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_set_current_limit(struct regulator *regulator,
int min_uA, int max_uA)
{
return 0;
}
static inline int regulator_get_current_limit(struct regulator *regulator)
{
return 0;
}
static inline int regulator_set_mode(struct regulator *regulator,
unsigned int mode)
{
return 0;
}
static inline unsigned int regulator_get_mode(struct regulator *regulator)
{
return REGULATOR_MODE_NORMAL;
}
regulator: Fix regulator_get_error_flags() signature mismatch The function signature of does not match regulator_get_error_flags() when CONFIG_REGULATOR is not defined vs. when it is not defined. This makes both declarations match to prevent compiler errors. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-12-05 06:52:31 +08:00
static inline int regulator_get_error_flags(struct regulator *regulator,
unsigned int *flags)
regulator: core: Add new API to poll for error conditions Regulator consumers can receive event notifications when errors are reported to the driver, but currently, there is no way for a regulator consumer to know when the error is over. To allow a regulator consumer to poll for error conditions add a new API: regulator_get_error_flags. Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-11-03 19:11:42 +08:00
{
return -EINVAL;
}
regulator: Rename regulator_set_optimum_mode Rename the regulator_set_optimum_mode() function regulator_set_load() to better represent what's going on. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-12 11:35:27 +08:00
static inline int regulator_set_load(struct regulator *regulator, int load_uA)
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
{
regulator: Fix return value of _set_load() stub The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang <cychiang@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-17 11:19:30 +08:00
return 0;
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
}
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>
2012-09-01 01:36:37 +08:00
static inline int regulator_allow_bypass(struct regulator *regulator,
bool allow)
{
return 0;
}
regulator: Add missing statics and inlines for stub functions So we don't get multiple definitions. Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-26 02:07:11 +08:00
static inline struct regmap *regulator_get_regmap(struct regulator *regulator)
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>
2014-07-21 23:38:48 +08:00
{
return ERR_PTR(-EOPNOTSUPP);
}
regulator: Add missing statics and inlines for stub functions So we don't get multiple definitions. Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-26 02:07:11 +08:00
static inline int regulator_get_hardware_vsel_register(struct regulator *regulator,
unsigned *vsel_reg,
unsigned *vsel_mask)
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>
2014-07-21 23:38:48 +08:00
{
return -EOPNOTSUPP;
}
regulator: Add missing statics and inlines for stub functions So we don't get multiple definitions. Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-26 02:07:11 +08:00
static inline int regulator_list_hardware_vsel(struct regulator *regulator,
unsigned selector)
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>
2014-07-21 23:38:48 +08:00
{
return -EOPNOTSUPP;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_register_notifier(struct regulator *regulator,
struct notifier_block *nb)
{
return 0;
}
regulator: core: Add devres versions of notifier registration Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05 23:39:20 +08:00
static inline int devm_regulator_register_notifier(struct regulator *regulator,
struct notifier_block *nb)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline int regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb)
{
return 0;
}
regulator: core: Add devres versions of notifier registration Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05 23:39:20 +08:00
static inline int devm_regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb)
{
return 0;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
static inline void *regulator_get_drvdata(struct regulator *regulator)
{
return NULL;
}
static inline void regulator_set_drvdata(struct regulator *regulator,
void *data)
{
}
regulator: add missing prototype for regulator_is_supported_voltage avoids needs for CONFIG_REGULATOR in sdhci.c Signed-off-by: Philip Rakity <prakity@nvidia.com> Reviewed-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-11-21 01:07:41 +08:00
static inline int regulator_count_voltages(struct regulator *regulator)
{
return 0;
}
regulator: Add missing dummy definition for regulator_list_voltage Fixes a build break when CONFIG_REGULATOR is not selected. e.g, on linux-next - 07102015: drivers/clk/tegra/clk-dfll.c: In function ‘find_lut_index_for_rate’: drivers/clk/tegra/clk-dfll.c:691:3: error: implicit declaration of function ‘regulator_list_voltage’ [-Werror=implicit-function-declaration] if (regulator_list_voltage(td->vdd_reg, td->i2c_lut[i]) == uv) ^ CC drivers/clocksource/mmio.o CC fs/proc/softirqs.o cc1: some warnings being treated as errors make[3]: *** [drivers/clk/tegra/clk-dfll.o] Error 1 make[2]: *** [drivers/clk/tegra] Error 2 make[1]: *** [drivers/clk] Error 2 make[1]: *** Waiting for unfinished jobs.... This should be pushed to 4.2 as we have the issue in 4.2-rc1, just that nobody uses it without the REGULATOR(yet). Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-10 23:26:38 +08:00
static inline int regulator_list_voltage(struct regulator *regulator, unsigned selector)
{
return -EINVAL;
}
regulator: add missing 'static inline' to a helper's stub The build fails when CONFIG_REGULATOR is not selected because the stub for regulator_bulk_set_supply_names() is missing the 'static inline' attribute. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190902151332.28058-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-02 23:13:32 +08:00
static inline void
regulator_bulk_set_supply_names(struct regulator_bulk_data *consumers,
const char *const *supply_names,
unsigned int num_supplies)
regulator: provide regulator_bulk_set_supply_names() There are many regulator consumers who - before using the regulator bulk functions - set the supply names in regulator_bulk_data using a for loop. Let's provide a simple helper in the consumer API that allows users to do the same with a single function call. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190830071740.4267-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30 15:17:37 +08:00
{
}
tkernel: add base tlinux kernel interfaces Sync kernel codes to the same with 590eaf1fec75 ("Init Repo base on linux 5.4.32 long term, and add base tlinux kernel interfaces."), which is from tk4, and it is the base of tk4. Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
2024-06-11 20:08:33 +08:00
static inline bool
regulator_is_equal(struct regulator *reg1, struct regulator *reg2)
{
return false;
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
#endif
regulator: core: Define regulator_set_voltage_triplet() Voltage tolerance isn't necessarily same on both sides of the target voltage and regulator_set_voltage_tol() wouldn't be suitable in such cases. Add another routine regulator_set_voltage_triplet(), which accepts target, min and max voltages as arguments. This first tries to set the voltage between the target voltage and the upper limit, then fall back on the full range. The idea behind this is to set regulator's voltage as close to the target voltage, as possible. Based on regulator_set_voltage_tol(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-17 10:46:51 +08:00
static inline int regulator_set_voltage_triplet(struct regulator *regulator,
int min_uV, int target_uV,
int max_uV)
{
if (regulator_set_voltage(regulator, target_uV, max_uV) == 0)
return 0;
return regulator_set_voltage(regulator, min_uV, max_uV);
}
regulator: add a new API regulator_set_voltage_tol() There are some use cases where a voltage range could be reasonably specified by a target voltage and tolerance. Add a new API regulator_set_voltage_tol() wrapping regulator_set_voltage() call to ease the users. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-05 23:05:20 +08:00
static inline int regulator_set_voltage_tol(struct regulator *regulator,
int new_uV, int tol_uV)
{
regulator: core: Make set_voltage_tol() try for mid-range first The expected semantic for something expressed as a tolerance is that it should deliver the specified value with some deviation allowed but this is not what set_voltage_tol() currently does. Instead it just passes the maximum possible range to set_voltage() which will typically result in a voltage aimed at lower than the target voltage. Instead first try to set a voltage between the target voltage and the upper limit, then fall back on the full range. This will be much more robust against physical variation in systems and makes the API behave more like users would expect. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-07-05 00:27:14 +08:00
if (regulator_set_voltage(regulator, new_uV, new_uV + tol_uV) == 0)
return 0;
else
return regulator_set_voltage(regulator,
new_uV - tol_uV, new_uV + tol_uV);
regulator: add a new API regulator_set_voltage_tol() There are some use cases where a voltage range could be reasonably specified by a target voltage and tolerance. Add a new API regulator_set_voltage_tol() wrapping regulator_set_voltage() call to ease the users. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-05 23:05:20 +08:00
}
regulator: core: Add regulator_is_supported_voltage_tol() If consumers wish to set voltages based on a tolerance it stands to reason that they will also want to query for support in the same manner. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
2012-11-14 15:47:10 +08:00
static inline int regulator_is_supported_voltage_tol(struct regulator *regulator,
int target_uV, int tol_uV)
{
return regulator_is_supported_voltage(regulator,
target_uV - tol_uV,
target_uV + tol_uV);
}
regulator: consumer device interface Add support to allow consumer device drivers to control their regulator power supply. This uses a similar API to the kernel clock interface in that consumer drivers can get and put a regulator (like they can with clocks atm) and get/set voltage, current limit, mode, enable and disable. This should allow consumers complete control over their supply voltage and current limit. This also compiles out if not in use so drivers can be reused in systems with no regulator based power control. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2008-04-30 22:10:07 +08:00
#endif