HD Audio Issues in AMDGPU Drivers Receive Patch, DRM Can Now Handle Hot-Plugging

While Radeon / AMD GPU’s have been getting better Linux support with newer GPU models, the audio support has been woefully neglected – until now. A patch was just recently pushed by SUSE’s Takashi Iwai, who also maintains the sound subsystem in Linux’s mainline kernel. The patch addresses some overall issues with AMDGPU’s audio support.

Current AMDGPU audio issues revolve around some GPUs to have HDMI/DP audio support being delayed by the AMDGPU Display Code (DC / DAL) needing to be patched into the kernel, a few audio formats being unsupported, and overall bugs in certain parts of the driver stack. However, SUSE’s Takashi Iwai has released a set of patches for the Radeon / AMDGPU DRM drivers.

What these patches do is provide DRM audio component support for the Radeon and AMDGPU Direct Rendering Manager drivers – in a nutshell, the DRM audio component mode for HDMI and DisplayPort interfaces will allow for audio hot-plug and ELD read-outs to happen, without hardware access. This basically means that it can be allowed for correct hot-plug handling, even if the system is in a run-time suspend mode. However, the AMDGPU DC code paths are not properly put together in the current patch form.

So basically, only Radeon and a part of AMDGPU is addressed by the patch – DC support is not yet included.

Takashi explained the patches in-depth below:

AMD/ATI HDMI codec drivers didn’t have the audio component binding like i915, but it worked only with the traditional HD-audio unsolicited event for the HDMI hotplug detection and the ELD read-up thereafter. This has been a problem in many ways: first of all, it goes through the hardware event transition (from GPU register write, HD-audio controller trigger, and finally to HD-audio unsolicited event handling), which is often unreliable and may miss some opportunities. Second, each unsol event handling and ELD read-up need the explicit power up / down when the codec is in the runtime suspend. Last but not least, which is the most important, the hotplug wakeup may be missed when the HD-audio controller is in runtime suspend. Especially the last point is a big problem due to the recent change relevant with vga_switcheroo that forcibly enables the runtime PM for AMD HDMI controllers.

These issues are solved by introducing the audio component; the hotplug notification is done by a direct function callback, which is more accurate and reliable, and it can be processed without the actual hardware access, i.e. no runtime PM trigger is needed, and the HD-audio gets the event even if it’s in runtime suspend. The same for ELD query, as it’s read directly from the cached ELD bytes stored in the DRM driver, hence the whole hardware access can be skipped.

So here it is: this patch implements the audio component binding with AMD/ATI DRM driver. The biggest difference from i915 implementation is that this binding is fully optional and it can be enabled asynchronously on the fly. That is, the driver will switch from the HD-audio unsolicited event to the notify callback once when the DRM component gets bound. Similarly, when DRM driver gets unloaded, the HDMI event handling returns to the legacy mode, too.

Also, another difference from i915 is that AMD HDMI registers the component in the codec driver, while i915 HDMI codec assumes the component binding was already done. Hence AMD code does de-register the component binding at the codec exit, too.”

The post HD Audio Issues in AMDGPU Drivers Receive Patch, DRM Can Now Handle Hot-Plugging appeared first on Appuals.com.