[BUG] ESSX 8336 No local devices (speakers/headphones) on N4120 tablet (Chuwi Hi10X)

[callegar]

Describe the bug

Cannot seem to be able to get sound working on the Chuwi Hi10X convertible/tablet. It looks like there are two versions of this tablet using the same Hi10X name. The problematic one uses a Celeron N4120 Gemini lake processor and related chipset.

Trying with manjaro linux that uses a quite recent kernel and alsa. Audio is not detected apart from the HDMI outputs.

Tried options snd-intel-dspcfg dsp_driver=1 that does not seem to help.

Alto tried options snd-intel-dspcfg dsp_driver=3 that creates a lot of activity on dmesg (with many errors). Will attach output here if relevant.

Audio works in Windows and that OS shows "Smart Sound Technology (Intel(R) SST) OED" for the audio part not attached to HDMI. The device codes I am getting there are 3198, 0222 and AE34. And for all of them the vendor code is 8086 (intel).

Before proceeding with an attempt to collect more data I would like to know if sound is expected to be working in linux on this hardware or if it is still a work in progress, so that testing is premature.

To Reproduce

aplay -l only reports HDMI outputs.

Reproduction Rate

Always.

Expected behavior

Sound should be available via the internal speakers and the audio jack (mic+headphones).

Impact

Total showstopper. Only way to use audio on this machine is to use bluetooth headphones.

Environment

Unclear to me how to get this for my system that is installed from a distro.

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: {SHA}
   • SOF: {SHA}
2. Name of the topology file
   • Topology: {FILE}
3. Name of the platform(s) on which the bug is observed.
   • Platform: {PLATFORM}

Screenshots or console output

Will provide all that may be needed if audio can be expected to be working on this system.
Unclear to me how to get the sof-logger to debug.

[callegar]

Moving to a 5.12 kernel, with snd-intel-dspcfg dsp_driver=3 the firmware appears to load correctly. However, a topology file for idisp only seems to be loaded and the local devices remain missing.

The situation seems similar (to some extent) to the one described in https://askubuntu.com/questions/1330755/no-sound-on-gemini-lake-with-xubuntu, that also refers to geminilake.

[kv2019i]

@callegar wrote:

Before proceeding with an attempt to collect more data I would like to know if sound is expected to be working in linux on this hardware or if it is still a work in progress, so that testing is premature.

The DSP side on N4120 is supported on Linux (e.g. there are multiple Chromebooks with N4120). But for devices that have shipped with Windows, it all depends how the vendor has put the hw together, what codec, how it's hooked up, are there codec drivers in Linux for the hw, etc, etc.

So before that can be answered, more info is needed on the hw.

Can you do a NHLT dump and attach the output to this bug?

sudo bash
cat /sys/firmware/acpi/tables/NHLT >NHLT.bin

The NHLT.bin might reveal something about this machine. NHLT is a set of tables in ACPI providing the OS (Linux here) information about how the audio peripherals are connected. More info at https://01.org/sites/default/files/595976_intel_sst_nhlt.pdf

[callegar]

Here is the file. Had to zip it otherwise github did not let me download it.
I see the word ALASKA in the file. There is this word in something that the kernel tries to load (failing) if I set snd-intel-dspcfg dsp_driver=2.

nhlt.zip

[kv2019i]

So it seems there's a I2S codec connected, but NHLT doesn't reveal make or model. We support a few configuration for GLK upstream, you can see the list in:
linux/sound/soc/intel/common/soc-acpi-intel-glk-match.c

It would seem this is not a supported configuration, so some new development (by someone who has a device) is needed. At minimum, an entry is needed to soc-acpi-intel-glk-match.c, but more likely is some changes and/or new code is needed in machine drivers. The codec most probably is already supported upstream.

[plbossart]

ALASKA isn't linked to audio codecs.

I think we need to start with the basics assuming the DSP is not enabled and it's an HDaudio codec. I am not aware of any non-Chromebook devices with I2C/I2S and of any support on Windows for this kind of codecs.

@callegar You need to start with removing all options and checking how snd-hda-intel deals with the hardware. attach dmesg and alsa-info (separtely)

[callegar]

Here is the dmesg obtained after removing any modprobe option related to snd-intel-dspcfg dsp_driver=....
dmesg.txt

[callegar]

... And here I also have the alsa info
alsa-info.txt

[callegar]

@kv2019i:

it seems there's a I2S codec connected, but NHLT doesn't reveal make or model.

before I switched to linux, I have collected the hardware info I could get from windows. Here I see a "hierarchy" of audio devices, springing from a 8086.3198 Intel SST audio subsystem. Local microphone and speakers appear to be attached via a 8086.0222 OED device (don't know what OED stands for) and 8086.AE34. Could any of them point at the actual CODEC?

I also have the windows partition images that can be mounted for inspection (including a recovery image). Do you believe that anything there could hint at some hardware description and at how the codec should be managed?

[kv2019i]

@plbossart It seems DSP is enabled and NHLT lists a I2S port programmed:
[ 3.994142] snd_hda_intel 0000:00:0e.0: DSP detected with PCI class/subclass/prog-if info 0x040100

@callegar You can look at this old bug https://bugzilla.kernel.org/show_bug.cgi?id=189261 to see typical steps to dig up information from Windows. DSDT dump with probably reveal details -- I'd guess it's a Realtek codec so ACPI HID will be 10EC something.

[callegar]

@kv2019i I'm not really able to read the dsdt dump file, but grepping for 10EC returns nothing.

dsdt.dsl.txt

[callegar]

@kv2019i incidentally, using options snd-intel-dspcfg dsp_driver=3 shows in dmesg that a firmware is actually loaded and booted. Would that dmesg dump be useful too?

[callegar]

Among the ACPI devices I find an ESSX8336. This is an Everst sound device, right? Can it be relevant?
I have also found this on github, but unclear to me if it should apply and how: https://github.com/yangxiaohua2009/GLK-ES8336
The repo owner seems to be the same person writing in the bugzilla.kernel.org thread (about audio on the Chuwi X10/X12 you have just pointed me at).