[Intel-gfx] [PATCH] drm/i915/display: compute config for audio

[Ville Syrjälä]

On Wed, Aug 24, 2022 at 06:57:04PM +0300, Kai Vehmanen wrote:
> Hi,
> 
> On Wed, 24 Aug 2022, Jani Nikula wrote:
> 
> > On Wed, 24 Aug 2022, "Borah, Chaitanya Kumar" <chaitanya.kumar.borah at intel.com> wrote:
> > > In certain scenarios, we might have to filter out some audio
> > > configuration depending on HW limitation. For example, in
> > > GLK DP port more than 2 channels are not supported for audio.
> [...]
> > > +			for (i = 0; i < drm_eld_sad_count(temp_buf); i++, sad += 3) {
> > > +				if (!(intel_encoder->supported_sads & (1 << i)))
> > > +					memset(&sad[0], 0, 3);
> > 
> > Here's the main question I have about the change, really. The ELD
> > (literally EDID-like-data) and SAD are supposed to describe the *sink*
> > capabilities. Why are we filtering the data here, telling the audio
> > controller driver this is what the *sink* supports, when the limitation
> > comes from the *source*?
> > 
> > I could just be clueless about how audio works, but semantically this
> > feels the same as modifying the EDID based on what the *source*
> > supports.
> 
> I provided early input to this patchset and I think this is a pragmatic 
> approach to take. What the audio controller really wants is intersection 
> of capabilities supported both by source and the sink. E.g. no need to 
> advertise to the audio user-space about an audio format xyz, if the full 
> pipeline, including source and sink, cannot support it.

Yeah, I think filtering the SADs would probably be the right thing
to do, eg. depending on the available bandwidth given the current
display timings/etc.

However what this patch implements is some fairy tale constraint
of (GLK && DP && channels>2). I'm fairly sure no such limitation
exists in the hardware.

-- 
Ville Syrjälä
Intel