| Message ID | 20260720213832.3763-1-andre.przywara@arm.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-24552-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10]) by mxe881.netcup.net (Postfix) with ESMTPS id 9D4141C2B79 for <noreply@patchwork.local>; Mon, 20 Jul 2026 23:43:00 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=arm.com; spf=pass (sender IP is 172.234.253.10) smtp.mailfrom=linux-sunxi+bounces-24552-noreply=patchwork.local@lists.linux.dev smtp.helo=sea.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.234.253.10 as permitted sender) client-ip=172.234.253.10; envelope-from=linux-sunxi+bounces-24552-noreply=patchwork.local@lists.linux.dev; helo=sea.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id DA609304569F for <noreply@patchwork.local>; Mon, 20 Jul 2026 21:42:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C3A1A355F43; Mon, 20 Jul 2026 21:42:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="l8iAgLJz" X-Original-To: linux-sunxi@lists.linux.dev Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BC6473B95EC for <linux-sunxi@lists.linux.dev>; Mon, 20 Jul 2026 21:42:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784583744; cv=none; b=R1jxwiqBNHYs1yY+KVL7gHKKNZrkg6QSWvbbINAK2fO1LbiyhmEymKtp1tO28NsHoItH3V9BjqXw31rRiy9Mnc7rr2jR5+GcA98PcvJ0O0LhyWwIUvwPmMazxYHNfvcCT3GKEJLjTxT3cIFLLFC9gqVbT+RSI5Hh+eYf5MmKYTk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784583744; c=relaxed/simple; bh=7GPCEpWSp6hdvoiZp/dWDlRlQZkpNncKgtqSVs5WpVQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HTeIV2gkjayzq44FPt/qUy1o08Tb9xv48PVxHXwLBCPfcrYXloDXGD9/Kq4KnD8vVfQT7LWtXs0TgwpKkikg73NJ7Hkcg1wcDAPDR/DGVOouMyZHsfzKUbVYS6LExx6pq5m67imRs1gXS0PvloIJcbZpZpSDWFipU1wdgIMvsE4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=l8iAgLJz; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A3366143D; Mon, 20 Jul 2026 14:42:17 -0700 (PDT) Received: from ryzen.fritz.box (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9DC563F66F; Mon, 20 Jul 2026 14:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1784583741; bh=7GPCEpWSp6hdvoiZp/dWDlRlQZkpNncKgtqSVs5WpVQ=; h=From:To:Cc:Subject:Date:From; b=l8iAgLJzV7Gh3mwE/JMxyp/TMqv1GUgNiObXadU2jzw1/5vwKGwxnPdQewXZ9dYDu WjFH5fDtXjJQN8vlY6tcX3U9ypgFZk1wmHI8SjrQSnCnB7AGmkgjh6OmhIOtWeLD24 /eUxAXDjbLj0L+RW23StDNOoNAUYlriflwcAUjpE= From: Andre Przywara <andre.przywara@arm.com> To: Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley <conor+dt@kernel.org>, Chen-Yu Tsai <wens@kernel.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org> Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH] arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC Date: Mon, 20 Jul 2026 23:38:32 +0200 Message-ID: <20260720213832.3763-1-andre.przywara@arm.com> X-Mailer: git-send-email 2.46.4 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspamd-worker-8404 X-Spamd-Result: default: False [-0.66 / 15.00]; BAYES_HAM(-5.50)[100.00%]; RBL_SENDERSCORE(2.00)[172.234.253.10:from]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; MAILLIST(-0.15)[generic]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; FROM_HAS_DN(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; PRECEDENCE_BULK(0.00)[]; TAGGED_RCPT(0.00)[dt]; DBL_BLOCKED_OPENRESOLVER(0.00)[arm.com:email,arm.com:dkim,sea.lore.kernel.org:rdns,sea.lore.kernel.org:helo]; R_DKIM_ALLOW(0.00)[arm.com:s=foss]; RCVD_COUNT_FIVE(0.00)[6]; FROM_NEQ_ENVFROM(0.00)[andre.przywara@arm.com,linux-sunxi@lists.linux.dev]; TAGGED_FROM(0.00)[bounces-24552-noreply=patchwork.local]; DMARC_POLICY_ALLOW(0.00)[arm.com,none]; RCPT_COUNT_SEVEN(0.00)[10]; DKIM_TRACE(0.00)[arm.com:+]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:172.234.253.10]; FORGED_SENDER_MAILLIST(0.00)[]; FREEMAIL_TO(0.00)[kernel.org,gmail.com,sholland.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:63949, ipnet:172.234.224.0/19, country:SG]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 9D4141C2B79 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC
|
|
Commit Message
Andre Przywara
July 20, 2026, 9:38 p.m. UTC
On the X96QPro+ TV box, the eMMC wasn't working properly: the chip would
be detected, but most requests failed, leaving it unusable. Some
"solutions" were circulating downstream, one "popular" one is severely
limiting the clock frequency, with a drastic performance impact.
Instead slightly bumping the I/O voltage on PortC from the canonical
1.8V to 1.9V seemed to do the trick: the eMMC now works and reaches the
expected 120MB/s performance.
Adjust the respective regulator voltage in the .dts to enable eMMC
operation on that device.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,
I am not super happy with this patch, but it seems to be a pragmatic and
the least hacky solution I have seen.
Cheers,
Andre
arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Bumping the eMMC IO regulator (`reg_cldo1`) to 1.9V inadvertently misconfigures the SoC's IO bank (Port C) into 3.3V power mode instead of 1.8V mode, creating a logic threshold mismatch. -- --- Patch [1]: [PATCH] arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC --- commit e4c261c388d6e406babdf0d56ac61d104d537230 Author: Andre Przywara <andre.przywara@arm.com> Date: Mon Jul 20 21:38:32 2026 +0000 arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC This commit changes the eMMC IO regulator voltage on PortC from 1.8V to 1.9V for the X96QPro+ device. The goal is to improve eMMC stability and performance without drastically limiting the clock frequency. > diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts > --- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts > +++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts [ ... ] > @@ -194,8 +194,8 @@ reg_bldo4: bldo4 { > > reg_cldo1: cldo1 { > regulator-always-on; > - regulator-min-microvolt = <1800000>; > - regulator-max-microvolt = <1800000>; > + regulator-min-microvolt = <1900000>; > + regulator-max-microvolt = <1900000>; [Severity: High] Does bumping this regulator to 1.9V inadvertently force the SoC's IO bank (Port C) into 3.3V power mode? Looking at sunxi_pinctrl_set_io_bias_cfg() in drivers/pinctrl/sunxi/pinctrl-sunxi.c, the driver uses a strict check when evaluating the voltage: case BIAS_VOLTAGE_PIO_POW_MODE_SEL: val = uV <= 1800000 ? 1 : 0; Since 1900000 is greater than 1800000, this evaluates to 0 and clears the PIO_POW_MOD_SEL register bit, incorrectly configuring the IO bank for 3.3V mode while being powered at 1.9V. Could this mismatch alter input receiver thresholds and drive strengths, potentially causing signal integrity issues or long-term hardware degradation? > regulator-name = "vcc-codec-sd"; > };
On Mon, 20 Jul 2026 21:50:35 +0000 sashiko-bot@kernel.org wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [High] Bumping the eMMC IO regulator (`reg_cldo1`) to 1.9V inadvertently misconfigures the SoC's IO bank (Port C) into 3.3V power mode instead of 1.8V mode, creating a logic threshold mismatch. Huh, that's interesting, but might actually point to the real root cause: it seems like the meaning of the bits in the withstand register is inverted on the A523: 0 encodes 1.8V, a 1 encodes 3.3V. But that's the opposite of the H6 definition, which we use in the kernel for the A523 as well. Which means they were wrongly programmed before, but now the wrong voltage selection turns out to trigger the really correct setting. So I will try playing around with those registers instead. Cheers, Andre. > -- > > --- Patch [1]: [PATCH] arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC --- > commit e4c261c388d6e406babdf0d56ac61d104d537230 > Author: Andre Przywara <andre.przywara@arm.com> > Date: Mon Jul 20 21:38:32 2026 +0000 > > arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC > > This commit changes the eMMC IO regulator voltage on PortC from 1.8V to 1.9V > for the X96QPro+ device. The goal is to improve eMMC stability and performance > without drastically limiting the clock frequency. > > > diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts > > --- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts > > +++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts > [ ... ] > > @@ -194,8 +194,8 @@ reg_bldo4: bldo4 { > > > > reg_cldo1: cldo1 { > > regulator-always-on; > > - regulator-min-microvolt = <1800000>; > > - regulator-max-microvolt = <1800000>; > > + regulator-min-microvolt = <1900000>; > > + regulator-max-microvolt = <1900000>; > > [Severity: High] > Does bumping this regulator to 1.9V inadvertently force the SoC's IO bank > (Port C) into 3.3V power mode? > > Looking at sunxi_pinctrl_set_io_bias_cfg() in > drivers/pinctrl/sunxi/pinctrl-sunxi.c, the driver uses a strict check when > evaluating the voltage: > > case BIAS_VOLTAGE_PIO_POW_MODE_SEL: > val = uV <= 1800000 ? 1 : 0; > > Since 1900000 is greater than 1800000, this evaluates to 0 and clears the > PIO_POW_MOD_SEL register bit, incorrectly configuring the IO bank for 3.3V > mode while being powered at 1.9V. > > Could this mismatch alter input receiver thresholds and drive strengths, > potentially causing signal integrity issues or long-term hardware > degradation? > > > regulator-name = "vcc-codec-sd"; > > }; >
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts index a96927fbdadd5..5636e95312218 100644 --- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts +++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts @@ -194,8 +194,8 @@ reg_bldo4: bldo4 { reg_cldo1: cldo1 { regulator-always-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; + regulator-min-microvolt = <1900000>; + regulator-max-microvolt = <1900000>; regulator-name = "vcc-codec-sd"; };