From nobody Mon Feb 9 04:45:44 2026 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E34B62BEFFE; Wed, 12 Nov 2025 15:14:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762960478; cv=none; b=gIaELSmD2tt2V+uElh+uuIM2eCwzKMEbKCOmbZp4mUjBRgBqsSnSmsHTitUYfAnJRoZripkAp66AuZECcakkFjeZ3Pv6JCrt1I0c9GDU25y7rPY2347vU649bN1a/3H97Zmi6o6+UNOHSUxo0Mt7ls2Pzm2ENYupQcSD1tbY7UQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762960478; c=relaxed/simple; bh=Lr8R7aXFYbmoGF//QddzR38UzaejFGtwDhCgL5UqziU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=UMC2s1nQrXn94wFzZ++MfgHAXJXhcfVl/6N8eH6R9OO9ns9975jjL670IzbquOtD7pUxtMb+DPSAeQtVtwSxxXoRdy/FmwkmMnVuliK4ki6q72HJy2ketR0RNKk8ClBs5hrS8ii/scJ2+tMiuAPLDu7FnNeeKQYzZBLhUM7gkk8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=1R5jmhn0; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="1R5jmhn0" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id BE7B3C0F562; Wed, 12 Nov 2025 15:14:12 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 63D8C6070B; Wed, 12 Nov 2025 15:14:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 2C672102F1973; Wed, 12 Nov 2025 16:14:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1762960473; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Uh+2n9sRKzemxl0qpoJ4RyEt1okO5dZPU6Yl7d9Jp5U=; b=1R5jmhn0gHwnUDzfOtxc0D2n0upCBDDNX0Q+w9gDssLbUxXMDx2pIlwiLekmIwyDaZ1yeP QFuSZteDdt0nptr2PhXCtcS4s6nfgLlQTAhaaU7sUbwWTZ+HdOoxwSZYzgEdn+Bs92a2+N SkUIiGMFbZSh4gHsqVc0uvzMSkGoNJ01If1b8Yh8ouHqEt/DyhsmnauDhkttwxJVxnX9a+ lhx4uTDo/uJx352SJ55RFDtndZ8jxdWMuzT/BpPtIrNQmYoNhIDvqWMEbEIfUqwR5mS33g QjsW0zXiyHIwLRYocTYoOPIrTlRytbuyJrMWGFvIomavqHnxyYZFB4bQD1kr/g== From: "Kory Maincent (TI.com)" Date: Wed, 12 Nov 2025 16:14:20 +0100 Subject: [PATCH v4 1/2] mfd: tps65219: Implement LOCK register handling for TPS65214 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20251112-fix_tps65219-v4-1-696a0f55d5d8@bootlin.com> References: <20251112-fix_tps65219-v4-0-696a0f55d5d8@bootlin.com> In-Reply-To: <20251112-fix_tps65219-v4-0-696a0f55d5d8@bootlin.com> To: Aaro Koskinen , Andreas Kemnade , Kevin Hilman , Roger Quadros , Tony Lindgren , Lee Jones , Shree Ramamoorthy , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: Andrew Davis , Bajjuri Praneeth , Thomas Petazzoni , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, "Kory Maincent (TI.com)" , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Last-TLS-Session-Version: TLSv1.3 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) Reviewed-by: Andrew Davis --- 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; } =20 + if (chip_id =3D=3D TPS65214) { + ret =3D i2c_smbus_write_byte_data(client, TPS65214_REG_LOCK, + TPS65214_LOCK_ACCESS_CMD); + if (ret) + return ret; + } + ret =3D 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) --=20 2.43.0 From nobody Mon Feb 9 04:45:44 2026 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 469FF33E372; Wed, 12 Nov 2025 15:14:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762960480; cv=none; b=oznvNcgqLjXFFBZYSzBbcEEmcVmQh5IR+jp2NwZpoe2Mmh7c96/JADKr4/Qx7ILzEELpBgKjCTG0pwrBpAzB4MNynSRXrP8WshWPRXjrOYYZZP+id536DDwyIFRw7gznL5ZAjrlII2pMElFrPRHPecj6SeXOMUNx52T4x3mG4mY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762960480; c=relaxed/simple; bh=hMJzIR4lZEcblXjR0I9hzQzbHScfcP0F6rIKaU7ffA4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=R4kWchd6GjLlD+s/RPtuVL5ee4da9e/UGnndE23a+IWsHg5QCwjMITXkPuo7vUJ+XofRFflDnwlA4WZbNND2VTKrWNjVAvgm+mtMSx7SwRC8STKSWiOkFdgU7j1IFpgA75bgyD1SzcOWE89+GORaY5aJcmVLAspz2Ljr/w0v4NQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=MRUJtnmY; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="MRUJtnmY" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id BE4D64E4166C; Wed, 12 Nov 2025 15:14:36 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 8FAC560710; Wed, 12 Nov 2025 15:14:36 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id A9A4F102F1A2B; Wed, 12 Nov 2025 16:14:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1762960475; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Hi/5WmyJVI8+IqSzvn7iNXPzQu9SoH12tl/3+e8BE4I=; b=MRUJtnmYyUioxknI08eCMhkw5KitvAMdyhFReE5y3ycgW3b8R8zwNXzJGidOWAcoDwmGp2 4LKspJ/prvz2mwNBddvkgxg4ucfmuQJJEShP0ZVEpRLROP85YtJYqFOp/SWBiR0/7dI+X/ Z5TU/LsW4RLUAxJeYAElocwS4p8p7y2aFXJjmKKwIglWZ3w+gksK67qt9UU34bi0FrtdaP sB7QO3fPrEw6W0RNPcf6iAOo/NOsOF8pjube/ef5YHPgmjIPKwGrAGsaS/twIyr8mqE8sY xQll78eaoWFuWPdSQYamn0EtdRbMI4K7Pf3bYk3q7h/OCVoL6hCXmL5Z0hcu+g== From: "Kory Maincent (TI.com)" Date: Wed, 12 Nov 2025 16:14:21 +0100 Subject: [PATCH v4 2/2] ARM: dts: am335x-bonegreen-eco: Enable 1GHz OPP by increasing vdd_mpu voltage Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20251112-fix_tps65219-v4-2-696a0f55d5d8@bootlin.com> References: <20251112-fix_tps65219-v4-0-696a0f55d5d8@bootlin.com> In-Reply-To: <20251112-fix_tps65219-v4-0-696a0f55d5d8@bootlin.com> To: Aaro Koskinen , Andreas Kemnade , Kevin Hilman , Roger Quadros , Tony Lindgren , Lee Jones , Shree Ramamoorthy , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: Andrew Davis , Bajjuri Praneeth , Thomas Petazzoni , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, "Kory Maincent (TI.com)" X-Mailer: b4 0.14.3 X-Last-TLS-Session-Version: TLSv1.3 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. With the recent TPS65219 PMIC driver fixes that properly implement the LOCK register handling, voltage transitions now work reliably. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used. Reviewed-by: Shree Ramamoorthy Signed-off-by: Kory Maincent (TI.com) --- arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts b/arch/arm/= boot/dts/ti/omap/am335x-bonegreen-eco.dts index d21118cdb6c2c..f00abfdd2cbd4 100644 --- a/arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts +++ b/arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts @@ -63,7 +63,7 @@ regulators { buck1: buck1 { regulator-name =3D "vdd_mpu"; regulator-min-microvolt =3D <925000>; - regulator-max-microvolt =3D <1298500>; + regulator-max-microvolt =3D <1351500>; regulator-boot-on; regulator-always-on; }; --=20 2.43.0