)]}'
{
  "commit": "ade49db337a9d44ac5835cfce1ee873549011b27",
  "tree": "48f0b0a4df47f786452f8c1e83e1862afae8bd8a",
  "parents": [
    "551626ec0ad28dc43cae3094c35be7088cc625ab"
  ],
  "author": {
    "name": "Takashi Iwai",
    "email": "tiwai@suse.de",
    "time": "Wed Jul 11 18:05:52 2018 +0200"
  },
  "committer": {
    "name": "Takashi Iwai",
    "email": "tiwai@suse.de",
    "time": "Mon Jul 22 09:13:56 2019 +0200"
  },
  "message": "ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI\n\nAMD/ATI and Nvidia HDMI codec drivers didn\u0027t have the audio component\nbinding like i915, but it worked only with the traditional HD-audio\nunsolicited event for the HDMI hotplug detection and the ELD read-up\nthereafter.  This has been a problem in many ways: first of all, it\ngoes through the hardware event transition (from GPU register write,\nHD-audio controller trigger, and finally to HD-audio unsolicited event\nhandling), which is often unreliable and may miss some opportunities.\nSecond, each unsol event handling and ELD read-up need the explicit\npower up / down when the codec is in the runtime suspend.  Last but\nnot least, which is the most important, the hotplug wakeup may be\nmissed when the HD-audio controller is in runtime suspend.  Especially\nthe last point is a big problem due to the recent change relevant with\nvga_switcheroo that forcibly enables the runtime PM for AMD HDMI\ncontrollers.\n\nThese issues are solved by introducing the audio component; the\nhotplug notification is done by a direct function callback, which is\nmore accurate and reliable, and it can be processed without the actual\nhardware access, i.e. no runtime PM trigger is needed, and the\nHD-audio gets the event even if it\u0027s in runtime suspend.  The same for\nELD query, as it\u0027s read directly from the cached ELD bytes stored in\nthe DRM driver, hence the whole hardware access can be skipped.\n\nSo here it is: this patch implements the audio component binding with\nAMD/ATI and Nouveau DRM drivers.  The biggest difference from i915\nimplementation is that this binding is fully optional and it can be\nenabled asynchronously on the fly.  That is, the driver will switch\nfrom the HD-audio unsolicited event to the notify callback once when\nthe DRM component gets bound.  Similarly, when DRM driver gets\nunloaded, the HDMI event handling returns to the legacy mode, too.\n\nAlso, another difference from i915 is that the new code registers the\ncomponent in the codec driver, while i915 HDMI codec assumes the\ncomponent binding was already done in the HD-audio controller driver.\nHence the new code does need to de-register the component binding at\nthe codec exit, too.\n\nSome other details:\n- The match component ops assumes that both VGA and HD-audio\n  controller PCI entries belong to the same PCI bus, and only accepts\n  such an entry.\n\n- The pin2port audio_ops is implemented with assumption of the fixed\n  widget layout.  For AMD, it\u0027s starting from 3, with step 2 (3, 5, 7,\n  ...), while for Nvidia, it\u0027s starting from 4, with step 1 (4, 5, 6,\n  ...)\n\nAs of this patch, the corresponding component isn\u0027t implemented in DRM\nside, so this change alone won\u0027t give any benefit.  By the following\nchanges in DRM sides, the mission will be completed.\n\nSigned-off-by: Takashi Iwai \u003ctiwai@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c380596b2e84c0079d7268e554dc7c645372278e",
      "old_mode": 33188,
      "old_path": "sound/pci/hda/patch_hdmi.c",
      "new_id": "2096993eaf285cfbd7160a96a137accd4d5b18f8",
      "new_mode": 33188,
      "new_path": "sound/pci/hda/patch_hdmi.c"
    }
  ]
}