[plbossart]

address #2955 reported by @callegar

This should only force the SOF driver to be loaded and assumes the firmware file is installed in /lib/firmware/intel/sof.
The topology file should be copied, e.g. from https://github.com/yangxiaohua2009/GLK-ES8336 (from @yangxiaohua2009)

@callegar please take this branch for a spin. This will not create a card since it's missing the machine driver but it should setup the SOF part.

[callegar]

@plbossart currently doing some 'homework' to prepare for testing. Tried to compile a kernel on manjaro and succeeded (my first kernel compilation on a tablet, nice). Now looking at how to integrate your changes.

I have a few question (mostly about making sure that I am not making mistakes, so that my feedback can be useful):

• I assume that these two patches can be directly applied to the 5.12.8 kernel tree, right?
• Your comment says patches assume the firmware file is installed in /lib/firmware/intel/sof. Do I need to grab the firmware from somewhere? or is the sof-glk.ri file that I already have OK?
• In fact I have 3 different sof-glk.ri (one in /lib/firmware/intel/sof/community/sof-glk.ri, one in/lib/firmware/intel/sof/intel-signed/sof-glk.ri, one in /lib/firmware/intel/sof/sof-glk.ri, the last one being a link to the signed one). Is this one OK? I also have a sof-glk.ldc being a link to sof-apl.ldc. Is it OK?
• The topology file to copy over is sof-glk-es8336.tplg, right? There seem to be 3 different versions of it in the @yangxiaohua2009 tree. Is one to be preferred over the others?
• I see that a couple of build checks above fail. Should I be worried about it? Should I wait to test when the tree checks are all clean?

I am also trying to read your patches, to see if I can learn something, but so far I am still in the phase in which clarifications are needed all the time (sorry about that):

• Your patched version of soc-acpi-intel-glk-match.c seems to match some parts of the same file in the yangxiaohua2009's tree, but also to exclude some other parts. With reference to the glk_codecs struct, I do not understand why in the yangxiaohua2009's tree there is the ESSX8336 codec and in yours the MX98357A one. I also see that the .machine_quirk and .quirk_data fields are not filled. Is it because of the work in progress? By changing the gtk_codecs structure in this way, does the yangxiaohua2009's tree break the DLGS7219, 10EC5682 and 10134242 that end up getting a different quirk_data?
• In the yangxiaohua2009's tree there is no change to the intel-dsp-config.c file at all. What exactly is that?
• I am asking the previous question because of the matches entries. Here, you look for the DMI_BOARD_NAME being "Hi10 X". I believe that this string was taken from my dump. However, I am wondering if this match is OK/enough. In fact, to the best of my knowledge, there are 2 different pieces of hardware both identified by Chuwi as Hi10 X with different audio codecs. From exchanges on the Chuwi forum, I believe that there used to be a Hi10 X with the N4100 and a Realtek codec, then an enhanced version of that called Hi10 XR with the N4120 started being sold in parallel to it, still with the Realtek codec, and now there is a "new" Hi10 X superseding both with the N4120 and the Everest codec.
• The yangxiaohua2009's tree also provides sof_essx8336.c. Is that the machine driver that at this point is still missing here, but that in fact is taken from your HiFiberry driver?

[plbossart]

@plbossart currently doing some 'homework' to prepare for testing. Tried to compile a kernel on manjaro and succeeded (my first kernel compilation on a tablet, nice). Now looking at how to integrate your changes.

I never compile on a target device, only install kernel, modules and initrd. see https://thesofproject.github.io/latest/getting_started/setup/setup_ktest_environment.html

I have a few question (mostly about making sure that I am not making mistakes, so that my feedback can be useful):

• I assume that these two patches can be directly applied to the 5.12.8 kernel tree, right?

probably no. We work with the latest upstream code, so there are dependencies that haven't hit Linus' tree just yet.

If you want better support from us, use our tree :-)

