AMD
Tot i que les GPU Radeon / AMD han estat millorant el suport de Linux amb els models de GPU més recents, el suport d’àudio s’ha descuidat lamentablement, fins ara. Recentment, un pegat va ser impulsat per Takashi Iwai de SUSE, que també manté el subsistema de so al nucli principal de Linux. El pegat tracta alguns problemes generals amb el suport d’àudio d’AMDGPU.
Els problemes actuals d’àudio AMDGPU giren al voltant d’algunes GPU perquè la compatibilitat d’àudio HDMI / DP es retardi gràcies al codi de visualització AMDGPU (DC / DAL) que ha de ser pegat al nucli, no s’admeten alguns formats d’àudio i errors generals en certes parts del pila de controladors. Tot i això, Takashi Iwai de SUSE ha publicat un conjunt de pegats per als controladors DRM de Radeon / AMDGPU.
El que fan aquests pegats és proporcionar compatibilitat amb components d’àudio DRM per als controladors de Radeon i AMDGPU Direct Rendering Manager: en poques paraules, el mode de component d’àudio DRM per a les interfícies HDMI i DisplayPort permetrà que es produeixin lectures d’extinció d’àudio i lectures ELD, sense accés al maquinari . Bàsicament, això significa que es pot permetre una correcta manipulació dels connectors en calent, fins i tot si el sistema està en mode de suspensió en temps d'execució. Tanmateix, els camins de codi AMDGPU DC no estan correctament reunits en el formulari de pegat actual.
De manera bàsica, només el Radeon i una part d’AMDGPU són abordats pel suport de correcció DC encara no ho és inclòs.
Takashi va explicar els pegats a fons a continuació:
Els controladors de còdecs HDMI AMD / ATI no tenien la vinculació de components d’àudio com l’i915, però només funcionava amb l’esdeveniment tradicional no sol·licitat d’àudio HD per a la detecció de connectors en calent HDMI i la lectura ELD posteriorment. Aquest ha estat un problema de moltes maneres: primer, passa per la transició d'esdeveniments de maquinari (des de l'escriptura de registres de la GPU, el disparador del controlador d'àudio HD i, finalment, fins a la gestió d'esdeveniments no sol·licitats d'àudio HD), que sovint no és fiable i pot faltar algunes oportunitats. En segon lloc, cada manipulació d’esdeveniments unsol i lectura ELD necessiten l’encesa / baixada explícita quan el còdec està en suspensió en temps d’execució. Per últim, però no menys important, que és el més important, és possible que es perdi el despertador del hotplug quan el controlador d’àudio HD estigui en suspensió en temps d’execució. Especialment, l'últim punt és un gran problema a causa del recent canvi rellevant amb vga_switcheroo que permet forçadament el PM en temps d'execució per als controladors HDMI AMD.
Aquests problemes es resolen introduint el component d’àudio; la notificació de connectivitat ràpida es fa mitjançant una devolució de trucada de funció directa, que és més precisa i fiable, i es pot processar sense l'accés real al maquinari, és a dir, no es necessita cap activador PM en temps d'execució i l'àudio HD obté l'esdeveniment encara que sigui en temps d'execució suspendre. El mateix per a la consulta ELD, ja que es llegeix directament des dels bytes ELD emmagatzemats al controlador DRM, de manera que es pot ometre l'accés complet al maquinari.
Així és: aquest pedaç implementa la vinculació de components d’àudio amb el controlador AMD / ATI DRM. La diferència més gran respecte a la implementació d’i915 és que aquesta vinculació és totalment opcional i es pot habilitar de manera asíncrona al moment. És a dir, el controlador passarà de l’esdeveniment no sol·licitat d’àudio HD a la devolució de trucada de notificació una vegada que el component DRM es vinculi. De la mateixa manera, quan es descarrega el controlador DRM, la gestió d'esdeveniments HDMI també torna al mode heretat.
A més, una altra diferència respecte a l’i915 és que l’AMD HDMI registra el component al controlador de còdecs, mentre que el còdec HDMI de l’i915 assumeix que la vinculació del component ja estava feta. Per tant, el codi AMD també anul·la la unió de components a la sortida del còdec. '
