drm/i915/audio: Don't program the hardware ELD buffer on hsw+
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Tue, 24 Jan 2023 14:46:17 +0000 (16:46 +0200)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Wed, 25 Jan 2023 10:23:47 +0000 (12:23 +0200)
commit68470541e630bb43f047cd372cc49489c0e82084
tree20ee45798667b3dfac11b0c696869fa66ef8c363
parent343cb0f9234ec5f5d86e47c33d2c6fa649cef2fa
drm/i915/audio: Don't program the hardware ELD buffer on hsw+

Since we use the audio component to transfer the ELD to the audio
driver on hsw+ platforms there is no point in even programming
the hardware ELD buffer. Stop doing so.

The one slight caveat here is that this is not strictly legal
according to the HDA spec. PD=1;ELD=0 is only documented as
an intermediate state during modeset. But if there is no hardware
that depends on that then I guess we're fine. Or we could
perhaps set ELD=1 without actually programming the buffer?

Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 ->
PD=1;ELD=1 is also not strictly correct according to the HDA
spec, as the only documented transition from PD=0;ELD=0 is
straight to PD=1;ELD=1.

Additionally on hsw/bdw the hardware buffer is tied in with the
dedicated display HDA controller's power state, so currently
we mostly fail at proramming the buffer anyway. When the HDA
side is not sufficiently powered up the ELD address bits get
stuck and the ELD data register accesses go nowhere.

Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
References: https://lore.kernel.org/intel-gfx/20221012104936.30911-1-ville.syrjala@linux.intel.com/
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124144628.4649-3-ville.syrjala@linux.intel.com
drivers/gpu/drm/i915/display/intel_audio.c