From: sugar zhang <sugar.zhang@rock-chips.com>
To: Mark Brown <broonie@kernel.org>, Maxime Ripard <maxime@cerno.tech>
Cc: Dmitry Osipenko <digetx@gmail.com>,
Jaroslav Kysela <perex@perex.cz>,
Jiapeng Chong <jiapeng.chong@linux.alibaba.com>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Takashi Iwai <tiwai@suse.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ASoC: hdmi-codec: Add option for ELD bypass
Date: Sat, 14 May 2022 23:20:45 +0800 [thread overview]
Message-ID: <7ff0ed31-6326-9dc8-6003-0aab8370ad0d@rock-chips.com> (raw)
In-Reply-To: <YnGUHcFOYrvcA2Ol@sirena.org.uk>
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.
prev parent reply other threads:[~2022-05-14 15:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-30 5:41 Sugar Zhang
2022-05-03 8:38 ` Maxime Ripard
2022-05-03 20:44 ` Mark Brown
2022-05-14 15:20 ` sugar zhang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ff0ed31-6326-9dc8-6003-0aab8370ad0d@rock-chips.com \
--to=sugar.zhang@rock-chips.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=digetx@gmail.com \
--cc=jiapeng.chong@linux.alibaba.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime@cerno.tech \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®