Hi,
On Wed, 24 Aug 2022, Jani Nikula wrote:
> On Wed, 24 Aug 2022, "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@xxxxxxxxx> 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.
And in practise, as the constraints depend on active display
configuration, this is the only interface where we can pass such
information to ALSA.
Br, Kai
