From: James Calligeros <jcalligeros99@gmail.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Shenghao Ding <shenghao-ding@ti.com>, Kevin Lu <kevin-lu@ti.com>,
Baojun Xu <baojun.xu@ti.com>, Sen Wang <sen@ti.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org,
asahi@lists.linux.dev,
James Calligeros <jcalligeros99@gmail.com>
Subject: [PATCH 0/3] Enable shared GPIO for Apple Silicon audio support
Date: Mon, 31 Aug 2026 21:32:38 +1000 [thread overview]
Message-ID: <20260831-apple-shared-gpio-v1-0-e855b12e18ce@gmail.com> (raw)
Hi folks,
On Apple Silicon Macs, every speaker codec's software shutdown pin
is connected to the same GPIO line. This line must be pulled high
whenever any codec asserts it so.
This makes power management impossible. When we goe through the list of
codecs and call each suspend/resume, the GPIO line is asserted low or high
by the first suspended/resumed codec. This causes issues for the subsequent
codecs; they are already shut off by the time we try to cache the register
state on suspend.
In the downstream Asahi Linux kernel[1], we were previously (ab)using the
regulator API to work around this safely. We replaced the shutdown-gpios
property in the codec Devicetree nodes with a virtual regulator which acts
as a proxy for the GPIO line. The regulator will not deassert the pin until
every consumer wants it off, and it will assert it as soon as any one
codec requires it.
Now that the kernel has shared GPIO support, this has become unnecessary.
The first commit in this series enables shared GPIO for ARCH_APPLE so
that we can take advantage of this new(ish) infrastructure.
The shared GPIO infrastructure considers the first state change of a
line to be the "default" state, which is the state that it will allow
to be asserted without all consumers agreeing. Currently the TAS2764 and
TAS2770 drivers initialise the shutdown GPIO high, which means the first
change is to low. This does not help us, as the line will not be reasserted
on resume until all codecs have tried to assert it. Since both drivers
explicitly pull the line high on codec probe, we can initialise it low,
causing the first state change to be from low to high. This makes the
shared GPIO proxy behave as we intend. The second and third commits in this
series implement this.
This has been enabled in the Asahi Linux kernel since 7.1.9, and addresses
the last obstacle to attempting to upstream the machine driver for this
platform.
We intend to take the Kconfig patch via our soc tree. The two codec driver
changes should be taken via asoc.
Regards,
James
[1] https://github.com/AsahiLinux/linux
---
James Calligeros (3):
arm64: Kconfig: Select HAVE_SHARED_GPIOS for Apple Silicon
ASoC: tas2764: Initialise SDZ GPIO low
ASoC: tas2770: Initialise SDZ GPIO low
arch/arm64/Kconfig.platforms | 1 +
sound/soc/codecs/tas2764.c | 2 +-
sound/soc/codecs/tas2770.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
---
base-commit: cf72cbb39da84b6f02f90c07f33b102fc10b16f0
change-id: 20260829-apple-shared-gpio-60f86e74e35a
Best regards,
--
James Calligeros <jcalligeros99@gmail.com>
next reply other threads:[~2026-08-31 11:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 11:32 James Calligeros [this message]
2026-08-31 11:32 ` [PATCH 1/3] arm64: Kconfig: Select HAVE_SHARED_GPIOS for Apple Silicon James Calligeros
2026-08-31 11:32 ` [PATCH 2/3] ASoC: tas2764: Initialise SDZ GPIO low James Calligeros
2026-08-31 11:32 ` [PATCH 3/3] ASoC: tas2770: " James Calligeros
2026-08-31 12:12 ` (subset) [PATCH 0/3] Enable shared GPIO for Apple Silicon audio support Mark Brown
2026-09-01 20:11 ` Sven Peter
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=20260831-apple-shared-gpio-v1-0-e855b12e18ce@gmail.com \
--to=jcalligeros99@gmail.com \
--cc=asahi@lists.linux.dev \
--cc=baojun.xu@ti.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kevin-lu@ti.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=perex@perex.cz \
--cc=sen@ti.com \
--cc=shenghao-ding@ti.com \
--cc=tiwai@suse.com \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).