ALT Linux Bugzilla – #49475

Вот эту подпорку

	{
		.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, возможно ли такое, вроде бы есть связь с ними.