On 2015-07-21 19:37, R, Durgadoss wrote:
Hi David,
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of David Henningsson Sent: Tuesday, July 21, 2015 1:27 PM To: alsa-devel@alsa-project.org; intel-gfx@lists.freedesktop.org; tiwai@suse.de; Vetter, Daniel; jani.nikula@linux.intel.com Cc: Koul, Vinod; David Henningsson Subject: [Intel-gfx] [PATCH 0/4] i915 to call hda driver on HDMI plug/unplug
This patch set aims to resolve three problems:
The first - and most serious one - is that the audio driver is not woken up properly when in power save modes, especially not when the HDA controller is in D3. By having the i915 driver call directly into the hda driver, the HDA driver is always notified that an HDMI hotplug event has happened.
Second, there is currently no way for userspace to match an HDMI audio output with an HDMI video output. We fix this by sending connector_type and connector_type_id in the HDMI hotplug callback.
Third, writing ELD info to the hardware just so the HDA driver can read it from the hardware seems a bit inefficient. We could just pass that information in the callback, too.
The patch in its current form fixes the first of these problems and provides most of the infrastructure for the second and third problem.
The patch set is based on 4.2rc2 + my recent codec wakeup patch. So far, it has been tested (and working) on one Skylake machine.
I believe you tested these patches with hda driver after few cycles of D3. By any chance, did you also try this once after i915 driver's D3 cycle also ? In this case, can the check_presence_and_report() function get the pin presence and ELD valid bits read out properly..?
When running this code with drm.debug=0xe, I can see a lot of calls to set different power wells on and off, to the extent that I don't keep track of them.
So I assume that means that the i915 driver goes into D3 as well during my tests.