- 11 Dec, 2018 12 commits
-
-
Linus Walleij authored
The GPIO descriptors used by the DA9211 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before handing it over to the regulators core. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
The probe path of this driver is a bit complex: sometimes the GPIO descriptor is passed to the regulator core, sometimes it is not. To handle it in a simple way: stick with the devm_* resource management and unhinge the GPIO descriptor devres handling right before passing it to the regulator core, if we pass it to the regulator core. Fixes: e7d2be69 ("regulator: max8973: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could imagine that fits Rusty Russell's API design criterions "the obvious use is the correct one" and "the name tells you how to use it". The idea came out of a remark from Mark Brown that it should be possible to handle over management of a resource from devres to the regulator core, and indeed we can do that. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
When we get a nonexeclusive GPIO descriptor using managed resources, we should only add it to the list of managed resources once: on the first user. Augment the devm_gpiod_get_index() and devm_gpiod_get_from_of_node() calls to account for this by checking if the descriptor is already resource managed before we proceed to allocate a new resource management struct. Fixes: b0ce7b29 ("regulator/gpio: Allow nonexclusive GPIO access") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
This makes gpiod_get_from_of_node() respect the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially nice when getting regulator GPIOs right out of device tree nodes. Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: b0ce7b29 ("regulator/gpio: Allow nonexclusive GPIO access") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Use the gpiod_get_from_of_node() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fix up the errorpath so that we free this descriptor if an error occurs in the callback. Rely on the regulator core to deal with it after this point: a previous patch fixed up the regulator core to properly dispose any GPIO descriptors once you call regulator_register(). Fixes: 96392c3d ("regulator: max77686: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when done with a descriptor, so export this function so we can hand the refcounting over to the regulator core for these descriptors after retrieveal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: d7a261c2 ("regulator: max8952: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: 2468f0d5 ("regulator: lp8788-ldo: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: b2d751b7 ("regulator: lm363x: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: efdfeb07 ("regulator: fixed: Convert to use GPIO descriptor only") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
If a GPIO descriptor is passed to the regulator_register() function inside the config->ena_gpiod callers must be sure that once they call this API the regulator core owns that descriptor and will make sure to issue gpiod_put() on it, no matter whether the call is successful or not. For device tree regulators, the regulator core will automatically set up regulator init data from the device tree when registering a regulator by calling regulator_of_get_init_data() which in turn calls down to the regulator driver's .of_parse_cb() callback. This callback (in drivers such as for max77686) may also choose to fill in the config->ena_gpiod field with a GPIO descriptor. Harden the errorpath of regulator_register() to properly gpiod_put() any passed in cfg->ena_gpiod or any gpiod coming from the device tree on any type of error. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 06 Dec, 2018 1 commit
-
-
Rob Herring authored
Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. For instances using of_node_cmp, this has the side effect of now using case sensitive comparisons. This should not matter for any FDT based system which all of these are. Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Support Opensource <support.opensource@diasemi.com> Cc: Sangbeom Kim <sbkim73@samsung.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 04 Dec, 2018 2 commits
-
-
Charles Keepax authored
Currently it is expected that regulator init data will be defined as a series of sub-nodes from the node that bound in the driver. Add support for a node to both bind in a driver and contain init data for that regulator. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
To support future additions factor out the location of the OF node containing the init data for the regulator from the code that parses the init data. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 03 Dec, 2018 1 commit
-
-
Pascal PAILLET-LME authored
fix a compilation issue due to regulator_lock usage. Signed-off-by: Pascal Paillet <p.paillet@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 26 Nov, 2018 1 commit
-
-
Douglas Anderson authored
Prior to commit 5451781d ("regulator: core: Only count load for enabled consumers") we used to always add up the total load on every enable in _regulator_enable(). After that commit we only updated the total load when enabling / disabling a regulator where a consumer specified a load or when changing the consumer load on an enabled regulator. The problem with the new scheme is that if there is a system load specified for a regulator but no consumers specify a load then we never account for it. Let's account for the system load in set_machine_constraints(). NOTE: with the new scheme we end up with a bit of a quandry. What if someone specifies _both_ an initial mode and a system load? If we take the system load into account right at init time then it will effectively clobber the initial mode. We'll resolve this by saying that if both are specified then the initial mode will win. The system load will then only take effect if/when a consumer specifies a load. If no consumers ever specify a load then the initial mode will persist and the system load will have no effect. Fixes: 5451781d ("regulator: core: Only count load for enabled consumers") Reported-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 22 Nov, 2018 3 commits
-
-
Ryan Case authored
Address remaining comments from original driver patch series * Move RD_FIFO_CFG to be ordered corretly * Expand spinlock comment Signed-off-by: Ryan Case <ryandcase@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Douglas Anderson authored
When we called regulator_enable() on a regulator we'd end up propagating that call all the way up the chain every time. This is a bit of a waste of time. A child regulator already refcounts its own enables so it should avoid passing on to its parent unless the refcount transitioned between 0 and 1. Historically this hasn't been a huge problem since we skipped dealing with enable for always-on regulators. In a previous patch, however, we removed the always-on optimization. On one system, the debugfs regulator_summary was now showing a "use_count" of 33 for a top-level regulator. Let's implement this optimization. This turns out to be fairly trivial with the recent reorganization of the regulator core. NOTE: as part of this patch I'll make "always-on" regulators start with a use count of 1. This keeps the counts clean when recursively resolving regulators. ALSO NOTE: this commit also contains somewhat of a bug fix to regulator_force_disable(). It was incorrectly looping over "rdev->open_count" when it should have been looping over use_count. We have to touch that code anyway (since we should no longer loop at all), so we'll fix it together in one patch. Also: since this comes after commit f8702f9e ("regulator: core: Use ww_mutex for regulators locking") we can now move to use _regulator_disable() for our supply and keep it in the lock. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Douglas Anderson authored
In general when the consumer of a regulator requests that the regulator be disabled it no longer will be drawing much load from the regulator--it should just be the leakage current and that should be very close to 0. Up to this point the regulator framework has continued to count a consumer's load request for disabled regulators. This has led to code patterns that look like this: enable_my_thing(): regular_set_load(reg, load_uA) regulator_enable(reg) disable_my_thing(): regulator_disable(reg) regulator_set_load(reg, 0) Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead of setting a 0 uA load. I will make the assertion that nearly all (if not all) places where we set a nominal load of 100 uA or less we end up with a result that is the same as if we had set a load of 0 uA. Specifically: - The whole point of setting the load is to help set the operating mode of the regulator. Higher loads may need less efficient operating modes. - The only time this matters at all is if there is another consumer of the regulator that wants the regulator on. If there are no other consumers of the regulator then the regulator will turn off and we don't care about the operating mode. - If there's another consumer that actually wants the regulator on then presumably it is requesting a load that makes our nominal <= 100 uA load insignificant. A quick survey of the existing callers to regulator_set_load() to see how everyone uses it: Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 21 Nov, 2018 1 commit
-
-
Charles Keepax authored
The regulator core takes over managing the lifetime of the enable GPIO once the regulator is registered. As such we shouldn't register the enable GPIO using devm, or it will be freed twice. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 20 Nov, 2018 4 commits
-
-
Douglas Anderson authored
The "requested_microamps" sysfs attribute was only being exposed for "current" regulators. This didn't make sense. Allow it to be exposed always. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Lochnagar is an evaluation and development board for Cirrus Logic Smart CODEC and Amp devices. It allows the connection of most Cirrus Logic devices on mini-cards, as well as allowing connection of various application processor systems to provide a full evaluation platform. This driver supports the board controller chip on the Lochnagar board. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Based on review comments on the MFD driver, move the child drivers for the Lochnagar MFD over to binding through device tree. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Marek Szyprowski authored
GPIO descriptor array must be zero initialized to ensure that core will properly handle also the case when no external GPIO pin is defined. Fixes: 1c984942 ("regulator: s2mps11: Pass descriptor instead of GPIO number") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 19 Nov, 2018 5 commits
-
-
Mark Brown authored
Merge branch 'topic/coupled' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21 for trivial conflict
-
Dmitry Osipenko authored
Redefine binding for regulator-coupled-max-spread property in a way that max-spread values are defined per regulator couple instead of defining single max-spread for the whole group of coupled regulators. With that change the following regulators coupling configuration will be possible: regA: regulatorA { regulator-coupled-with = <®B ®C>; regulator-coupled-max-spread = <100000 300000>; }; regB: regulatorB { regulator-coupled-with = <®A ®C>; regulator-coupled-max-spread = <100000 200000>; }; regC: regulatorC { regulator-coupled-with = <®A ®B>; regulator-coupled-max-spread = <300000 200000>; }; Note that the regulator-coupled-max-spread property does not have any users yet, hence it's okay to change the binding. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Osipenko authored
It's unlikely that regulators may disappear/appear while regulators debug-summary is being prepared, but let's be consistent and avoid that situation. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Osipenko authored
Check whether supply regulator is the couple to avoid infinite recursion during of locking. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Osipenko authored
Wait/wound mutex shall be used in order to avoid lockups on locking of coupled regulators. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Suggested-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 15 Nov, 2018 4 commits
-
-
zoro authored
when the VIR_LDO1 regulator supplier is it's brother, we can't find the supplier. example code : &vir_regulator { ldo0_vir: ldo0-virtual { regulator-compatible = "VIR_LDO0"; regulator-name= "VIR_LDO0"; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <2000000>; }; ldo1_vir: ldo1-virtual { regulator-compatible = "VIR_LDO1"; regulator-name= "VIR_LDO1"; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <3000000>; ldo1-supply = <&ldo0_vir>; }; ... } so we add the child ptah to find the suppier. Signed-off-by: zoro <long17.cool@163.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
Instead of passing a global GPIO number, pass a descriptor looked up from the device tree configuration node. Tested on Odroid U3 (with max77686 although not using any GPIOs for regulators, so at least default paths are not broken). Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Krzysztof Kozlowski <krzk@kernel.org> 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 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". Cc: patches@opensource.cirrus.com Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Lee Jones <lee.jones@linaro.org> 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 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. Tested on Odroid XU3 (with s2mps11 although not using any GPIOs for regulators, so at least default paths are not broken). Cc: Sangbeom Kim <sbkim73@samsung.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 14 Nov, 2018 3 commits
-
-
Matti Vaittinen authored
BD71837 and BD71847 have a HW functionality which leave power rails OFF after powerof state: - if they have been controlled by SW. - if state transition from poweroff is done to SNVS BD71837 can after reset transition from power-off to SNVS or READY state depending on reset reason. By default only wathcdog reset changes state from poweroff to ready. Change PMIC configuration to always transition to READY in order to avoid crucial power rails being OFF after reset. If SNVS is required the crucial power rails should not be controlled by SW - eg corresponding regulator control register should have SEL bit kept zero. Currently the driver assumes all regulators to be controlled by SW so it sets all SEL bits to 1. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 13 Nov, 2018 3 commits
-
-
Axel Lin authored
The voltages in bd718xx_3rd_nodvs_buck_volts are in ascendant order, so use regulator_map_voltage_ascend. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Andrei.Stefanescu@microchip.com authored
Set the according constraints for PM_SUSPEND_STANDBY case. Previously, only suspend to mem/disk were taken into consideration. Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Andrei.Stefanescu@microchip.com authored
For state-mem and state-disk regulators can have various parameters applied such as enabled/disabled, current mode, voltage etc. This patch adds documentation on how to set these parameters in the device tree for the standby state. Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-