The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used.
Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably.
Changes in v4: - Move the registers unlock in the probe instead of a custom regmap write operation. - Link to v3: https://lore.kernel.org/r/20251112-fix_tps65219-v3-0-e49bab4c01ce@bootlin.co...
Changes in v3: - Remove an unused variable - Link to v2: https://lore.kernel.org/r/20251106-fix_tps65219-v2-0-a7d608c4272f@bootlin.co...
Changes in v2: - Setup a custom regmap_bus only for the TPS65214 instead of checking the chip_id every time reg_write is called. - Add the am335x-bonegreen-eco devicetree change in the same patch series.
Signed-off-by: Kory Maincent (TI.com) kory.maincent@bootlin.com --- Kory Maincent (TI.com) (2): mfd: tps65219: Implement LOCK register handling for TPS65214 ARM: dts: am335x-bonegreen-eco: Enable 1GHz OPP by increasing vdd_mpu voltage
arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts | 2 +- drivers/mfd/tps65219.c | 7 +++++++ include/linux/mfd/tps65219.h | 2 ++ 3 files changed, 10 insertions(+), 1 deletion(-) --- base-commit: 1c353dc8d962de652bc7ad2ba2e63f553331391c change-id: 20251106-fix_tps65219-dd62141d22cf
Best regards,
The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently.
This approach is justified because: - Register locking is very uncommon in typical system operation - No code path is expected to lock the registers during runtime - Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently
Cc: stable@vger.kernel.org Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Signed-off-by: Kory Maincent (TI.com) kory.maincent@bootlin.com --- Changes in v4: - Move the registers unlock in the probe instead of a custom regmap write operation.
Changes in v3: - Removed unused variable.
Changes in v2: - Setup a custom regmap_bus only for the TPS65214 instead of checking the chip_id every time reg_write is called. --- drivers/mfd/tps65219.c | 7 +++++++ include/linux/mfd/tps65219.h | 2 ++ 2 files changed, 9 insertions(+)
diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c index 65a952555218d..f1115c5585545 100644 --- a/drivers/mfd/tps65219.c +++ b/drivers/mfd/tps65219.c @@ -498,6 +498,13 @@ static int tps65219_probe(struct i2c_client *client) return ret; }
+ if (chip_id == TPS65214) { + ret = i2c_smbus_write_byte_data(client, TPS65214_REG_LOCK, + TPS65214_LOCK_ACCESS_CMD); + if (ret) + return ret; + } + ret = devm_regmap_add_irq_chip(tps->dev, tps->regmap, client->irq, IRQF_ONESHOT, 0, pmic->irq_chip, &tps->irq_data); diff --git a/include/linux/mfd/tps65219.h b/include/linux/mfd/tps65219.h index 55234e771ba73..3abf937191d0c 100644 --- a/include/linux/mfd/tps65219.h +++ b/include/linux/mfd/tps65219.h @@ -149,6 +149,8 @@ enum pmic_id { #define TPS65215_ENABLE_LDO2_EN_MASK BIT(5) #define TPS65214_ENABLE_LDO1_EN_MASK BIT(5) #define TPS65219_ENABLE_LDO4_EN_MASK BIT(6) +/* Register Unlock */ +#define TPS65214_LOCK_ACCESS_CMD 0x5a /* power ON-OFF sequence slot */ #define TPS65219_BUCKS_LDOS_SEQUENCE_OFF_SLOT_MASK GENMASK(3, 0) #define TPS65219_BUCKS_LDOS_SEQUENCE_ON_SLOT_MASK GENMASK(7, 4)
On 11/12/25 9:14 AM, Kory Maincent (TI.com) wrote:
The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently.
This approach is justified because:
- Register locking is very uncommon in typical system operation
- No code path is expected to lock the registers during runtime
Any other entity in the system that could re-lock these registers? How about low power modes or other PM handling?
- Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently
Cc: stable@vger.kernel.org Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Signed-off-by: Kory Maincent (TI.com) kory.maincent@bootlin.com
Changes in v4:
- Move the registers unlock in the probe instead of a custom regmap write operation.
Changes in v3:
- Removed unused variable.
Changes in v2:
- Setup a custom regmap_bus only for the TPS65214 instead of checking the chip_id every time reg_write is called.
drivers/mfd/tps65219.c | 7 +++++++ include/linux/mfd/tps65219.h | 2 ++ 2 files changed, 9 insertions(+)
diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c index 65a952555218d..f1115c5585545 100644 --- a/drivers/mfd/tps65219.c +++ b/drivers/mfd/tps65219.c @@ -498,6 +498,13 @@ static int tps65219_probe(struct i2c_client *client) return ret; }
- if (chip_id == TPS65214) {
ret = i2c_smbus_write_byte_data(client, TPS65214_REG_LOCK,TPS65214_LOCK_ACCESS_CMD);if (ret)return ret;
Might be good to print out some error message here, otherwise LGTM,
Reviewed-by: Andrew Davis afd@ti.com
- }
- ret = devm_regmap_add_irq_chip(tps->dev, tps->regmap, client->irq, IRQF_ONESHOT, 0, pmic->irq_chip, &tps->irq_data);
diff --git a/include/linux/mfd/tps65219.h b/include/linux/mfd/tps65219.h index 55234e771ba73..3abf937191d0c 100644 --- a/include/linux/mfd/tps65219.h +++ b/include/linux/mfd/tps65219.h @@ -149,6 +149,8 @@ enum pmic_id { #define TPS65215_ENABLE_LDO2_EN_MASK BIT(5) #define TPS65214_ENABLE_LDO1_EN_MASK BIT(5) #define TPS65219_ENABLE_LDO4_EN_MASK BIT(6) +/* Register Unlock */ +#define TPS65214_LOCK_ACCESS_CMD 0x5a /* power ON-OFF sequence slot */ #define TPS65219_BUCKS_LDOS_SEQUENCE_OFF_SLOT_MASK GENMASK(3, 0) #define TPS65219_BUCKS_LDOS_SEQUENCE_ON_SLOT_MASK GENMASK(7, 4)
On Wed, 12 Nov 2025 13:03:22 -0600 Andrew Davis afd@ti.com wrote:
On 11/12/25 9:14 AM, Kory Maincent (TI.com) wrote:
The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently.
This approach is justified because:
- Register locking is very uncommon in typical system operation
- No code path is expected to lock the registers during runtime
Any other entity in the system that could re-lock these registers? How about low power modes or other PM handling?
No there is no reason to re-lock these registers. It will be locked again only if the PMIC is reset. In any case, if one case appears that needs to lock these register (even if I think it is unlikely) we could come back to the regmap custom write design.
Regards,
On Tue, 09 Dec 2025, Kory Maincent wrote:
On Mon, 08 Dec 2025 19:09:45 -0800 Kevin Hilman khilman@baylibre.com wrote:
Kory Maincent kory.maincent@bootlin.com writes:
On Wed, 12 Nov 2025 16:14:19 +0100 "Kory Maincent (TI.com)" kory.maincent@bootlin.com wrote:
The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used.
Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably.
Hello,
What is the status on this series? Is there anything that could prevent it from being merged?
Nothing technical. I'll start queuing things up after the merge window closes and -rc1 (or maybe -rc2) is out.
Ok, thank you!
Andrew made a suggestion on the MFD patch, so I unmarked it for review.
On Wed, 12 Nov 2025 16:14:19 +0100 "Kory Maincent (TI.com)" kory.maincent@bootlin.com wrote:
The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used.
Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably.
Hello,
What is the status on this series? Is there anything that could prevent it from being merged?
Regards,
Kory Maincent kory.maincent@bootlin.com writes:
On Wed, 12 Nov 2025 16:14:19 +0100 "Kory Maincent (TI.com)" kory.maincent@bootlin.com wrote:
The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used.
Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably.
Hello,
What is the status on this series? Is there anything that could prevent it from being merged?
Nothing technical. I'll start queuing things up after the merge window closes and -rc1 (or maybe -rc2) is out.
Kevin
On Mon, 08 Dec 2025 19:09:45 -0800 Kevin Hilman khilman@baylibre.com wrote:
Kory Maincent kory.maincent@bootlin.com writes:
On Wed, 12 Nov 2025 16:14:19 +0100 "Kory Maincent (TI.com)" kory.maincent@bootlin.com wrote:
The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used.
Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably.
Hello,
What is the status on this series? Is there anything that could prevent it from being merged?
Nothing technical. I'll start queuing things up after the merge window closes and -rc1 (or maybe -rc2) is out.
Ok, thank you!
Regards,
linux-stable-mirror@lists.linaro.org
-
Andrew Davis -
Kevin Hilman -
Kory Maincent -
Kory Maincent (TI.com)
-
Lee Jones