Hi Mark, Maxime,
在 2022/5/4 4:44, 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.
I agree this idea that just don't use it for constraints and channel map
or something else.
but still do get_eld() as it was. will do in v3.
--
Best Regards!
张学广/Sugar
瑞芯微电子股份有限公司
Rockchip Electronics Co., Ltd.