Honor MagicBook Art 14 (HONOR-MRA, MTL-P): RT1308 smart amp on I2C3 not functional — BIOS disables I2C3 controller

[voronin166]

Hardware

Laptop	Honor MagicBook Art 14, HONOR-MRA_XXX-M1100, SKU C233
CPU	Intel Meteor Lake-P (Core Ultra 7)
BIOS	3.05 (2025-03-07), latest available
Codec	Realtek ALC256 (HDA, subsystem 0x1ee72060) — works, drives 2 tweeters
Amp	Realtek RT1308 (ACPI: 10EC1308:00, path \_SB_.PC00.I2C3.HDC1, I2C addr 0x10, I2S+I2C mode — not SoundWire)
Kernel	6.17.0-20-generic
Stack	SOF sof-hda-dsp, PipeWire 1.4.7, topology sof-hda-generic-4ch.tplg

The laptop has 6 speakers: 2 tweeters (ALC256) + 4 woofers (RT1308). Only the 2 tweeters work under Linux.

Root cause

BIOS physically disables the I2C3 controller at hardware level.

1. GNVS variable I2SC = 0x00 at GNVS_BASE + 0x84E (physical addr 0x65DD8866).
RT1308 _STA in DSDT:

If (((I2SC == 0x02) && (CDIS != One))) { Return(0x0F) }

With I2SC=0x00, _STA returns 0 → ACPI device disabled:

$ cat /sys/bus/acpi/devices/10EC1308:00/status
0

2. I2C3 PCI device is absent — only 00:15.0 (I2C0) and 00:15.1 (I2C1) are visible in lspci.

3. I2C3 MMIO (0x48192D1000) returns 0xFFFFFFFF — hardware is physically off. Address overlaps with Thunderbolt BAR2 (PCI 00:0d.3).

4. NHLT table has no RT1308 endpoint — only BT on SSP4 and 4 DMIC.

5. SoundWire bus exists (/sys/bus/soundwire/) but is completely empty — no devices, no drivers.

6. Warm reboot from Windows does not help — tested multiple times.

ACPI details

• I2SB = 0x03 (I2C3 bus index)
• RT1308 I2C address: 0x10 (7-bit)
• GNVS OperationRegion: SystemMemory, 0x65DD8018, 0x0DAA
• I2SC at offset 0x84E within GNVS

SOF state

• No MTL + RT1308 (I2C mode) machine driver or topology exists in SOF project
• Existing RT1308 topologies target ADL/TGL with SoundWire
• ABI mismatch noted: sof-hda-generic-ace1-4ch.tplg reports ABI 3:29:1 vs kernel ABI 3:23:1

Questions

1. Is there a known way to force-enable I2C3 from Linux (ACPI method, EFI variable write)?
2. Is a machine driver/topology for MTL + RT1308-via-I2C feasible?
3. Should this be reported to Honor/Intel as a BIOS bug?

Full ACPI tables, dmesg, and additional diagnostics available on request.

[voronin166]

Status update (2026-04-18)

After exhaustive investigation, the blocking issue is at a lower level than SOF topology: the I2C3 controller is physically disabled by the BIOS and cannot be enabled from Linux via any known ACPI mechanism.

All approaches have been tried and failed:

• SSDT/DSDT overrides
• Writing I2SC=0x02 via ACPI
• acpi_osi="Windows 2015" spoofing
• Warm reboot from Windows

Windows enables I2C3 via its own PEP/LPSS boot driver that directly programs PCH registers — Linux has no equivalent for this hardware. The issue has been escalated to thesofproject/linux #5740 where a DMI-based quirk for the Intel LPSS driver is being discussed.

This means a new SOF topology for MTL+RT1308 would be premature until the I2C3 hardware enable problem is resolved upstream. Keeping this issue open for tracking, but the actionable work is in the linux repo.

[mark-herbert42]

Sound pretty strange to me. I have 2 arts - MRB-A ARL-based, and MRA-521 (MTL based). My MRA is global, while MRB is Chinese. They all have 6 speakers - MRB looks bit more advanced but they are compatiple in the way you can swap them between laptops without any issue. tweeters are in separate boxes, while the 4 big speakers are connected to the ESMT AD52068B amp. And there is ALC256 chip on board as well - but I have'nt seen the RT1308 there. And the big speakers - the ones you call woofers - work just great out of the box. The only thing I had to do is to open alsamixer and unmute some pre-mixer or post-mixer controls (do not remember exactly which ones) - so that made all 4 big speakers work. And only the tweeters were silent till this patch

https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=d9448dca423543c6c0a9890d3ff53a5d51895318

So my suggestion is - try to extend this workaround to MRA hardware, that most likely will help. From what I see on the board - Honor just upgraded the CPU trying to keep as much as possible unchanged, so whatever quirk is good for MRB model shoul help in MRA.

And I would not trust to the BIOS findings - BIOS can have reference to RT1308 but that does not mean that you have th RT1308 in hardware. Maybe thye planned to use it , made a bios but finally for some reason used AD52068 instead and just disabled RT1308 path.