[PATCH v2] ASoC: hdmi-codec: Add option for ELD bypass

[Mark Brown]

On Tue, May 03, 2022 at 10:38:52AM +0200, Maxime Ripard wrote:

> I think some more documentation is needed there to describe how it's
> going to be used.
> 
> Like, you mention that it's relevant when the EDID is not valid. But if
> the EDID is valid, is bypass still allowed or not?

I'd expect so given that it's explicitly an override and that it's not
like it's unknown for people to put nonsense in ID information.

> > +static int hdmi_codec_eld_bypass_put(struct snd_kcontrol *kcontrol,
> > +				     struct snd_ctl_elem_value *ucontrol)
> > +{
> > +	struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
> > +	struct hdmi_codec_priv *hcp = snd_soc_component_get_drvdata(component);
> > +
> > +	if (hcp->eld_bypass == ucontrol->value.integer.value[0])
> > +		return 0;
> > +
> > +	hcp->eld_bypass = ucontrol->value.integer.value[0];
> > +
> > +	return 1;
> > +}

> If the ELD bypass is set, how does it affect the hdmi_codec_params being
> passed to the codec?

Presumably we should tell the CODEC what we're trying to play (looks
like that's what the current code does)?

> Also, what is being returned to the userspace by hdmi_eld_ctl_get once
> the bypass is enabled?

My first thought would be that we'd always read whatever is there
rather than trying to make something up, bypass just says we're not
enforcing it.

> And shouldn't we call get_eld when we remove the bypass?

Or given what I just said above should we not change any get_eld() calls
but instead only change things so that we don't look at the ELD data
when setting constraints during startup() and during channel map
operations?  In that case we wouldn't need to read again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20220503/2227e14d/attachment.sig>