• Your comment says patches assume the firmware file is installed in /lib/firmware/intel/sof. Do I need to grab the firmware from somewhere? or is the sof-glk.ri file that I already have OK?
• In fact I have 3 different sof-glk.ri (one in /lib/firmware/intel/sof/community/sof-glk.ri, one in/lib/firmware/intel/sof/intel-signed/sof-glk.ri, one in /lib/firmware/intel/sof/sof-glk.ri, the last one being a link to the signed one). Is this one OK? I also have a sof-glk.ldc being a link to sof-apl.ldc. Is it OK?

that should be fine.

• The topology file to copy over is sof-glk-es8336.tplg, right? There seem to be 3 different versions of it in the @yangxiaohua2009 tree. Is one to be preferred over the others?

I see one topology, you start from the m4 code to generate the .conf and compile the .tplg one. Only the latter needs to land in /lib/firmware/intel/sof-tplg

• I see that a couple of build checks above fail. Should I be worried about it? Should I wait to test when the tree checks are all clean?

there is no issue.

I am also trying to read your patches, to see if I can learn something, but so far I am still in the phase in which clarifications are needed all the time (sorry about that):

• Your patched version of soc-acpi-intel-glk-match.c seems to match some parts of the same file in the yangxiaohua2009's tree, but also to exclude some other parts. With reference to the glk_codecs struct, I do not understand why in the yangxiaohua2009's tree there is the ESSX8336 codec and in yours the MX98357A one. I also see that the .machine_quirk and .quirk_data fields are not filled. Is it because of the work in progress? By changing the gtk_codecs structure in this way, does the yangxiaohua2009's tree break the DLGS7219, 10EC5682 and 10134242 that end up getting a different quirk_data?

the code from yangxiaohua2009 is incorrect and breaks other platforms. What I added is the only thing needed.

• In the yangxiaohua2009's tree there is no change to the intel-dsp-config.c file at all. What exactly is that?

probably because they use blacklists to avoid using snd-hda-intel. this change is required to avoid any blacklists.

• I am asking the previous question because of the matches entries. Here, you look for the DMI_BOARD_NAME being "Hi10 X". I believe that this string was taken from my dump. However, I am wondering if this match is OK/enough. In fact, to the best of my knowledge, there are 2 different pieces of hardware both identified by Chuwi as Hi10 X with different audio codecs. From exchanges on the Chuwi forum, I believe that there used to be a Hi10 X with the N4100 and a Realtek codec, then an enhanced version of that called Hi10 XR with the N4120 started being sold in parallel to it, still with the Realtek codec, and now there is a "new" Hi10 X superseding both with the N4120 and the Everest codec.

The quirk in intel-dsp-config would work for both cases if they are all I2S/I2C codecs.
The case of a realtek codec would need a dedicated match entry.

• The yangxiaohua2009's tree also provides sof_essx8336.c. Is that the machine driver that at this point is still missing here, but that in fact is taken from your HiFiberry driver?

yes, they use the minimal sof-wm8804.c and modified it. A better solution is needed but one step at a time.

[callegar]

@plbossart thanks for the extended help. I'll check the getting started document. I will probably not be able to test today, due to work duties, but I plan doing it asap. In the meantime, I got a reply from yangxiaohua who I am trying to get in the loop. From his email, they have reached a point where they have a working driver (only still failing headphone detection). He has sent me driver code that may be more recent than the one on his github repo (I'll diff and see asap). The alternate topologies and drivers in his repo are in ssp/ssp0 and ssp/ssp1.

[plbossart]

@callegar are you saying the exact connectivity is not known? I am not sure I understand why there are alternate topologies, the SSP number is related to the hardware layout, it's not like we have any freedom here.

[callegar]

@plbossart I don't know if I am understanding the matter in the correct way but what I see in the @yangxiaohua2009 repo there is an ssp folder with a readme saying

now we have bclk 4.8m, lrck 48k and data 24bit, but we still don't have mclk.
you may replace the original machine driver and topoloy file with that in ssp0/ssp1
folder to change the backend dai to ssp0/ssp1.

[plbossart]

@plbossart I don't know if I am understanding the matter in the correct way but what I see in the @yangxiaohua2009 repo there is an ssp folder with a readme saying

now we have bclk 4.8m, lrck 48k and data 24bit, but we still don't have mclk.
you may replace the original machine driver and topoloy file with that in ssp0/ssp1
folder to change the backend dai to ssp0/ssp1.

