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>

On Mon, 31 Aug 2026 21:32:38 +1000, James Calligeros wrote:
> 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.
> 
> [...]

Applied to git@github.com:AsahiLinux/linux.git (apple-soc/drivers-7.4), thanks!

[1/3] arm64: Kconfig: Select HAVE_SHARED_GPIOS for Apple Silicon
      https://github.com/AsahiLinux/linux/commit/a416a347931f

Best regards,
-- 
Sven Peter <sven@kernel.org>

On Mon, 31 Aug 2026 21:32:38 +1000, James Calligeros wrote:
> Enable shared GPIO for Apple Silicon audio support
> 
> 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.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.4

Thanks!

[2/3] ASoC: tas2764: Initialise SDZ GPIO low
      https://git.kernel.org/broonie/sound/c/e152ac60589b
[3/3] ASoC: tas2770: Initialise SDZ GPIO low
      https://git.kernel.org/broonie/sound/c/87e41baa36fc

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark