Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20 |
|
#
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 regulato
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>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16 |
|
#
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
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>
show more ...
|
#
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 VPO
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>
show more ...
|
Revision tags: v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8 |
|
#
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 th
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>
show more ...
|
#
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
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>
show more ...
|
Revision tags: v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6 |
|
#
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.
S
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>
show more ...
|
#
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
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>
show more ...
|
Revision tags: v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21 |
|
#
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
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>
show more ...
|
Revision tags: v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8 |
|
#
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: 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>
show more ...
|
Revision tags: v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15 |
|
#
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 regulator
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>
show more ...
|
Revision tags: v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
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:
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>
show more ...
|
Revision tags: v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2 |
|
#
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
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>
show more ...
|
Revision tags: v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1 |
|
#
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 |
| 29-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 |
| 26-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. Boo
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>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16 |
|
#
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]:
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>
show more ...
|
#
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 Desc
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>
show more ...
|
#
8a3367cc |
| 09-Jul-2019 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'leds-for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: - Add a new LED common module for ti-l
Merge tag 'leds-for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: - Add a new LED common module for ti-lmu driver family - Modify MFD ti-lmu bindings - add ti,brightness-resolution - add the ramp up/down property - Add regulator support for LM36274 driver to lm363x-regulator.c - New LED class drivers with DT bindings: - leds-spi-byte - leds-lm36274 - leds-lm3697 (move the support from MFD to LED subsystem) - Simplify getting the I2C adapter of a client: - leds-tca6507 - leds-pca955x - Convert LED documentation to ReST * tag 'leds-for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: dt: leds-lm36274.txt: fix a broken reference to ti-lmu.txt docs: leds: convert to ReST leds: leds-tca6507: simplify getting the adapter of a client leds: leds-pca955x: simplify getting the adapter of a client leds: lm36274: Introduce the TI LM36274 LED driver dt-bindings: leds: Add LED bindings for the LM36274 regulator: lm363x: Add support for LM36274 mfd: ti-lmu: Add LM36274 support to the ti-lmu dt-bindings: mfd: Add lm36274 bindings to ti-lmu leds: max77650: Remove set but not used variable 'parent' leds: avoid flush_work in atomic context leds: lm3697: Introduce the lm3697 driver mfd: ti-lmu: Remove support for LM3697 dt-bindings: ti-lmu: Modify dt bindings for the LM3697 leds: TI LMU: Add common code for TI LMU devices leds: spi-byte: add single byte SPI LED driver dt-bindings: leds: Add binding for spi-byte LED. dt-bindings: mfd: LMU: Add ti,brightness-resolution dt-bindings: mfd: LMU: Add the ramp up/down property
show more ...
|
Revision tags: v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8 |
|
#
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 u
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>
show more ...
|
#
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 a
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>
show more ...
|
Revision tags: v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6 |
|
#
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
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>
show more ...
|
#
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.
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>
show more ...
|
Revision tags: v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21 |
|
#
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
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>
show more ...
|
Revision tags: v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8 |
|
#
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. F
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>
show more ...
|
Revision tags: v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15 |
|
#
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 s
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>
show more ...
|