#
259b93b2 |
|
16-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14 Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
962f170d |
|
26-Jun-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Fix n_voltages setting for lm36274 According to the datasheet http://www.ti.com/lit/ds/symlink/lm36274.pdf: Table 23. VPOS Bias Register Field Descriptions VPOS[5:0]: VPOS voltage (50-mV steps): VPOS = 4 V + (Code × 50 mV), 6.5 V max 000000 = 4 V 000001 = 4.05 V : 011110 = 5.5 V (Default) : 110010 = 6.5 V 110011 to 111111 map to 6.5 V So the LM36274_LDO_VSEL_MAX should be 0b110010 (0x32). The valid selectors are 0 ... LM36274_LDO_VSEL_MAX, n_voltages should be LM36274_LDO_VSEL_MAX + 1. Similarly, the n_voltages should be LM36274_BOOST_VSEL_MAX + 1 for LM36274_BOOST. Fixes: bff5e8071533 ("regulator: lm363x: Add support for LM36274") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20190626132632.32629-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1e2cc8c5 |
|
26-Jun-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Fix off-by-one n_voltages for lm3632 ldo_vpos/ldo_vneg According to the datasheet https://www.ti.com/lit/ds/symlink/lm3632a.pdf Table 20. VPOS Bias Register Field Descriptions VPOS[5:0] Sets the Positive Display Bias (LDO) Voltage (50 mV per step) 000000: 4 V 000001: 4.05 V 000010: 4.1 V .................... 011101: 5.45 V 011110: 5.5 V (Default) 011111: 5.55 V .................... 100111: 5.95 V 101000: 6 V Note: Codes 101001 to 111111 map to 6 V The LM3632_LDO_VSEL_MAX should be 0b101000 (0x28), so the maximum voltage can match the datasheet. Fixes: 3a8d1a73a037 ("regulator: add LM363X driver") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20190626132632.32629-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d2912cb1 |
|
04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
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>
|
#
bff5e807 |
|
05-Jun-2019 |
Dan Murphy <dmurphy@ti.com> |
regulator: lm363x: Add support for LM36274 Adding regulator support for the LM36274 backlight driver. This device can leverage this existing code as the functionality and registers are common enough between the LM36274 and the LM363x series of devices. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
55c083d8 |
|
02-Apr-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Constify regulator_ops The lm363x_boost_voltage_table_ops and lm363x_regulator_voltage_table_ops never need to be modified, make them const so compiler can put them to .rodata. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8a76f107 |
|
02-Apr-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Use proper data type for regmap_read arguments regmap_read() takes unsigned int reg and unsigned int *val arguments, use proper data type for these arguments. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c68f47aa |
|
08-Feb-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Check return value of gpiod_get_index_optional gpiod_get_index_optional can return ERR_PTR, add IS_ERR checking for it. While at it, also remove a redundant NULL test for gpiod in error path. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e8a33aa0 |
|
06-Dec-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: lm363x: Let core handle GPIO descriptor Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: b2d751b7f69b ("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>
|
#
63239e4b |
|
15-Oct-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: Fetch enable gpiods nonexclusive Since the core regulator code is treating GPIO descriptors as nonexclusive, i.e. it assumes that the enable GPIO line may be shared with several regulators, let's add the flag introduced for fixing this problem on fixed regulators to all drivers fetching GPIO descriptors to avoid possible regressions. Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b2d751b7 |
|
14-May-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: lm363x: Pass descriptor instead of GPIO number 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>
|
#
9503b508 |
|
28-Feb-2017 |
Milo Kim <milo.kim@ti.com> |
regulator: lm363x: Use generic DT property name for external control pins Vpos and Vneg LDOs can be enabled or disabled by external GPIOs. Use general DT property 'enable-gpios' for this usage. Two enable pins are differentiable by selecting the index number. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
faa5cf3a |
|
29-Nov-2015 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Staticise ldo_cont_enable_time Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a8bc6ca0 |
|
28-Nov-2015 |
Axel Lin <axel.lin@ingics.com> |
regulator: lm363x: Remove struct lm363x_regulator which is not necessary Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3a8d1a73 |
|
25-Nov-2015 |
Milo Kim <milo.kim@ti.com> |
regulator: add LM363X driver LM363X regulator driver supports LM3631 and LM3632. LM3631 has 5 regulators. LM3632 provides 3 regulators. One boost output and LDOs are used for the display module. Boost voltage is configurable but always on. Supported operations for LDOs are enabled/disabled and voltage change. Two LDOs of LM3632 can be controlled by external pins. Those are configured through the DT properties. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|