From nobody Fri Dec 19 15:51:50 2025 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 6BEE02DAFC7; Thu, 18 Dec 2025 15:06:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766070403; cv=none; b=k8ZFaTPNj5diaRPpJwTXodnEXTfpY8fSQhDKxhK+Wh96UxxREpk4bbY4lLjdPAnwQwl4XO4dH9YInZKMyAVDO6yeLeb7lCwSIbUsOBKRVj0RXEnD5jKt6p7nNI6zGuqaPfbIMByLIuyOGXkyjUbAJIgtskWBwOviUK0ZUix4cfY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766070403; c=relaxed/simple; bh=sgTSisfv8DUnh29tJVOHt3YNMJ+GeRYBpJQEIu9rFyQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=od6Yzl7Mbj/JHa+RKYGXBLy8b49HS0UlYYLXCCEUK8SL9PzlnczynWOiTxVtEjq2NEG1v4txzBb2gUfUlyyoDLvz+Vux7JXVHYbb18s9p7oUdFjtEQcc49qYMg+jx/PVFwfoJvDWCC/q3NKRiQhcKCvTFqCpCcYwddveIORPdTk= 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=jiKTos7T; arc=none smtp.client-ip=185.246.84.56 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="jiKTos7T" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id E1A001A22D2; Thu, 18 Dec 2025 15:06:39 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id B5DE9606B6; Thu, 18 Dec 2025 15:06:39 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id D5AB9102F0B2B; Thu, 18 Dec 2025 16:06:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1766070398; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=uoYxhLVSSc04WNfQajT43rAD+zIsLXpdX+ZhTFAHmW0=; b=jiKTos7TAqio2zKYxOBqDVrnkBHPD+VIWi4DNKFk2MshBCs0aH2LROkBi9rCsnjmjyF0P7 WeZGtD6vw+KXGhLeFPhvuKH8t9plEM7en5UnU3XiimUvAYK0K0mcyxuzyraRe3KAJkAHSP uKU8nTSBehwE7gmDUogOmxzxITH5C1iwfrDf9moAU424e4JM4/oo/EoqfsaZHW9hSe3xjo wFN19Ha38e9K9K4F2DXprxDXDjkoN113/XTTYKhOwC258hUPxOc6SoHVpCHzJQl1wF5VUR 9ZYVXP/ZZu+TKFHDCYllrtkZakL5q4bdF3FhSj+4i76NyF44Gljh39VMS8skQQ== From: "Kory Maincent (TI.com)" Date: Thu, 18 Dec 2025 16:06:28 +0100 Subject: [PATCH v5 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: <20251218-fix_tps65219-v5-1-8bb511417f3a@bootlin.com> References: <20251218-fix_tps65219-v5-0-8bb511417f3a@bootlin.com> In-Reply-To: <20251218-fix_tps65219-v5-0-8bb511417f3a@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") Reviewed-by: Andrew Davis Signed-off-by: Kory Maincent (TI.com) --- Changes in v5: - Add error message. 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 | 9 +++++++++ include/linux/mfd/tps65219.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c index 65a952555218d..7275dcdb7c44f 100644 --- a/drivers/mfd/tps65219.c +++ b/drivers/mfd/tps65219.c @@ -498,6 +498,15 @@ 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) { + dev_err(tps->dev, "Failed to unlock registers %d\n", 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 Fri Dec 19 15:51:50 2025 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 C25BF2D8768 for ; Thu, 18 Dec 2025 15:06:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766070404; cv=none; b=IoQ0ysF1AZchuXZi8gtvRlkQSRg4ZszGxiEGVia98DzG9n/qyWkrZQfVQWUo2M4rOUMmFtsfrYcz4U3rdYTMnEJHk0huT81t7T+eytFMvnzPXRH54AwjHkYaLPxHIBji5/y2KusDXZI579NOrtATrroJnJiZsuDF4OfReWxLBaw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766070404; c=relaxed/simple; bh=hMJzIR4lZEcblXjR0I9hzQzbHScfcP0F6rIKaU7ffA4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=nm4AgCOeYLonP0Adxv204pFW53VmF7LewGfmsC2Vnm6LmZJ/LE4WkYOfXMARx8L7bx4YXidJ0gN4B1ftCfmkos0d/0cAAkXfvSM+uqnzRJKi05AUKG2ef4lJhdz9S6FHZI5s7wnHLZXbjJRkE5vWSrXqg5Z6jKrZMoKOyTySGBk= 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=rgh15m4x; arc=none smtp.client-ip=185.246.84.56 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="rgh15m4x" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 3B3721A22D3; Thu, 18 Dec 2025 15:06:41 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 11C36606B6; Thu, 18 Dec 2025 15:06:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id BBFB3102F0B18; Thu, 18 Dec 2025 16:06:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1766070399; 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=rgh15m4xrjdIMVI0OpUDJGP9xCKirdKw8s6/O9VusHO7NtDH/rLkyJYhewRTOCICFjBBfX f9WBGnttKRWzuPHOav4mMqdjbJ5xZwu1e+z4xorEK1+fQqjADFl1JYFUfm16rman098k4u I8an/WyOrUOJH5iN++SDfZoGeh6btRFPUt6aWgAz64wKqbiky1nkF7bgNH6Sdo8yjODFED zSB1N34quusI+YNfEIGGG1VIORlWkIaXA3S6mipw86Ya2fvZS0BhNmezFw8NmmAcnp/nqU 8zxtYdpjK0h5z7ZOJL2cWHs9tAm/YgsZUv1w9qVnYKAYm4B5Wp0xTa9shvqxBQ== From: "Kory Maincent (TI.com)" Date: Thu, 18 Dec 2025 16:06:29 +0100 Subject: [PATCH v5 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: <20251218-fix_tps65219-v5-2-8bb511417f3a@bootlin.com> References: <20251218-fix_tps65219-v5-0-8bb511417f3a@bootlin.com> In-Reply-To: <20251218-fix_tps65219-v5-0-8bb511417f3a@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