AMD
Radeon / AMD GPUは新しいGPUモデルでより良いLinuxサポートを取得していますが、オーディオサポートは今までひどく無視されてきました。パッチは、Linuxのメインラインカーネルでサウンドサブシステムも管理しているSUSEの岩井隆によって最近プッシュされました。 パッチ AMDGPUのオーディオサポートに関するいくつかの全体的な問題に対処します。
現在のAMDGPUオーディオの問題は、一部のGPUを中心に展開しており、カーネルにパッチを適用する必要があるAMDGPUディスプレイコード（DC / DAL）によってHDMI / DPオーディオのサポートが遅延している、いくつかのオーディオ形式がサポートされていない、およびドライバースタック。ただし、SUSEの岩井隆はRadeon / AMDGPUDRMドライバー用の一連のパッチをリリースしました。
これらのパッチが行うことは、RadeonおよびAMDGPUダイレクトレンダリングマネージャードライバーのDRMオーディオコンポーネントサポートを提供することです。簡単に言えば、HDMIおよびDisplayPortインターフェイスのDRMオーディオコンポーネントモードでは、オーディオホットプラグおよびELDの読み取りが可能になります。 ハードウェアアクセスなし 。これは基本的に、システムがランタイムサスペンドモードにある場合でも、正しいホットプラグ処理を許可できることを意味します。ただし、AMDGPU DCコードパスは、現在のパッチ形式で適切にまとめられていません。
したがって、基本的に、RadeonとAMDGPUの一部のみがパッチで対処されます–DCサポート まだです 含まれています。
タカシはパッチについて以下に詳しく説明しました。
AMD / ATI HDMIコーデックドライバには、i915のようなオーディオコンポーネントバインディングはありませんでしたが、HDMIホットプラグ検出とその後のELD読み取りのための従来のHDオーディオ非送信請求イベントでのみ機能しました。これは多くの点で問題になっています。まず、ハードウェアイベントの移行（GPUレジスタの書き込み、HDオーディオコントローラーのトリガー、最後にHDオーディオの一方的なイベント処理へ）を経ますが、これは信頼性が低く、見逃される可能性があります。いくつかの機会。次に、コーデックがランタイムサスペンド状態にある場合、各unsolイベント処理とELD読み取りには、明示的な電源投入/停止が必要です。最後になりましたが、最も重要なことですが、HDオーディオコントローラーがランタイムサスペンド状態にある場合、ホットプラグウェイクアップが見落とされる可能性があります。特に最後の点は、AMDHDMIコントローラーのランタイムPMを強制的に有効にするvga_switcherooに関連する最近の変更による大きな問題です。
これらの問題は、オーディオコンポーネントを導入することで解決されます。ホットプラグ通知は、より正確で信頼性の高い直接関数コールバックによって実行され、実際のハードウェアアクセスなしで処理できます。つまり、ランタイムPMトリガーは不要であり、HDオーディオはランタイムであってもイベントを取得します。サスペンド。 ELDクエリの場合も同じです。DRMドライバに格納されているキャッシュされたELDバイトから直接読み取られるため、ハードウェアアクセス全体をスキップできます。
つまり、このパッチは、AMD / ATIDRMドライバーとのオーディオコンポーネントバインディングを実装します。 i915実装との最大の違いは、このバインディングは完全にオプションであり、オンザフライで非同期に有効にできることです。つまり、DRMコンポーネントがバインドされると、ドライバーはHDオーディオの非送信請求イベントから通知コールバックに1回切り替わります。同様に、DRMドライバーがアンロードされると、HDMIイベント処理もレガシーモードに戻ります。
また、i915とのもう1つの違いは、AMD HDMIがコンポーネントをコーデックドライバに登録するのに対し、i915HDMIコーデックはコンポーネントのバインドがすでに行われていることを前提としていることです。したがって、AMDコードは、コーデック出口でのコンポーネントバインディングの登録も解除します。」
