Re: [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: mengdong.lin@linux.intel.com, tiwai@suse.de,
	intel-gfx@lists.freedesktop.org, liam.r.girdwood@linux.intel.com,
	vinod.koul@intel.com, broonie@kernel.org,
	rakesh.a.ughreja@intel.com,
	David Henningsson <david.henningsson@canonical.com>
Subject: Re: [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface
Date: Fri, 11 Mar 2016 11:27:13 -0600	[thread overview]
Message-ID: <56E2FFF1.1010704@linux.intel.com> (raw)
In-Reply-To: <20160310180039.GC4329@intel.com>

Thanks for the review Ville

[snip]

> Kinda hard to see where everything gets used due to the way the patches
> are split up.

Yes, it's far from great...

> At least the hotplug/mode change events are not needed. We only have the
> two points where i915 should inform the audio driver about this stuff,
> and those are the intel_audio_code_enable/disable(). For that we
> already have the .pin_eld_notify() hook.
>
> The interrupt stuff should mostly vanish from i915 with the subdevice
> approach. As in i915 would just call the interrupt handler of the audio
> driver based on the LPE bits in IIR, and the audio driver can then do
> whatever it wants based on its own status register.

Are you saying that the subdevice would provide a read/write interface 
for the audio driver to look at display registers, and the i915 driver 
would only provide a notification interface (EDID and interrupts) to the 
audio driver?
If yes, would there be two component framework links, one between 
i915/audio driver and one between subdevice/audio driver.
I am way beyond my comfort zone, bear with me if this is silly.
Thanks.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx