AMD
Докато графичните процесори Radeon / AMD получават по-добра поддръжка на Linux с по-новите модели графични процесори, аудио поддръжката беше ужасно пренебрегвана - досега. Съвсем наскоро бе изтласкан пластир от Takashi Iwai на SUSE, който също поддържа звуковата подсистема в основното ядро на Linux. Пластирът разглежда някои общи проблеми с аудио поддръжката на AMDGPU.
Текущите проблеми със звука на AMDGPU се въртят около някои графични процесори, за да се забави аудиоподдръжката на HDMI / DP от AMDGPU дисплейния код (DC / DAL), който трябва да се закърпи в ядрото, като няколко аудио формата не се поддържат, а общи грешки в някои части стека на водача. Въпреки това, Takashi Iwai на SUSE пусна набор от кръпки за драйверите за Radeon / AMDGPU DRM.
Това, което правят тези кръпки, е да осигурят поддръжка на DRM аудио компоненти за драйверите Radeon и AMDGPU Direct Rendering Manager - накратко, режимът на DRM аудио компонент за интерфейси HDMI и DisplayPort ще позволи да се случват аудио горещи тапи и ELD четения, без хардуерен достъп . Това по същество означава, че може да бъде разрешено за правилно боравене с горещи контакти, дори ако системата е в режим на спиране по време на изпълнение. Въпреки това, кодовите пътища на AMDGPU DC не са правилно съставени в текущата форма на кръпка.
Така че основно само Radeon и част от AMDGPU са адресирани от кръпката - DC поддръжка все още не е включени.
Такаши обясни по-подробно корекциите по-долу:
Драйверите за кодеци на AMD / ATI HDMI нямаха свързване на аудио компоненти като i915, но работеха само с традиционното HD-аудио непоискано събитие за откриване на горещ щепсел HDMI и отчитане на ELD след това. Това е проблем в много отношения: на първо място, той преминава през хардуерния преход на събитие (от запис на регистър на графичния процесор, задействане на HD-аудио контролер и накрая до обработка на нежелани събития с HD-аудио), което често е ненадеждно и може да пропусне някои възможности. Второ, всяко обработване на нежелани събития и четене на ELD се нуждаят от изрично захранване нагоре / надолу, когато кодекът е в спирането на изпълнението. Не на последно място, което е и най-важното, събуждането на горещия щепсел може да бъде пропуснато, когато HD-аудио контролерът е в режим на спиране по време на работа. Особено последната точка е голям проблем поради скорошната промяна, свързана с vga_switcheroo, която принудително позволява изпълнението на PM за AMD HDMI контролери.
Тези проблеми се решават чрез въвеждане на аудио компонент; известието за hotplug се извършва чрез директно обратно извикване на функцията, което е по-точно и надеждно и може да бъде обработено без действителния достъп до хардуера, т.е. не е необходим спусък за изпълнение по време на работа, а HD-аудиото получава събитието, дори ако е в изпълнение спиране. Същото е и за ELD заявката, тъй като се чете директно от кешираните ELD байтове, съхранени в DRM драйвера, поради което целият достъп до хардуера може да бъде пропуснат.
И ето го: този пластир изпълнява свързването на аудио компоненти с AMD / ATI DRM драйвер. Най-голямата разлика от внедряването на i915 е, че това свързване е напълно незадължително и може да се активира асинхронно в движение. Това означава, че драйверът ще премине от HD-аудио непоискано събитие към уведомяване за обратно извикване веднъж, когато DRM компонентът бъде обвързан. По същия начин, когато драйверът за DRM се разтовари, обработката на събитията HDMI също се връща в наследения режим.
Също така, друга разлика от i915 е, че AMD HDMI регистрира компонента в драйвера на кодека, докато i915 HDMI кодекът предполага, че свързването на компонента вече е извършено. Следователно AMD кодът също премахва регистрацията на свързването на компонента при изхода на кодека. '
