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]

Update after further investigation (2026-04-18)

All ACPI-level approaches have been exhausted:

• SSDT override (creating INT34B5:00, raising i2c-3 bus, writing I2SC=0x02) — caused Thunderbolt 00:0d.3 BAR2 conflict (same MMIO 0x48192D1000); i2c_designware / intel_lpss probe returned ENODEV — hardware does not respond
• DSDT override via initrd — kernel 6.17 has no CONFIG_ACPI_INITRD_TABLE_OVERRIDE; DSDT was in initrd but never applied
• acpi_osi="Windows 2015" — no effect; 10EC1308:00/status remains 0; BIOS writes I2SC=0x00 to GNVS statically during POST, before any OS interaction

The key observation: Windows does enable I2C3, but not via ACPI _OSI path. It appears Windows acpi.sys/pep.sys (Platform Extension Plugin) directly programs the PCH LPSS registers to power on and configure I2C3 during early boot — before userspace drivers load. Linux has no equivalent quirk for this hardware.

Question: Is it feasible to add a DMI-based quirk to the Intel LPSS driver (or a similar location) that force-enables the I2C3 PCH controller for this specific laptop, ignoring the _STA=0 from ACPI? What PCH registers would need to be written, and would the SOF team be able to advise on this path?

EFI variable PchSetup (4570b7f1-..., 6082 bytes) has been identified; [0x0007]=0x02 may relate to I2C3 mode, but the structure is undocumented and modification without confirmation seems too risky.

[voronin166]

Further investigation: root cause chain identified (2026-04-18)

Traced the full disable chain for I2C3:

FSP-S UPD parameter SerialIoI2cMode[3] = 0 (Disabled) is set by BIOS for this laptop. When FSP-S silicon initialization runs, it programs the PCH via P2SB/PSF sideband registers to:

• Hide PCI function 00:15.3 (I2C3, PCI ID 0x7e7b) from enumeration
• Power-gate the I2C3 MMIO block at 0x48192D1000

This is confirmed by the FSP UPD header from Intel's public FSP repo (MeteorLakeFspBinPkg/IoT/MeteorLake/Include/FspsUpd.h):

UINT8 SerialIoI2cMode[8];  // Offset 0x027B
// 0: Disabled, 1: PCI mode, 2: Hidden (ACPI only)

Proposed fix path: A DMI-based quirk kernel module that:

1. Calls p2sb_bar() to access the P2SB MMIO
2. Writes to the PSF (Primary Sideband Fabric) registers via PCR mechanism (P2SB_BAR + (port_id << 16) + offset) to un-hide 00:15.3 and power on the I2C3 hardware
3. Allows intel_lpss_pci to then probe the device normally

Missing piece: The specific PSF port ID and register offsets for MTL I2C3 function enable — these would be in the FSP-S source or MTL PCH EDS.

Could someone from Intel confirm:

1. Which PSF port controls I2C3 on MTL (PID_PSF1 = 0xBA or different)?
2. What is the T0_SHDW register offset for the LPSS I2C3 function within that PSF port?

This is actionable — once we have the register offsets, we can write the kernel module.

[bardliao]

@voronin166 Do you have the HW design document? We need to know the HW design. I agree with @mark-herbert42 thesofproject/sof-bin#206 (comment). We can't 100% trust the BIOS.

Unfortunately, I have no idea about the I2C controls. You might enable the I2C by adding I2C3 related ACPI section via https://github.com/thesofproject/acpi-scripts.