From: Andre Przywara <andre.przywara@arm.com>
To: Vinicius Pedrosa <vinicius.eduardo.pedrosa@gmail.com>
Cc: Linus Walleij <linusw@kernel.org>, Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Jerome Brunet <jbrunet@baylibre.com>, Yixun Lan <dlan@gentoo.org>,
Enzo Adriano <enzo.adriano.code@gmail.com>,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFT] pinctrl: sunxi: Fix A733 withstand programming
Date: Wed, 14 Oct 2026 00:13:34 +0200 [thread overview]
Message-ID: <20261014001334.54dcf0b5@ryzen.lan> (raw)
In-Reply-To: <20261013172427.328177-1-vinicius.eduardo.pedrosa@gmail.com>
On Tue, 13 Oct 2026 14:23:38 -0300
Vinicius Pedrosa <vinicius.eduardo.pedrosa@gmail.com> wrote:
Hi Vinicius,
thanks for having a look and testing it!
> Thanks for the RFT. I found two things when checking it against the A733
> manual and my Cubie A7Z.
>
> PB is an exception to bank * 2: its VCC-IO field is at bits 25:24, while
> bits 3:2 are reserved.
So PortB has no supply of its own, instead it's always supplied by
VCC-IO. That was even more common on older SoCs, with also PortH and
PortF being supplied by that. Which somewhat means that this is broken
there as well?
> With the board's SEL value (0x01155550), a 3.3 V
What do you mean with "the board's SEL value"? That's not the SoC reset
value, is it? So who programs that value, and why?
> request produces 0x01155558, leaving VCC-IO untouched.
... naturally, because nothing in mainline sets VCC-IO, which is beyond
the SoC's GPIO bank offset.
> I also think we should preserve AUTO (01). On my A7Z with vendor 5.15,
> PF=10 resulted in 22 SDR104 read timeouts and no rootfs, while PF=01 and
> PF=11 reached login.
So this means you hacked the register in the vendor kernel, for the
sake of an experiment? And I guess this just means that the vendor
kernel uses UHS, and uses register 0x70 to switch PortF to 1.8V? So you
need either auto or 1.8V for it to work, the same problem we hit with
PortC on the A523.
> This was one run per setting with one card, not a
> mainline before/after test. In my mainline setup, MMC0 already requests PF
> with a fixed 3.3 V supply, so the RFT would replace AUTO with 10 even
> without voltage switching. Preserving AUTO requires no special case for PF.
So can you say whether you observed a real problem with either the
current (broken) code, or with one the fixes? I am still confused about
your reports, whether they are just experiments, and comparing to the
BSP, or looking at the manual, or whether there is an actually observed
problem.
> I boot-tested your RFT with two small fixups for PB and AUTO on my Cubie
> A7Z (rev B). UART0 and MMC0 work, and GPIO_POW_MOD_SEL remains at
> 0x01155550. No voltage-field writes were expected with this DT. I haven't
> tested the RFT as posted.
>
> I agree the full table and PI exclusion aren't needed, and found no
> evidence for restricting the encoding to revision B.
Thanks for the confirmation, and just curious where this revB
restriction came from, originally?
> A733-R still needs its own descriptor for the two-bit PL/PM fields. I'm
> happy for your RFT to supersede my patch 1 once PB and AUTO are addressed,
> and I'll rebase the A733-R fix on it.
>
> I have the PB/AUTO fixups and the A733-R patch ready, and can send them if
> useful.
Well, this is getting really messy, isn't it? I never understood why
the IP even allows manual programming if there is an automatic setting.
Did you find any recommendation? IIRC manuals for other SoCs did
recommend one or the other method. If AUTO works, and is used by the
BSP, then we can just use that, but in a much simpler way: either use
BIAS_VOLTAGE_NONE, or create a new AUTO name (better), and then skip
the whole action in sunxi_pinctrl_set_io_bias_cfg(). Instead just once
program the GPIO_POW_MOD_SEL to "all auto", once at init time.
Curious what others think about this.
Cheers,
Andre
prev parent reply other threads:[~2026-10-13 22:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 14:23 [PATCH RFT] pinctrl: sunxi: Fix A733 withstand programming Andre Przywara
2026-10-13 17:23 ` Vinicius Pedrosa
2026-10-13 22:13 ` Andre Przywara [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261014001334.54dcf0b5@ryzen.lan \
--to=andre.przywara@arm.com \
--cc=dlan@gentoo.org \
--cc=enzo.adriano.code@gmail.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=samuel@sholland.org \
--cc=vinicius.eduardo.pedrosa@gmail.com \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox