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@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.
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