I saw this and can't figure out what it means. the choice of the SSP number is dictated by hardware and PCB layout, it's not like there's a user choice to select a different number.

[callegar]

@plbossart I have managed spending some time on your patches, but obviously I am in big trouble because the tablet has Manjaro on it (I need a rolling distro to have other stuff apart from sound working) and is being used, so I cannot really disrupt the install. At the same time your nice getting started guide assumes a debian/ubuntu target, which is quite reasonable.

My first experiment has been to backport your patches to 5.12.9 (the current manjaro kernel) and make a manjaro kernel package with it, by compiling on a faster laptopo. So when I install it on the tablet, the initrd is generated and the system boots.
Unfortunately, with this I see absolutely no change on dmesg and no sign of the firmware or topology files being loaded.

... and obviously because I was not following your instructions it is totally unclear to me whether the issue is on my side...

So when I have some time again I'll make a different experiment. I'll try to make an "ubuntu on a usbpen" system so I can work there without affecting the in-use OS of the tablet and use your kernel and getting started guide.

[plbossart]

This PR is now ready for review thanks to the work of @hli25

Dependencies:
topology update in thesofproject/sof#4577
codec driver update in #3107 - this needs to be cleaned up by codec vendor and is not something the SOF team should review.

[kv2019i]

A few HDMI implementation notes. See inline.

[kv2019i]

You can drop this. See SND_SOC_INTEL_EHL_RT5660_MACH for a simple reference for HDMI dependencies.

[plbossart]

@kv2019i can you take a look? You had a change requested.

[kv2019i]

One minor thing still, otherwise looks good to go.

[sergeyfil1]

адрес # 2955 сообщил @callegar

Это должно только вызвать загрузку драйвера SOF и предполагает, что файл прошивки установлен в / lib / firmware / intel / sof.
Файл топологии следует скопировать, например, с https://github.com/yangxiaohua2009/GLK-ES8336 (с @ yangxiaohua2009 ).

@callegar, пожалуйста, попробуйте эту ветку. Это не создаст карту, поскольку в ней отсутствует драйвер машины, но она должна настроить часть SOF.

Здравствуйте, имею ноутбук KUU с таким же звуковым устройством и кодеком, как мне это можно установить у себя в Linux системе для теста?
Hello, I have a KUU laptop with the same sound device and codec, how can I install this on my Linux system for a test?

[sergeyfil1]

Приветствую, скажите пожалуйста, когда примерно появиться поддержка этого устройства в ядре?
Hello, please tell me, when will support for this device appear in the kernel approximately?

[plbossart]

let's merge, this should land in the upstream kernel 5.16 at best (still missing the updated codec parts).

[sergeyfil1]

давайте объединимся, в лучшем случае это должно появиться в апстрим-ядре 5.16 (все еще отсутствуют обновленные части кодека).

А как можно с вами объединиться и что для этого нужно проделать?
And how can we unite with you and what needs to be done for this?

[sergeyfil1]

Привет, нашел установочные файлы для чипа и кодека es8316 - https://disk.yandex.ru/d/VD8W6Yruvx0flQ он похож с нашим чипом может в работе пригодиться.
Hi, I found the installation files for the chip and the es8316 codec - https://disk.yandex.ru/d/VD8W6Yruvx0flQ it is similar to our chip can be useful in the work.

[sergeyfil1]

адрес # 2955 сообщил @callegar

Это должно только вызвать загрузку драйвера SOF и предполагает, что файл прошивки установлен в / lib / firmware / intel / sof.
Файл топологии следует скопировать, например, с https://github.com/yangxiaohua2009/GLK-ES8336 (с @ yangxiaohua2009 )

@callegar, пожалуйста, попробуйте эту ветку. Это не создаст карту, поскольку в ней отсутствует драйвер машины, но она должна настроить часть SOF.

Привет, имею UBUNTU 21.04 скажите пожалуйста как эти файлы установить и в какую папку, можно по подробней инструкцию?
Hi, I have UBUNTU 21.04, please tell me how to install these files and in which folder, you can follow the instructions in more detail?

[glehmann]

has it landed in linux 5.16?