Re: [Intel-gfx] [PATCH v2 22/22] drm/i915/audio: Resume HSW/BDW HDA controller around ELD access

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Oct 14, 2022 at 01:51:47PM +0300, Kai Vehmanen wrote:
> Hi,
> 
> On Wed, 12 Oct 2022, Ville Syrjala wrote:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > On HSW/BDW the hardware ELD buffer does not work if the controller
> > is suspended. I'm not 100% which thing in there is needed to make it
> > work (at least just forcing the controller into D0 with setpci is
> > not enough). But a full runtime resume seems to do the trick here
> > at least, and so far it looks like this doesn't even deadlock or
> > anything.
> 
> excuse my lack of history information/context, but I also wonder how 
> important writing this to hw AUD_EDID_DATA is anymore. All platforms since 
> Sandy/Ivy Bridge have used the DRM component interface to query ELD (via 
> direct kernel call i915_audio_component_get_eld()). So I don't see any 
> usage of querying the ELD data via "legacy" AC_VERB_GET_HDMI_ELDD method 
> (as that does require powering on the audio controller and codec). At 
> least based on quick browse, I don't see this register having impact to 
> other things than said HDA verb implementation in hardware. May explain 
> why the issue has not been reported before.

I guess just trying to not write it and seeing what happens
is the best we can do.

Do all the platforms that use the software get_eld() stuff
totally ignore the hw buffer already in the audio driver?
Or do they still respond somehow when we toggle the valid 
bit?

If it's all getting ignored already then I'd like to stop
using the buffer for all ilk+. Just need to double check
that is where the split is also on the audio driver side.
Of if it's not that clear cut on the audio driver side
(and not easy to fix), then maybe we need to do the
cutoff at hsw+.

g4x I'd perhaps like to leave to use the hw buffer since I
think it can still take SDVO ADD2 cards (not sure any ilk+
can), so there is at least some kind of chance of someone
plugging in a HDMI ADD2 card (rare as those are). And since
SDVO depends on the hw buffer still we need to depend on it
for the native HDMI too, or else we'll have to convert absolutely
everything away from the hw buffer. That might be too much
hassle.

Anyways, I guess I'll be spooling up a few olders systems
and testing how they look w/o the buffer written at all.

-- 
Ville Syrjälä
Intel