I purchased a new I/O board but it did not resolve the issue. I made a summary documentation about the issue. Could you take a look at it please?
The ES8316 codec is detected and the sound card is registered, but actual codec register access fails during playback bring-up. The failure is not limited to PipeWire or ALSA routing; it reproduces on direct ALSA playback and on the PipeWire path.
The strongest current evidence is:
- playback-time I2S and MCLK clocks are alive,
- the codec is still visible on the I2C bus,
- but ES8316 register reads and writes fail with repeated `ASoC ... -6` errors,
- and debugfs regmap output shows many codec registers as unreadable even when idle.
This does not look like a simple user-space routing issue, and it no longer looks like an old I/O board-only problem either, because the issue remained after retesting with a new I/O board.
The most likely remaining categories are:
1. vendor BSP / codec driver sequencing bug or backport mismatch,
2. codec-side accessibility problem on the main board path,
3. connector, reset, power, or codec control-line issue between the main board and the audio path.
## Platform
- Board: Khadas Edge2 / RK3588S
- Codec: ES8316 on I2C bus 3, address `0x10`
- Kernel: `6.1.118`
- BSP package: `linux-image-rockchip-6.1` version `1.7.5`
- DTB package: `linux-dtb-rockchip-6.1` version `1.7.5`
- Live DTB: `/boot/dtb-6.1.118/rockchip/rk3588s-khadas-edge2.dtb`
- Active audio server: PipeWire / PulseAudio compatibility layer
Relevant detected playback devices:
- `rockchip-dp0`
- `rockchip-hdmi0`
- `rockchip,es8316-codec`
Relevant ES8316 sink seen in PipeWire:
- `alsa_output.platform-es8316-sound.stereo-fallback`
## Problem Statement
The ES8316 audio path is enumerated, selectable, and can be opened from user space, but audio playback does not produce confirmed normal sound output.
Instead, kernel logs show repeated codec register access failures during playback startup and power-up sequences.
Typical failure pattern:
- early failures at `0x0b`, `0x0a`, `0x09`
- followed by `0x04`, `0x05`, `0x06`, `0x07`
- then `0x01`, `0x0d`
- then analog / charge-pump / output-side registers such as `0x18`, `0x19`, `0x1a`, `0x2f`, `0x15`, `0x17`, `0x30`
This register order strongly matches codec bring-up, interface programming, and output-path power transitions rather than a late teardown-only problem.
## User Feedback During Latest Retest
The system was retested after replacing the I/O board.
Playback was intentionally kept conservative:
- PipeWire sink volume was limited to 50%
- only short and simple playback tests were used
- no high-volume stress playback was performed
User feedback from the short 50% playback test:
- a small metallic / electrical noise may have been heard
- it was not clear whether that noise actually came from the speaker
- there was no confirmed normal audio playback
This means the retest did not produce evidence of successful speaker playback.
## What Was Tested
### 1. Direct ALSA playback
Short raw playback was tested against the ES8316 hardware device, including direct silent playback with `aplay`.
Observed behavior:
- `aplay` returned success (`RC=0`)
- the kernel still immediately emitted ES8316 `-6` register access failures
Interpretation:
- the user-space stream can start
- but the codec control path fails during actual runtime programming
### 2. PipeWire playback
The ES8316 sink was set as default and volume was capped at 50% before playback.
Observed behavior:
- playback path ran from user space
- fresh kernel ES8316 `-6` failures reappeared
- no confirmed normal sound output resulted
Interpretation:
- this is not limited to direct ALSA only
- the fault is below the audio server layer
### 3. Mixer state inspection
The ES8316 mixer contents were examined.
Notable observations included:
- unusual or suspicious mixer defaults were present
- `Playback Polarity` was not at a clearly normal value
- `DAC Source Mux` did not look obviously ideal
- some controls had ranges suggesting the running driver includes at least some non-base-v6.1 fixes
These mixer states are not sufficient by themselves to explain the failure, but they show the codec control surface is not in a completely trivial default state.
### 4. Kernel log inspection
Recent and fresh kernel logs were examined before and after playback tests.
Result:
- the same ES8316 `ASoC ... -6` pattern reproduced again with the new I/O board
## Live Device Tree Findings
The live DTB was decoded from:
- `/boot/dtb-6.1.118/rockchip/rk3588s-khadas-edge2.dtb`
### ES8316 codec node
Relevant live properties:
- node: `/i2c@feab0000/es8316@10`
- `compatible = "everest,es8316"`
- `status = "okay"`
- `clocks = <&mclkout_i2s0>`
- `clock-names = "mclk"`
- `assigned-clocks = <&mclkout_i2s0>`
- `assigned-clock-rates = <12288000>`
- `spk-con-gpio` is present
- `hp-det-gpio` is present
Important conclusion:
- the live Edge2 DT already uses the same important 12.288 MHz MCLK assignment idea that fixed a known RK3588 Rock5B issue upstream
### ES8316 sound card node
Relevant live properties:
- node: `/es8316-sound`
- compatible: `simple-audio-card`
- `simple-audio-card,format = "i2s"`
- `simple-audio-card,mclk-fs = <256>`
- CPU DAI phandle points to the I2S0 controller
- codec DAI phandle points to the ES8316 codec node
### I2S0 node
Relevant live properties:
- node: `/i2s@fe470000`
- compatible: `rockchip,rk3588-i2s-tdm`
- `clock-names = "mclk_tx", "mclk_rx", "hclk"`
- `rockchip,trcm-sync-tx-only` is set
- I2S pinctrl is present
- node status is `okay’
Important conclusion:
- the live DTS wiring is not obviously missing the standard ES8316 MCLK assignment
- this weakens the hypothesis that the current issue is the same as the known Rock5B first-open MCLK misconfiguration bug
## Clock Findings
Playback-time clock inspection showed the RK3588 audio path is active.
Observed during playback window:
- `hclk_i2s0_8ch` enabled
- `clk_i2s0_8ch_rx` enabled
- `clk_i2s0_8ch_tx` enabled
- `mclk_i2s0_8ch_rx` enabled
- `mclk_i2s0_8ch_tx` enabled
- `i2s0_mclkout_to_io` enabled and associated with `3-0010` / `es8316@10`
- effective MCLK was around `12.288 MHz`
Important conclusion:
- the main audio clock path is alive during playback
- this does not look like a dead I2S clock tree
## I2C and Regmap Findings
### I2C bus state
The codec remained present on I2C bus 3.
Observed:
- `i2cdetect -y 3` showed the codec bound at `0x10` as `UU`
Important conclusion:
- the codec is still registered on the bus
- the bus is not simply missing the device
### Low-level controller logs
The kernel log did not show a clean, obvious pattern of RK I2C controller timeout or arbitration-loss messages on `feab0000.i2c` at the time of the ES8316 failures.
Important conclusion:
- this weakens the idea that the main SoC I2C controller itself is simply dead
### Runtime PM state
Codec and controller runtime PM state did not indicate a classic runtime-suspend mistake:
- runtime PM showed as unsupported / disabled rather than actively suspending the device
Important conclusion:
- the current evidence does not point to runtime PM as the primary trigger
### Regmap debugfs
The ES8316 regmap debug interface exists:
- `/sys/kernel/debug/regmap/3-0010`
Crucial observation:
- many registers in `/sys/kernel/debug/regmap/3-0010/registers` already showed `XX` even while idle
Important conclusion:
- codec register accessibility is partially broken even outside active playback
- this is a very strong signal that the problem is deeper than just user-space route selection or a normal muted output
## Local Driver / Kernel Findings
### Driver presence
The ES8316 driver is present on the machine and built into the running kernel.
Observed:
- `CONFIG_SND_SOC_ES8316=y`
- `modinfo` reports `snd_soc_es8316`
- author shown by modinfo: `David Yang`
- description: `Everest Semi ES8316 ALSA SoC Codec Driver`
### Built-in symbol evidence
The running kernel exposes ES8316 symbols in `/proc/kallsyms`, including:
- `es8316_set_dai_fmt`
- `es8316_pcm_hw_params`
- `es8316_pcm_startup`
- `es8316_set_dai_sysclk`
- `es8316_probe`
- `es8316_i2c_probe`
- `es8316_irq`
- `es8316_set_jack`
- and notably `es8316_enable_spk.isra.0`
### Upstream 6.1 comparison
The upstream Linux 6.1 ES8316 driver was checked by line number.
Relevant upstream 6.1 locations:
- `ALC Capture Target Volume` control around line 118
- `es8316_set_dai_sysclk()` around line 358
- `es8316_pcm_hw_params()` around line 458
- `es8316_probe()` around line 720
- `ES8316_SYS_VMIDSEL` write around line 751
- `ES8316_CLKMGR_ADCOSR` write around line 758
However, there are two important local-vs-upstream clues:
1. The running system exposes `es8316_enable_spk.isra.0`, which is not part of the plain upstream Linux 6.1 ES8316 driver shape.
2. The running mixer suggests the `ALC Capture Target Volume` range is already at the later fixed maximum, which differs from plain base v6.1 behavior.
### Vendor divergence clue
A public vendor kernel tree was found containing:
- `es8316_enable_spk()` in `yanyitech/coolpi-kernel`
This matters because the presence of `es8316_enable_spk` in the running kernel strongly suggests that the active Edge2 driver is not a pure untouched upstream ES8316 driver, but a vendor-diverged or backported branch with speaker GPIO handling.
### Practical conclusion about the local driver
The current kernel appears to be:
- based on the ES8316 mainline driver family,
- but not identical to plain upstream Linux 6.1,
- and likely contains vendor-specific ES8316 changes or backports.
That is important because it means upstream behavior and vendor behavior cannot be assumed to match exactly.
## Similar Non-Khadas Rockchip Cases Found Online
### Case A: CoolPi CM5 / Armbian 6.1
Public thread:
- CoolPi forum: ES8316 sound issues on Armbian with 6.1 Rockchip kernel
Pattern:
- no sound
- static on headphone path
- custom out-of-tree ES8316 variants were involved
Reported fix direction:
- DTS / clock path changes
- use of `mclkout_i2s0`
- explicit `assigned-clock-rates = <12288000>`
- proper I2S0 MCLK pinctrl
Category:
- configuration / DTS issue
### Case B: Rock5B upstream ES8316 fix series
Public patch series:
- `[PATCH v2 0/3] ES8316 audio codec fixes on Rock5B`
Key fixes:
1. Driver fix: do not set rate constraints for unsupported MCLKs
2. DTS fix: assign ES8316 MCLK to `12.288 MHz`
3. Mixer control fix: fix `ALC Capture Target Volume` max value
Typical failure in that case:
- first-open invalid configuration
- wrong or non-standard sample rates
- `Invalid argument` on first access
Category:
- partly driver / kernel behavior
- partly DTS / config issue
### Why those cases matter here
They show that Rockchip + ES8316 problems do exist outside Khadas and that MCLK and DTS mistakes are real.
But they are still not a perfect match for the current Edge2 case because:
- the current Edge2 DT already has explicit 12.288 MHz assignment
- the current playback does open successfully from user space
- the current failure is repeated runtime regmap access failure with `-6`, not just first-open rate constraint failure
## Interpretation of the Current Evidence
### What is less likely now
The following explanations are weaker now than at the start:
- simple PipeWire routing problem
- simple ALSA card selection problem
- wrong default sink only
- old I/O board alone being the entire cause
- dead RK3588 audio clock tree
- obviously dead RK3588 I2C controller
- ordinary user-space mute / mixer mistake as the only root cause
### What remains plausible
The most plausible explanations now are:
1. Vendor ES8316 driver sequencing bug
- reset / mute / power-up / jack-detect / speaker-enable ordering is wrong
- a vendor backport may be inconsistent with this BSP
2. Codec accessibility problem on the hardware control path
- reset line, control line, or codec-side state machine may not be stable
- regmap access failing even while idle is the strongest clue here
3. Main-board or connector path issue rather than I/O board issue
- replacing the I/O board did not remove the failure
- this shifts suspicion toward the base board side, connector path, or codec control wiring
4. Power / reset / jack-detect / speaker GPIO interaction bug
- the running kernel appears to contain a vendor-style speaker-enable path
- if that path is wrong for Edge2 hardware, it could make the codec inaccessible or unstable during runtime transitions
## Current Best Working Hypothesis
The strongest current working hypothesis is:
The Edge2 is running a vendor-diverged ES8316 driver path that is able to probe and register the codec, and able to bring up the I2S/MCLK side, but fails during runtime codec control transactions because the codec becomes partially inaccessible during reset / power / speaker-enable / jack-detect related sequencing.
If there is still a hardware issue, it is more likely on the main board side or on the codec control path than in the replaced I/O board itself.
## What We Have Already Tried
- confirmed ALSA card enumeration
- confirmed PipeWire sink selection
- confirmed direct ALSA playback path
- repeated short direct ALSA tests
- repeated short PipeWire tests
- safe-volume playback retest at 50% after I/O board replacement
- fresh kernel log capture before and after playback
- live DT inspection from `/proc/device-tree`
- full DTB decompile from the installed Edge2 DTB
- runtime clock inspection during active playback
- regmap debugfs inspection
- runtime PM inspection
- regulator inspection for likely relevant rails
- I2C bus presence check with `i2cdetect`
- local kernel config / modinfo / symbol inspection
- non-Khadas web research for similar Rockchip ES8316 cases
## Recommended Next Steps
### 1. Add a minimal debug patch to the vendor ES8316 driver
Goal:
- log the first real failing transaction with enough board state around it
Minimum useful instrumentation:
- before and after `es8316_set_dai_sysclk()`
- at entry of `es8316_pcm_startup()`
- at entry of `es8316_pcm_hw_params()`
- around the first writes to `0x0b`, `0x0a`, `0x09`, `0x04-0x07`
- around output-path writes to `0x18`, `0x19`, `0x1a`, `0x2f`, `0x15`, `0x17`, `0x30`
- log current `sysclk`, sample rate, format, IRQ presence, and any speaker-enable state
- if the vendor path has `es8316_enable_spk()`, log its requested level and the actual GPIO value
### 2. Compare the live Edge2 DTB against the exact vendor kernel DTS source
Goal:
- verify whether the shipping Edge2 vendor DTS and the running ES8316 driver actually agree on property names and expected GPIO behavior
Key targets:
- `spk-con-gpio`
- `hp-det-gpio` vs `hp-det-gpios`
- I2S0 pinctrl modes
- MCLK source node and clock consumer path
- any vendor-only Edge2 audio properties
### 3. Check main-board side hardware control lines
Goal:
- verify whether the codec control path remains electrically healthy during stream bring-up
Best targets if equipment is available:
- ES8316 reset behavior
- ES8316 MCLK presence and continuity during stream start
- I2C SCL/SDA behavior during the first failing playback transition
- speaker-enable GPIO behavior
- power rail stability on codec-related audio supplies
### 4. Isolate speaker-enable / jack-detect side effects
Goal:
- test whether the vendor speaker-enable or jack-detect path is what destabilizes codec access
Possible experiment:
- temporarily disable or stub the speaker-enable transition in the driver
- temporarily suppress jack-detect enable path
- rerun the same short direct ALSA playback test
If the repeated `-6` failures disappear or change significantly, that would sharply narrow the fault.
## Bottom Line
The current problem is not well explained by user-space routing, by missing driver support, or by a simple wrong sink choice.
The current Edge2 system already has the ES8316 driver built into the kernel, the sound card is registered, the live DTB already assigns a valid 12.288 MHz MCLK, and playback clocks do come up.
But the codec still fails during runtime register access, even with a new I/O board.
That makes the problem look like a codec control-path failure, most likely in a vendor-diverged ES8316 driver path or in board-level codec accessibility on the main board side.