Radeon/AMDGPU DRM Drivers Get HD Audio Component Support

If there is one part of the Radeon/AMDGPU open-source graphics driver stack that feels like it's been somewhat neglected over time has been the HDMI/DP audio support. Fortunately, another improvement is on the way for bettering it.

The AMDGPU audio issues have ranged from having to wait a long time on some GPUs for having HDMI/DP audio support that works due to being held up by the AMDGPU Display Code (DC / formerly DAL) to be merged into the kernel, various audio formats not being supported, and bugs seeming more prevalent than other areas of the driver stack. Fortunately, SUSE's Takashi Iwai who is also the maintainer of the sound subsystem in the mainline kernel has volleyed a set of new Radeon/AMDGPU DRM patches today.

These patches provide DRM audio component support with the Radeon and AMDGPU Direct Rendering Manager drivers. The DRM audio component mode for HDMI and DisplayPort interfaces allows for audio hot-plug and ELD read-out to happen without the hardware access. In particular, this can allow for proper hot-plug handling even when the system is in a run-time suspend mode. But in the current patch form, the AMDGPU DC code paths are not yet wired up.

Takashi posted the patches today for review. He further explained in the patches:

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.

As we're about at the cut-off of new feature material to be merged in DRM-Next, this audio component support for Radeon/AMDGPU will likely not materialize until the Linux 5.0 kernel cycle.