[PATCH v3 0/2] ASoC: es8328: enable capture on the ES8388

From: Bob Hui

Date: Sat Oct 31 2026 - 06:43:28 EST


This series fixes capture on boards built around the ES8388. That part
shares the driver with the ES8328, and the two differ in eleven power-on
register values and in the meaning of bit 7 of DAC Control 21, so the
driver has to know which part it is talking to before it can set either
of them up.

Changes in v3, addressing the Sashiko bot's suggestions on v2:

- Give the variant enum non-zero values, and add an SPI device id table
plus the ES8388 entry to the SPI match table. A zero match-data entry
cannot be told apart from "no match data", and with no id table the
fallback lookup walked a NULL table, which would fault on an
SPI-attached ES8328; an ES8388 behind SPI also resolved to the wrong
variant and skipped SLRCK.
- Drop the register cache after the control port reset. The cache
outlives a component rebind, so it would otherwise describe the values
the previous bind left behind instead of the ones the reset restored.
- Link to v2: https://patch.msgid.link/20261031-es8328-vol-init-v2-0-d15b04c22f4f@xxxxxxx

Changes in v2, addressing Mark Brown's review of v1:

- Reset the codec at probe time through SCP_RESET, so that the register
cache describes a state the hardware is actually in. SCP_RESET is not
self-clearing, so the reference and the VMID settings are written back
afterwards.
- Provide one set of power-on defaults per supported part, taken from the
ES8328 datasheet Revision 1.0 and the ES8388 datasheet Revision 5.0,
sections 6.1.1 to 6.3.30 in both cases.
- Look the variant up from the match data in the I2C and SPI glue instead
of testing the compatible string, so the lookup also works on ACPI
systems. Both i2c_get_match_data() and spi_get_device_match_data()
fall back to the legacy id table, and the I2C id table carries the
variant as well. The driver still has no ACPI HID table, as it never
had one.
- Use a define for the SLRCK bit, and drop the of.h include which is no
longer needed.
- Keep the regmap configuration indentation consistent.
- Link to v1: https://patch.msgid.link/20261024-es8328-vol-init-v1-0-efbd24de9639@xxxxxxx

The variant plumbing lives in patch 1 because the defaults have to be
chosen when the regmap is created, which happens in the bus glue before
the component is probed; patch 2 uses the same variant to decide whether
SLRCK applies. Boards with an ES8328 keep the same register values as
before; the only change for them is the reset at probe time.

One observation from bringing this up: this silicon is not fully
readable. Registers 0x28 and 0x29 read back as their power-on value
regardless of what is written, and bit 7 of register 0x01 is not
implemented, so writing 0xc0 reads back as 0x40. That is one more reason
to treat the register cache as the record of what the driver programmed
rather than reading the state back.

Testing: on a QuarkPi-CA2 (RK3588S, ES8388) running v7.3, where the codec
sits on I2C, playback works and capture goes from digital silence to
working audio. A register the driver never writes was modified before a
warm reboot and comes back at its reset value once the driver probes,
which shows that the reset and not a power cycle restores the state.
Unbinding and rebinding the sound card while the codec stays bound leaves
capture working as well, which exercises the cache invalidation above.

The SPI glue changes are compile-tested only: this board has no SPI
wiring for the codec, and the SPI side of the fix came from the Sashiko
review bot.

Assisted-by: Hermes:deepseek-v4-flash
Signed-off-by: Bob Hui <bg9oxa@xxxxxxx>
---
Bob Hui (2):
ASoC: es8328: reset the codec at probe time
ASoC: es8328: set SLRCK for the ES8388

sound/soc/codecs/es8328-i2c.c | 18 ++--
sound/soc/codecs/es8328-spi.c | 20 ++++-
sound/soc/codecs/es8328.c | 199 ++++++++++++++++++++++++++++++++++++++++--
sound/soc/codecs/es8328.h | 11 ++-
4 files changed, 231 insertions(+), 17 deletions(-)
---
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
change-id: 20261024-es8328-vol-init-6a52c17897cd

Best regards,
--
Bob Hui <bg9oxa@xxxxxxx>