pm24.git/drivers/regulator, branch perf-mon

Merge tag 'regulator-fix-v6.14-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2025-01-29T19:56:55Z

Pull regulator fixes from Mark Brown: "A couple of fixes that have come in during the merge window: one that operates the TPS6287x devices more within the design spec and can prevent current surges when changing voltages and another more trivial one for error message formatting" * tag 'regulator-fix-v6.14-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: core: Add missing newline character regulator: TPS6287X: Use min/max uV to get VRANGE

Merge tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2025-01-22T17:03:41Z

Pull regulator updates from Mark Brown: "This was a very quiet release, aside from some smaller improvements we have: - Support for power budgeting on regulators, initially targeted at some still in review support for PSE controllers but generally useful - Support for error interrupts from ROHM BD96801 devices - Support for NXP PCA9452" * tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: dt-bindings: Add regulator-power-budget-milliwatt property regulator: Add support for power budget regulator: core: Resolve supply using of_node from regulator_config regulator: of: Implement the unwind path of of_regulator_match() regulator: tps65219: Remove debugging helper function regulator: tps65219: Remove MODULE_ALIAS regulator: tps65219: Update driver name regulator: tps65219: Use dev_err_probe() instead of dev_err() regulator: dt-bindings: mt6315: Drop regulator-compatible property regulator: pca9450: Add PMIC pca9452 support regulator: dt-bindings: pca9450: Add pca9452 support regulator: pca9450: Use dev_err_probe() to simplify code regulator: pca9450: add enable_value for all bucks regulator: bd96801: Add ERRB IRQ

regulator: core: Add missing newline character

2025-01-22T14:29:29Z

dev_err_probe() error messages need newline character. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Alexander Stein Link: https://patch.msgid.link/20250122072019.1926093-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown

regulator: TPS6287X: Use min/max uV to get VRANGE

2025-01-21T15:21:56Z

Changing voltage might ignore slew rate and cause a current surge. With current implementation the driver will get the regulator to change the voltage range used during run time. According to communication I have had with Texas Instruments, this is not intended, since the Dynamic Voltage Scaling in the hardware is only designed to work within a voltage range. The current implementation will therefore ignore the slew rate that is defined in devicetree when the voltage range is changed during use. The current implementation will always select a voltage in the most accurate range that can reach that voltage even though multiple ranges are able to reach that voltage. There are 4 Voltage ranges with the following reach: 0b00: 0.4-0.71875V (1.25mV step size) 0b01: 0.4-1.0375V (2.5mV) 0b10: 0.4-1.675V (5mV) 0b11: 0.8-3.3V (10mV) This in practice means that a change from below to above 0.71875V will use the smallest range(0b00) for the values below and the second smallest range(0b01) for the voltages above (Up to 1.675V). I have timed how long it takes to go from below 0.71875V to above. The increase was 100mV which, with the slew rate set to 1250µV/µs. This in theory should take 80µs to do. With the current implementation, it takes 10µs on my hardware. Doing the same test with the slew rate set to 5000µV/µs, which should take 20µs, also only takes 10µs to do on my hardware. Not only is this not in line with the technical specification for the regulator. It also causes a current surge. Which when calculating the output current, as described in the technical specification, compared to what I could observe on my hardware the real output is ~1A higher (~1.2A) than what I calculated it to be(~0.2A). I tested also transitioning from a bigger to a smaller range, and the results were the same. Instead, let's limit the voltage range to a single one, which is in line with the intended use of the regulator. This is done by looking up the minimum and maximum requested voltage specified in devicetree. Signed-off-by: Jonas Andreasson Link: https://patch.msgid.link/20250121-tps-fix-v2-1-50cc4d0f1635@axis.com Signed-off-by: Mark Brown

regulator: Add support for power budget

2025-01-17T17:48:54Z

Introduce power budget management for the regulator device. Enable tracking of available power capacity by providing helpers to request and release power budget allocations. Signed-off-by: Kory Maincent Link: https://patch.msgid.link/20250115-feature_regulator_pw_budget-v2-1-0a44b949e6bc@bootlin.com Signed-off-by: Mark Brown

regulator: core: Resolve supply using of_node from regulator_config

2025-01-09T16:52:30Z

Previously, the regulator core resolved its supply only from the parent device or its children, ignoring the of_node specified in the regulator_config structure. This behavior causes issues in scenarios where multiple regulator devices are registered for components described as children of a controller, each with their own specific regulator supply. For instance, in a PSE controller with multiple PIs (Power Interfaces), each PI may have a distinct regulator supply. However, the regulator core would incorrectly use the PSE controller node or its first child to look up the regulator supply, rather than the node specified by the regulator_config->of_node for the PI. This update modifies the behavior to prioritize the of_node in regulator_config for resolving the supply. This ensures correct resolution of the power supply for each device. If no supply is found in the provided of_node, the core falls back to searching within the parent device as before. Reviewed-by: Oleksij Rempel Signed-off-by: Kory Maincent Link: https://patch.msgid.link/20250109-b4-feature_poe_arrange-v2-13-55ded947b510@bootlin.com Signed-off-by: Mark Brown

regulator: of: Implement the unwind path of of_regulator_match()

2025-01-06T13:08:49Z

of_regulator_match() does not release the OF node reference in the error path, resulting in an OF node leak. Therefore, call of_node_put() on the obtained nodes before returning the EINVAL error. Since it is possible that some drivers call this function and do not exit on failure, such as s2mps11_pmic_driver, clear the init_data and of_node in the error path. This was reported by an experimental verification tool that I am developing. As I do not have access to actual devices nor the QEMU board configuration to test drivers that call this function, no runtime test was able to be performed. Fixes: 1c8fa58f4750 ("regulator: Add generic DT parsing for regulators") Signed-off-by: Joe Hattori Link: https://patch.msgid.link/20250104080453.2153592-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Mark Brown

regulator: rename regulator-uv-survival-time-ms according to DT binding

2024-12-19T11:15:24Z

The regulator bindings don't document regulator-uv-survival-time-ms, but the more descriptive regulator-uv-less-critical-window-ms instead. Looking back at v3[1] and v4[2] of the series adding the support, the property was indeed renamed between these patch series, but unfortunately the rename only made it into the DT bindings with the driver code still using the old name. Let's therefore rename the property in the driver code to follow suit. This will break backwards compatibility, but there are no upstream device trees using the property and we never documented the old name of the property anyway. ¯\_(ツ)_/¯" [1]: https://lore.kernel.org/all/20231025084614.3092295-7-o.rempel@pengutronix.de/ [2]: https://lore.kernel.org/all/20231026144824.4065145-5-o.rempel@pengutronix.de/ Signed-off-by: Ahmad Fatoum Link: https://patch.msgid.link/20241218-regulator-uv-survival-time-ms-rename-v1-1-6cac9c3c75da@pengutronix.de Signed-off-by: Mark Brown

regulator: tps65219: Remove debugging helper function

2024-12-17T21:20:01Z

This helper function is primarily used by developers for debugging & is not a standard feature included in other PMIC drivers. The purpose of debugging function is to check if rdev is determine if the regulator has been registered prior to requesting a threaded irq. This case is already handled with the ISERR(rdev) check because the error code is returned. Signed-off-by: Shree Ramamoorthy Link: https://patch.msgid.link/20241217204526.1010989-5-s-ramamoorthy@ti.com Signed-off-by: Mark Brown

regulator: tps65219: Remove MODULE_ALIAS

2024-12-17T21:20:00Z

Remove MODULE_ALIAS because the same module alias is already generated by MODULE_DEVICE_TABLE. Signed-off-by: Shree Ramamoorthy Link: https://patch.msgid.link/20241217204526.1010989-4-s-ramamoorthy@ti.com Signed-off-by: Mark Brown