Problèmes audio HD dans les pilotes AMDGPU reçoivent le correctif, DRM peut désormais gérer le branchement à chaud

Linux-Unix / Problèmes audio HD dans les pilotes AMDGPU reçoivent le correctif, DRM peut désormais gérer le branchement à chaud 2 minutes de lecture

AMD



Alors que les GPU Radeon / AMD bénéficient d'une meilleure prise en charge de Linux avec les nouveaux modèles de GPU, la prise en charge audio a été malheureusement négligée - jusqu'à présent. Un correctif a été récemment mis en place par Takashi Iwai de SUSE, qui gère également le sous-système son dans le noyau principal de Linux. Le patch résout certains problèmes généraux liés à la prise en charge audio d'AMDGPU.

Les problèmes audio AMDGPU actuels tournent autour de certains GPU pour que la prise en charge audio HDMI / DP soit retardée par le code d'affichage AMDGPU (DC / DAL) devant être patché dans le noyau, quelques formats audio non pris en charge et des bogues globaux dans certaines parties du pile de pilotes. Cependant, Takashi Iwai de SUSE a publié un ensemble de correctifs pour les pilotes DRM Radeon / AMDGPU.



Ces correctifs fournissent une prise en charge des composants audio DRM pour les pilotes Radeon et AMDGPU Direct Rendering Manager - en un mot, le mode de composant audio DRM pour les interfaces HDMI et DisplayPort permettra des lectures audio hot-plug et ELD, sans accès matériel . Cela signifie essentiellement qu'il peut être autorisé pour une gestion correcte de la connexion à chaud, même si le système est en mode de suspension d'exécution. Cependant, les chemins de code AMDGPU DC ne sont pas correctement assemblés dans le formulaire de correctif actuel.



Donc, fondamentalement, seuls Radeon et une partie d'AMDGPU sont traités par le patch - support DC n'est pas encore inclus.



Takashi a expliqué les correctifs en détail ci-dessous:

Les pilotes de codec AMD / ATI HDMI n’avaient pas la liaison de composant audio comme i915, mais cela fonctionnait uniquement avec l’événement non sollicité audio HD traditionnel pour la détection de hotplug HDMI et la lecture ELD par la suite. Cela a posé un problème à bien des égards: tout d'abord, cela passe par la transition d'événement matériel (de l'écriture de registre GPU, du déclenchement du contrôleur audio HD et enfin à la gestion des événements non sollicités HD-audio), qui est souvent peu fiable et peut manquer quelques opportunités. Deuxièmement, chaque gestion d'événement unsol et lecture ELD ont besoin de la mise sous / hors tension explicite lorsque le codec est en suspension d'exécution. Dernier point mais non le moindre, qui est le plus important, le réveil du hotplug peut être manqué lorsque le contrôleur audio HD est en suspension d'exécution. En particulier, le dernier point est un gros problème en raison du changement récent concernant vga_switcheroo qui active de force le PM d'exécution pour les contrôleurs HDMI AMD.

Ces problèmes sont résolus en introduisant le composant audio; la notification hotplug est effectuée par un rappel de fonction direct, qui est plus précis et fiable, et elle peut être traitée sans l'accès matériel réel, c'est-à-dire qu'aucun déclencheur PM à l'exécution n'est nécessaire, et l'audio HD obtient l'événement même s'il est en cours d'exécution suspendre. Il en va de même pour la requête ELD, car elle est lue directement à partir des octets ELD mis en cache stockés dans le pilote DRM, par conséquent tout l’accès au matériel peut être ignoré.



La voici donc: ce patch implémente la liaison de composant audio avec le pilote AMD / ATI DRM. La plus grande différence par rapport à l'implémentation i915 est que cette liaison est entièrement facultative et qu'elle peut être activée de manière asynchrone à la volée. Autrement dit, le pilote passera de l'événement non sollicité HD-audio au rappel de notification une fois lorsque le composant DRM sera lié. De même, lorsque le pilote DRM est déchargé, la gestion des événements HDMI revient également au mode hérité.

En outre, une autre différence par rapport à i915 est qu'AMD HDMI enregistre le composant dans le pilote du codec, tandis que le codec HDMI i915 suppose que la liaison du composant a déjà été effectuée. Par conséquent, le code AMD désenregistre également la liaison du composant à la sortie du codec. »