Заметил, что в kernel-image-un-def 6.6 в sound/soc/intel/boards/sof_es8336.c больше нет костылей и подпорок ("quirks") для различного российского оборудования. Вот эти: https://git.altlinux.org/gears/k/kernel-image-std-def.git?p=kernel-image-std-def.git;a=blob_plain;f=sound/soc/intel/boards/sof_es8336.c;h=d2a8309c3d520d97fb3e9a1747fa374dd7786beb;hb=882bb4ce852b88412e92bf6d508b19acdcee29e3 static const struct dmi_system_id sof_es8336_quirk_table[] = { { .callback = sof_es8336_quirk_cb, .ident = "pa-enable ACPI deviant", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "3Logic Group"), DMI_MATCH(DMI_PRODUCT_NAME, "Graviton N15i"), }, .driver_data = (void *)(SOF_ES8336_SSP_CODEC(0) | SOF_ES8336_TGL_GPIO_QUIRK) }, { .callback = sof_es8336_quirk_cb, .ident = "pa-enable ACPI deviant", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "3Logic Group"), DMI_MATCH(DMI_PRODUCT_NAME, "Graviton N15i-K2"), }, .driver_data = (void *)(SOF_ES8336_SSP_CODEC(0) | SOF_ES8336_TGL_GPIO_QUIRK) }, { .callback = sof_es8336_quirk_cb, .ident = "pa-enable ACPI deviant", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "3Logic Group"), DMI_MATCH(DMI_PRODUCT_NAME, "Lime 15.6"), }, .driver_data = (void *)(SOF_ES8336_SSP_CODEC(0) | SOF_ES8336_TGL_GPIO_QUIRK) }, { .callback = sof_es8336_quirk_cb, .matches = { /* market name: Aquarius Cmp NS685U R11 */ DMI_MATCH(DMI_SYS_VENDOR, "Aquarius"), DMI_MATCH(DMI_PRODUCT_NAME, "NS685U R11"), }, .driver_data = (void *)(SOF_ES8336_SSP_CODEC(0) | SOF_ES8336_JD_INVERTED) }, { .callback = sof_es8336_quirk_cb, .matches = { DMI_MATCH(DMI_SYS_VENDOR, "CHUWI Innovation And Technology"), DMI_MATCH(DMI_BOARD_NAME, "Hi10 X"), }, .driver_data = (void *)SOF_ES8336_SSP_CODEC(2) }, { .callback = sof_es8336_quirk_cb, .ident = "pa-enable ACPI deviant", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "DEPO Computers"), DMI_MATCH(DMI_PRODUCT_NAME, "DPC156"), }, .driver_data = (void *)(SOF_ES8336_SSP_CODEC(0) | SOF_ES8336_TGL_GPIO_QUIRK) }, Так задумано или случайно потеряли?
Вот эту подпорку { .callback = sof_es8336_quirk_cb, .matches = { /* market name: Aquarius Cmp NS685U R11 */ DMI_MATCH(DMI_SYS_VENDOR, "Aquarius"), DMI_MATCH(DMI_PRODUCT_NAME, "NS685U R11"), }, .driver_data = (void *)(SOF_ES8336_SSP_CODEC(0) | SOF_ES8336_JD_INVERTED) }, можно написать чуть иначе: .driver_data = (void *)(SOF_ES8336_JD_INVERTED) Не знаю, рабочий ли ваш вариант, но SOF_ES8336_JD_INVERTED точно работало https://abf.io/import/kernel-6.1/blob/beefa777f9/0403-ASoC-Intel-sof_es8336-Add-a-quirk-for-Aquarius-NS685.patch
В какой версии ядра это было?
(Ответ для Vitaly Chikunov на комментарий #2) > В какой версии ядра это было? Не помню. В 6.1, кажется.
Похоже эти изменения были только до kernel-image-un-def-5.15.84-alt1 (p10). Затем они были заменены обновлением драйвера https://lists.altlinux.org/pipermail/devel-kernel/2022-December/007798.html
По ссылке нет замены, там просто удаление.
(Ответ для Vitaly Chikunov на комментарий #4) > Похоже эти изменения были только до kernel-image-un-def-5.15.84-alt1 (p10). > Затем они были заменены обновлением драйвера > https://lists.altlinux.org/pipermail/devel-kernel/2022-December/007798.html Похоже, что при copy driver source code from kernel v6.0.9 просто потеряли правки, сделанные поверх бекпортированного в старые ядра es8336. У вас там был сделанный Виталием из Аквариуса бекпорт, мне кажется, если правильно помню. А я в Росиное ядро 5.15 (https://abf.io/import/kernel-5.15/tree/rosa2021.1) вместо использования его бекпорта по-коммитово перенес изменения в es8336 и, посмотрев, как сделано в Альтовом ядре, добавил quirk. В Росином ядре 6.1 (https://abf.io/import/kernel-6.1/tree/rosa2021.1) уже нет бекпортов es8336 (как раз из района примерно 6.1 бекпортировали в 5.15), но есть патч с добавлением quirk. Не могу вспомнить или найти информацию, тестировали ли Росу с 6.1 на железе или нет. Но 5.15 точно тестировали, а код в 5.15 был перенесен из ~6.1, патч для quirk нужен на 5.15, значит он нужен и на 6.1. Вот это в Альте было, очевидно, сделано для того же оборудования: https://git.altlinux.org/gears/f/firmware-alsa-sof.git?p=firmware-alsa-sof.git;a=commitdiff;h=3e1039d55a64f83cb43fdacbef2b9f4c6857557e
@nickel @kovalev скажите, пожалуйста, почему вы отревертили эти квирки?
(Ответ для mikhailnov на комментарий #0) > Заметил, что в kernel-image-un-def 6.6 в sound/soc/intel/boards/sof_es8336.c > больше нет костылей и подпорок ("quirks") для различного российского > оборудования. > Так задумано или случайно потеряли? Большинство квирков стали не актуальны после обновления драйвера. (Ответ для Vitaly Chikunov на комментарий #7) > @nickel @kovalev скажите, пожалуйста, почему вы отревертили эти квирки? Для 6.6 ядра мы не добавляли и не ревертили квирки.
(In reply to Vasiliy Kovalev from comment #8) > Большинство квирков стали не актуальны после обновления драйвера. Спасибо за ответ. Я так и предполагал.
А как вы определили, что квирки перестали быть актуальными?
(Ответ для mikhailnov на комментарий #10) > А как вы определили, что квирки перестали быть актуальными? Заметьте "Большинство" квирков, а это из приведенной таблицы 3Logic Group, DEPO Computers и CHUWI. Для Aquarius проблема остается и на ядре 6.6, например, не решена.
Мне казалось, что драйвер не менялся как либо, чтоб квирки могли быть перестать актуальны. Получается, вы проверили функционально, и теперь работает без них? Для Аквариуса рабочее решение в Росе, ссылка в комментарии 1.
https://abf.io/import/kernel-6.6 - здесь патчи для Аквариуса, перенесенные из 6.1, но пока не было возможности проверить их на железе.
(Ответ для mikhailnov на комментарий #12) > Мне казалось, что драйвер не менялся как либо, чтоб квирки могли быть > перестать актуальны. Получается, вы проверили функционально, и теперь > работает без них? Ага > Для Аквариуса рабочее решение в Росе, ссылка в комментарии 1. Я имел ввиду проблема не решена в апстриме. > https://abf.io/import/kernel-6.6 - здесь патчи для Аквариуса, перенесенные из 6.1, но пока не было возможности проверить их на железе. В этих ноутбуках кодеки es8326 и именно с ними проблемы на 6.1 и выше. Мы еще не портировали на 6-ые ядра квирки и на текущий момент рабочая ветка протестированных моделей для тасков https://git.altlinux.org/people/kovalev/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/branch-kovalev_es8326_6.1.x_new Там же можете проверить и модель из вашего патча.
(Ответ для Vasiliy Kovalev на комментарий #14) > (Ответ для mikhailnov на комментарий #12) > > Мне казалось, что драйвер не менялся как либо, чтоб квирки могли быть > > перестать актуальны. Получается, вы проверили функционально, и теперь > > работает без них? > > Ага Интересно, почему так... > > > Для Аквариуса рабочее решение в Росе, ссылка в комментарии 1. > > Я имел ввиду проблема не решена в апстриме. С одной стороны, было бы неплохо заапстримить квирки, но с другой — не очень понятно, как поддерживать их актуальность в апстриме. > > > https://abf.io/import/kernel-6.6 - здесь патчи для Аквариуса, перенесенные из 6.1, но пока не было возможности проверить их на железе. > > В этих ноутбуках кодеки es8326 и именно с ними проблемы на 6.1 и выше. > Мы еще не портировали на 6-ые ядра квирки и на текущий момент рабочая ветка > протестированных моделей для тасков > https://git.altlinux.org/people/kovalev/packages/?p=kernel-image.git; > a=shortlog;h=refs/heads/branch-kovalev_es8326_6.1.x_new > Там же можете проверить и модель из вашего патча. Спасибо, посмотрел, у меня: DMI_MATCH(DMI_PRODUCT_NAME, "NS685U R11") и это же оборудование: DMI_MATCH(DMI_PRODUCT_NAME, "win10 HOME rs10") А у вас: DMI_MATCH(DMI_BOARD_NAME, "NS685") Без U модель не находится (https://yandex.ru/search/?text=aquarius+NS685). Либо у кого-то из нас ошибка, либо в природе сущеcтвуют оба варианта (плюс третий - "win10 HOME rs10").
"NS685U R11" точно существует: https://linux-hardware.org/?probe=339dc3db60&log=dmidecode
(Ответ для mikhailnov на комментарий #15) > > Спасибо, посмотрел, у меня: > DMI_MATCH(DMI_PRODUCT_NAME, "NS685U R11") > А у вас: > DMI_MATCH(DMI_BOARD_NAME, "NS685") "NS685" у нас - начальные буквы названия материнской платы (DMI_BOARD_NAME), если посмотреть здесь (https://linux-hardware.org/?probe=339dc3db60&log=dmidecode) - полное название у вас "NS685Uv3", тогда как у нас на тестировании была модель: Manufacturer: Aquarius Product Name: CMP NS685U_4 Board Name: NS685IS4 то есть, по DMI_MATCH пройдут обе модели. > и это же оборудование: > DMI_MATCH(DMI_PRODUCT_NAME, "win10 HOME rs10") > > Без U модель не находится (https://yandex.ru/search/?text=aquarius+NS685). > Либо у кого-то из нас ошибка, либо в природе сущеcтвуют оба варианта (плюс > третий - "win10 HOME rs10"). У вас "win10 HOME rs10" - название модели (DMI_PRODUCT_NAME) из данных "System Information" (https://linux-hardware.org/?probe=988e1b3035&log=dmidecode). Альтернатива - использовать "EM_CM525_PRO_V2.0" (DMI_BOARD_NAME) из "Base Board Information", или обрезать до "EM_CM525_PRO" для других ревизий: + DMI_MATCH(DMI_SYS_VENDOR, "Aquarius"), + DMI_MATCH(DMI_BOARD_NAME, "EM_CM525_PRO"), Заодно уйдет и сомнительное "win10" из названия. Такой модели у нас не было, расширю список, и вам спасибо. > С одной стороны, было бы неплохо заапстримить квирки, но с другой — не очень > понятно, как поддерживать их актуальность в апстриме. Да, здесь двойная проблема - непредсказуемость названий материнских плат (например, NS685 и EM_CM525_PRO для похожих моделей), что породит большое кол-во патчей, что вызовет подозрения, и другая - это всё же костыли, правильное решение - хранить специфичные конфигурационные параметры в прошивке биос и правильно интерпретировать их драйвером. Отсюда, либо драйвер недоработан, либо разработчики биос что-то упустили.
(Ответ для Vasiliy Kovalev на комментарий #17) > (Ответ для mikhailnov на комментарий #15) > > > > Спасибо, посмотрел, у меня: > > DMI_MATCH(DMI_PRODUCT_NAME, "NS685U R11") > > А у вас: > > DMI_MATCH(DMI_BOARD_NAME, "NS685") > > "NS685" у нас - начальные буквы названия материнской платы (DMI_BOARD_NAME), > если посмотреть здесь > (https://linux-hardware.org/?probe=339dc3db60&log=dmidecode) - > полное название у вас "NS685Uv3", тогда как у нас на тестировании была > модель: > Manufacturer: Aquarius > Product Name: CMP NS685U_4 > Board Name: NS685IS4 > > то есть, по DMI_MATCH пройдут обе модели. Спасибо за пояснение, не заметил замылившимся глазом, что в одном месте DMI_PRODUCT_NAME, а в другом DMI_BOARD_NAME, и думал, что DMI_MATCH - это точное соответствие, а это поиск вхождения подстроки в строку. > > > и это же оборудование: > > DMI_MATCH(DMI_PRODUCT_NAME, "win10 HOME rs10") > > > > Без U модель не находится (https://yandex.ru/search/?text=aquarius+NS685). > > Либо у кого-то из нас ошибка, либо в природе сущеcтвуют оба варианта (плюс > > третий - "win10 HOME rs10"). > > У вас "win10 HOME rs10" - название модели (DMI_PRODUCT_NAME) > из данных "System Information" > (https://linux-hardware.org/?probe=988e1b3035&log=dmidecode). > Альтернатива - использовать "EM_CM525_PRO_V2.0" (DMI_BOARD_NAME) из > "Base Board Information", или обрезать до "EM_CM525_PRO" для других ревизий: > > + DMI_MATCH(DMI_SYS_VENDOR, "Aquarius"), > + DMI_MATCH(DMI_BOARD_NAME, "EM_CM525_PRO"), > > Заодно уйдет и сомнительное "win10" из названия. > > Такой модели у нас не было, расширю список, и вам спасибо. > > > С одной стороны, было бы неплохо заапстримить квирки, но с другой — не очень > > понятно, как поддерживать их актуальность в апстриме. > > Да, здесь двойная проблема - непредсказуемость названий материнских плат > (например, NS685 и EM_CM525_PRO для похожих моделей), что породит большое > кол-во патчей, что вызовет подозрения, и другая - это всё же костыли, > правильное решение - хранить специфичные конфигурационные параметры в > прошивке биос и правильно интерпретировать их драйвером. Отсюда, либо > драйвер недоработан, > либо разработчики биос что-то упустили. Интересная мысль, попробую выяснить у инженеров Everest Semiconductor, возможно ли такое, вроде бы есть связь с ними.
