- 24 May, 2018 7 commits
-
-
Linus Walleij authored
Instead of passing a global GPIO number, pass a descriptor looked up with the standard devm_gpiod_get_index_optional() call. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Instead of passing a global GPIO number, pass a descriptor looked up with the standard devm_gpiod_get_optional() call. Signed-off-by:
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by:
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by:
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by:
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by:
-
- 17 May, 2018 15 commits
-
-
Anson Huang authored
If is_enabled() is not defined, regulator core will assume this regulator is already enabled, then it can NOT be really enabled after disabled. Based on Li Jun's patch from the NXP kernel tree. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
-
Anson Huang authored
Add enable/disable support for switch regulator on pfuze100. Based on Robin Gong's patch from the NXP kernel tree. Signed-off-by:
-
Linus Walleij authored
Instead of passing a global GPIO number for the enable GPIO, pass a descriptor looked up from the device tree node or the board file decriptor table for the regulator. There is a single board file passing the GPIOs for LDO1 and LDO2 through platform data, so augment this to pass descriptors associated with the i2c device as well. The special GPIO enable DT property for the enable GPIO is nonstandard but this was accomodated in commit 6a537d48 "gpio: of: Support regulator nonstandard GPIO properties". Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Maciej Purski authored
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Uncoupled regulators should be a special case of coupled regulators, so they should share a common voltage setting path. When enabling, disabling or setting voltage of a coupled regulator, all coupled regulators should be locked. Regulator's supplies should be locked, when setting voltage of a single regulator. Enabling a coupled regulator or setting its voltage should not be possible if some of its coupled regulators, has not been registered. Add function for locking coupled regulators and supplies. Extract a new function regulator_set_voltage_rdev() from regulator_set_voltage_unlocked(), which is called when setting voltage of a single regulator. Signed-off-by:
Maciej Purski <m.purski@samsung.com> Signed-off-by:
-
Maciej Purski authored
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Introduce new function regulator_balance_voltage(), which keeps max_spread constraint fulfilled between a group of coupled regulators. It should be called if a regulator changes its voltage or after disabling or enabling. Disabled regulators should follow changes of the enabled ones, but their consumers' demands shouldn't be taken into account while calculating voltage of other coupled regulators. Find voltages, which are closest to suiting all the consumers' demands, while fulfilling max_spread constraint, keeping the following rules: - if one regulator is about to rise its voltage, rise others voltages in order to keep the max_spread - if a regulator, which has caused rising other regulators, is lowered, lower other regulators if possible - if one regulator is about to lower its voltage, but it hasn't caused rising other regulators, don't change its voltage if it breaks the max_spread Change regulators' voltages step by step, keeping max_spread constraint fulfilled all the time. Function regulator_get_optimal_voltage() should find the best possible change for the regulator, which doesn't break max_spread constraint. In function regulator_balance_voltage() optimize number of steps by finding highest voltage difference on each iteration. If a regulator, which is about to change its voltage, is not coupled, method regulator_get_optimal_voltage() should simply return the lowest voltage fulfilling consumers' demands. Coupling should be checked only if the system is in PM_SUSPEND_ON state. Signed-off-by:
-
Maciej Purski authored
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Fill coupling descriptor with data obtained from DTS using previously defined of_functions. Fail to register a regulator, if some data inconsistency occurs. If some coupled regulators are not yet registered, don't fail to register, but try to resolve them in late init call. Signed-off-by:
-
Maciej Purski authored
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Add new structure "coupling_desc" to regulator_dev, which contains pointers to all coupled regulators including the owner of the structure, number of coupled regulators and counter of currently resolved regulators. Add of_functions to parse all data needed in regulator coupling. Provide method to check DTS data consistency. Check if each coupled regulator's max_spread is equal and if their lists of regulators match. Signed-off-by:
-
Maciej Purski authored
Some regulators require keeping their voltage spread below defined max_spread. Add properties to provide information on regulators' coupling. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Maciej Purski authored
Setting voltage, enabling/disabling regulators requires operations on all regulators related with the regulator being changed. Therefore, all of them should be locked for the whole operation. With the current locking implementation, adding additional dependency (regulators coupling) causes deadlocks in some cases. Introduce a possibility to attempt to lock a mutex multiple times by the same task without waiting on a mutex. This should handle all reasonable coupling-supplying combinations, especially when two coupled regulators share common supplies. The only situation that should be forbidden is simultaneous coupling and supplying between a pair of regulators. The idea is based on clk core. Signed-off-by:
-
Linus Walleij authored
Instead of passing a global GPIO number for the enable GPIO, pass a descriptor looked up with the standard devm_gpiod_get_optional() call. This regulator supports passing platform data, but enable/sleep regulators are looked up from the device tree exclusively, so we can need not touch other files. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Tested-by:
-
Linus Walleij authored
Instead of passing a global GPIO number, pass a descriptor looked up from the device tree configuration node. Signed-off-by:
-
Linus Walleij authored
Instead of passing a global GPIO number, pass a descriptor looked up with the standard devm_gpiod_get_optional() call. We have augmented the GPIO core to look up the regulator special GPIO "wlf,ldoena" in commit 6a537d48 "gpio: of: Support regulator nonstandard GPIO properties". Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
David Collins authored
Add support for configuring the machine constraints valid_modes_mask element based on a list of allowed modes specified via a device tree property. Signed-off-by:
David Collins <collinsd@codeaurora.org> Signed-off-by:
-
David Collins authored
Add a common device tree property for regulator nodes to support the specification of allowed operating modes. Signed-off-by:
-
Douglas Anderson authored
Regulators attached via RPMh on Qualcomm sdm845 apparently are write-only. Specifically you can send a request for a certain voltage but you can't read back to see what voltage you've requested. What this means is that at bootup we have absolutely no idea what voltage we could be at. As discussed in the patches to try to support the RPMh regulators [1], the fact that regulators are write-only means that its driver's get_voltage_sel() should return an error code if it's called before any calls to set_voltage_sel(). This causes problems in machine_constraints_voltage() when trying to apply the constraints. A proposed fix was to come up with an error code that could be returned by get_voltage_sel() which would cause the regulator framework to simply try setting the voltage with the current constraints. In this patch I propose the error code -ENOTRECOVERABLE. In errno.h this error is described as "State not recoverable". Though the error code was originally intended "for robust mutexes", the description of the error code seems to apply here because we can't read the state of the regulator. Also note that the only existing user of this error code in the regulator framework is tps65090-regulator.c which returns this error code from the enable() call (not get_voltage() or get_voltage_sel()), so there should be no existing regulators that might accidentally get the new behavior. (Side note is that tps65090 seems to interpret this error code to mean an error that you can't recover from rather than some data that can't be recovered). [1] https://patchwork.kernel.org/patch/10340897/Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 09 May, 2018 2 commits
-
-
Ondrej Jirman authored
SY8106A is an I2C attached single output regulator made by Silergy Corp, which is used on several Allwinner H3/H5 SBCs to control the power supply of the ARM cores. Add a driver for it. Signed-off-by:
Ondrej Jirman <megous@megous.com> [Icenowy: Change commit message, remove enable/disable code, add default ramp_delay, add comment for go bit, add code for fixed mode voltage] Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Ondrej Jirman authored
SY8106A is an I2C-controlled adjustable voltage regulator made by Silergy Corp. Add its device tree binding. Signed-off-by:
-
- 05 May, 2018 2 commits
-
-
Changbin Du authored
If device tree is not enabled, of_find_regulator_by_node() should have a dummy function since the function call is still there. This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced. If this option is enabled, GCC will not auto-inline functions that are not explicitly marked as inline. In this case (no CONFIG_OF), the copmiler will report error in function regulator_dev_lookup(). W/O NO_AUTO_INLINE, function of_get_regulator() is auto-inlined and then the call to of_find_regulator_by_node() is optimized out since of_get_regulator() always return NULL. W/ NO_AUTO_INLINE, the return value of of_get_regulator() is a variable so the call to of_find_regulator_by_node() cannot be optimized out. So we need a stub of_find_regulator_by_node(). static struct regulator_dev *regulator_dev_lookup(struct device *dev, const char *supply) { struct regulator_dev *r = NULL; struct device_node *node; struct regulator_map *map; const char *devname = NULL; regulator_supply_alias(&dev, &supply); /* first do a dt based lookup */ if (dev && dev->of_node) { node = of_get_regulator(dev, supply); if (node) { r = of_find_regulator_by_node(node); if (r) return r; ... Signed-off-by:Changbin Du <changbin.du@intel.com> Signed-off-by:
-
Fabio Estevam authored
According to Devicetree Specification v0.2 document: "The name of a node should be somewhat generic, reflecting the function of the device and not its precise programming model." Do as suggested in the binding example. Signed-off-by:
-
- 01 May, 2018 1 commit
-
-
Mark Brown authored
Merge branch 'topic/bd9571mwv' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.18
-
- 23 Apr, 2018 6 commits
-
-
Geert Uytterhoeven authored
The BD9571MWV PMIC supports backup mode, which keeps one or more DDR rails powered while the main SoC is powered down. Which DDR rails are to be kept powered is board-specific, and controlled using the optional "rohm,ddr-backup-power" DT property. In the absence of this property, backup mode is not available. Backup mode can be enabled or disabled by the user using the standard "wakeup" virtual file in sysfs, e.g. to enable: echo enabled > /sys/devices/platform/soc/e60b0000.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup When the PMIC is configured for backup mode, the role of the accessory power switch changes from a power switch to a wake-up switch. Two types of switches (or signals) can be used: A. With a momentary power switch (or pulse signal), the PMIC is configured for backup mode in the PMIC driver's suspend callback, during system suspend. Backup mode is enabled by default, as there is no further impact during normal system operation. B. With a toggle power switch (or level signal), the following steps must be followed exactly: 1. Configure PMIC for backup mode, 2. Switch accessory power switch off, to prepare for system suspend, which is a manual step not controlled by software, 3. Suspend system. This mode is not yet supported by the driver. As the switch type is board-specific, and cannot be determined automatically, it is obtained from the presence of one of the "rohm,rstbmode-*" properties in DT. Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Geert Uytterhoeven authored
Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which is amongst others used to configure DDR Backup Power. Signed-off-by:
-
Geert Uytterhoeven authored
Add definitions for the KEEPON_* bits in the "BKUP Mode Cnt" register, which control the DDR rails to be kept powered when backup mode is enabled. Signed-off-by:
-
Geert Uytterhoeven authored
Document the new optional properties related to DDR Backup Mode and toggle/momentary power switches. Signed-off-by:
-
Jagan Teki authored
Like axp221, axp223, axp813 the axp803 is also supporting external regulator to drive the OTG VBus through N_VBUSEN PMIC pin. Add support for it. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Colin Ian King authored
It seems that the loop index i is not being incremented and hence potentially the while loop could spin forever. Fortunately with the data being used this does not appear to happen at the moment. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
- 20 Apr, 2018 2 commits
-
-
Douglas Anderson authored
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: 5e5e3a42 ("regulator: of: Add support for parsing initial and suspend modes") Suggested-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
ryang authored
This version is exists in the Samsung Galaxy Tab 10.1 which is based on the Nvidia Tegra 2 board. The TPS658624 has the same SM2 voltage table as TPS658623. Signed-off-by:
ryang <decatf@gmail.com> Acked-by:
-
- 18 Apr, 2018 1 commit
-
-
Anson Huang authored
pfuze3000 datasheet(Rev.9.0) from: https://www.nxp.com/docs/en/data-sheet/PF3000.pdf updates sw1a's voltage range, the settings for 1.450V and 1.475V are replaced with 1.8V and 3.3V: 5b'11110 1.450 (SW1B), 1.8 (SW1A/SW1AB) 5b'11111 1.475 (SW1B), 3.3 (SW1A/SW1AB) the voltage calculation using steps is NOT available for sw1a now, use voltage table instead. Signed-off-by:
Robin Gong <yibin.gong@nxp.com> Signed-off-by:
-
- 17 Apr, 2018 2 commits
-
-
Keerthy authored
Buck10 is a multi(dual) phase regulator. So as part of enabling it turn on the LP87565_BUCK_CTRL_1_FPWM_MP_0_2 bit which forces it to operate always in multiphase and forced-PWM operation mode. This helps improve the transient voltage response while switching OPP. Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
-
Keerthy authored
The slew rate might need a +/- 15% margin as per the latest data manual: http://www.ti.com/lit/ds/snvsb22/snvsb22.pdf Hence take a conservative approach to program 85% of the original hardware slew rate so that the software accommodates the margin delay while voltage switching. Hence reduce the default ramp_delay populated in the descriptors also by 15%. Signed-off-by:
-
- 16 Apr, 2018 2 commits
-
-
Linus Walleij authored
The AB8540 was an evolved version of the AB8500, but it was never mass produced or put into products, only reference designs exist. The upstream support was never completed and it is unlikely that this will happen so drop the support for now to simplify maintenance of the AB8500. Cc: Loic Pallardy <loic.pallardy@st.com> Signed-off-by:
-
Linus Torvalds authored
-
