Problemas de audio HD en los controladores AMDGPU reciben parche, DRM ahora puede manejar la conexión en caliente

Linux-Unix / Problemas de audio HD en los controladores AMDGPU reciben parche, DRM ahora puede manejar la conexión en caliente 2 minutos de lectura

AMD



Si bien las GPU Radeon / AMD han obtenido un mejor soporte de Linux con los modelos de GPU más nuevos, el soporte de audio se ha descuidado lamentablemente, hasta ahora. Recientemente, Takashi Iwai de SUSE introdujo un parche, quien también mantiene el subsistema de sonido en el núcleo principal de Linux. El parche resuelve algunos problemas generales con el soporte de audio de AMDGPU.

Los problemas actuales de audio de AMDGPU giran en torno a algunas GPU para que el soporte de audio HDMI / DP se retrase debido al código de visualización de AMDGPU (DC / DAL) que debe parchearse en el kernel, algunos formatos de audio no son compatibles y errores generales en ciertas partes del pila de controladores. Sin embargo, Takashi Iwai de SUSE ha lanzado un conjunto de parches para los controladores DRM Radeon / AMDGPU.



Lo que hacen estos parches es proporcionar compatibilidad con componentes de audio DRM para los controladores Radeon y AMDGPU Direct Rendering Manager; en pocas palabras, el modo de componente de audio DRM para interfaces HDMI y DisplayPort permitirá que se realicen lecturas de audio en caliente y ELD, sin acceso al hardware . Esto básicamente significa que se puede permitir el manejo correcto de la conexión en caliente, incluso si el sistema está en modo de suspensión en tiempo de ejecución. Sin embargo, las rutas del código DC de AMDGPU no se combinan correctamente en el formulario de parche actual.



Básicamente, el parche solo aborda Radeon y una parte de AMDGPU: soporte DC aún no esta incluido.



Takashi explicó los parches en profundidad a continuación:

Los controladores de códec AMD / ATI HDMI no tenían el componente de audio vinculante como i915, pero solo funcionaban con el evento no solicitado de audio HD tradicional para la detección de conexión en caliente HDMI y la lectura ELD a partir de entonces. Esto ha sido un problema de muchas maneras: en primer lugar, pasa por la transición de eventos de hardware (desde la escritura del registro de GPU, el disparador del controlador de audio HD y finalmente hasta el manejo de eventos no solicitados de audio HD), que a menudo no es confiable y puede fallar algunas oportunidades. En segundo lugar, cada manejo de eventos unsol y lectura de ELD necesita el encendido / apagado explícito cuando el códec está en suspensión en tiempo de ejecución. Por último, pero no menos importante, que es el más importante, la activación del hotplug puede perderse cuando el controlador de audio HD está en suspensión en tiempo de ejecución. Especialmente el último punto es un gran problema debido al reciente cambio relevante con vga_switcheroo que habilita por la fuerza el tiempo de ejecución PM para los controladores AMD HDMI.

Estos problemas se resuelven introduciendo el componente de audio; la notificación de conexión en caliente se realiza mediante una devolución de llamada de función directa, que es más precisa y confiable, y se puede procesar sin el acceso al hardware real, es decir, no se necesita un disparador PM en tiempo de ejecución, y el audio HD recibe el evento incluso si está en tiempo de ejecución suspender. Lo mismo para la consulta ELD, ya que se lee directamente de los bytes ELD almacenados en caché almacenados en el controlador DRM, por lo que se puede omitir todo el acceso al hardware.



Así que aquí está: este parche implementa el enlace del componente de audio con el controlador AMD / ATI DRM. La mayor diferencia con la implementación de i915 es que este enlace es totalmente opcional y se puede habilitar de forma asincrónica sobre la marcha. Es decir, el controlador cambiará del evento no solicitado de audio HD a la devolución de llamada de notificación una vez cuando el componente DRM se vincule. Del mismo modo, cuando se descarga el controlador DRM, el manejo de eventos HDMI también vuelve al modo heredado.

Además, otra diferencia con el i915 es que AMD HDMI registra el componente en el controlador del códec, mientras que el códec HDMI del i915 asume que el enlace del componente ya se realizó. Por lo tanto, el código AMD también anula el registro del enlace del componente en la salida del códec '.