Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1665308iob; Sat, 14 May 2022 16:30:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzOrVDRU6U8ZHNmQ4K107LrhP+uD6QrXGG29wLlAXojUbGxDLYnvlrceh3lItfuDaZhW+5 X-Received: by 2002:a1c:f717:0:b0:396:f89f:897c with SMTP id v23-20020a1cf717000000b00396f89f897cmr3290436wmh.165.1652571020285; Sat, 14 May 2022 16:30:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652571020; cv=none; d=google.com; s=arc-20160816; b=w7Fw4nTPh+OXOBZkBOiW7MeM0SEyYS0uwjSXv/dOWdWNZEF4pb7aHa3sFauYpHPSR1 y298kZsjKLcFPN0datNSRswnPcRr3/DIJF+AEC0dc/PkkdKgJtyj7KNO5vOOUnw8Mc3l TJ0nkxABN1QDUvUVMK4gVYsOtQT6FG5WRFV2kIe0GLF9xTMNRnMUd9N3A6965gXCkeAd iAYmH+1xehWo5SUOvDsOS0Ei/iJVQFMuhDO7J3eic9GIWwZOoxuNGVbXqshjTAe3b8hI dPRJYpXd9s5nEfQLmtdv5Q0GeeqLZefvJ+vO4bw45l/PRe0FLoAiKkzjo5/53tUI3mqT wTPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=MfAQi6qpEmOEcsn5MtBJKAAnIs5P1Ci1D7w77dxu4iQ=; b=Vn7C6NIx2Z9+8VMdkF9cHCgvLxJeRBnGLtQ+gW95DLcVsTnGF5pmNmIwQ5yWJiJMSM NzoJPfa4OaVnwhtKqZQFgs9va3+mEANRRyh9K4o4TnmfEmzW/iKf5ZivBefOVKkHNAjk rV1vg0rtHj4QrSIOCEfCuYErnpEHe92W+LfX8gkjhHi++BzkasAcUypyLNlOK4M+wSqs GgM1lmYdagRctydvAGW310+dXHd8eUt9M0Mtcp7OU56hD27ESIIR/lA1b8wZOO3wQ8Dr XUvi+4NGM6VwQ7C76VpPGkHa+3FWcYojr450iMcak7i4RY0xy6nFNWfBg31HSWRIQGZc 6yQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=rock-chips.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o13-20020a05600c4fcd00b00396fbf94ef9si1394304wmq.11.2022.05.14.16.29.42; Sat, 14 May 2022 16:30:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=rock-chips.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233720AbiENPUv (ORCPT + 99 others); Sat, 14 May 2022 11:20:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229606AbiENPUt (ORCPT ); Sat, 14 May 2022 11:20:49 -0400 Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 389E92F391 for ; Sat, 14 May 2022 08:20:47 -0700 (PDT) Received: from [192.168.3.48] (unknown [220.250.45.22]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id E939880017B; Sat, 14 May 2022 23:20:42 +0800 (CST) Message-ID: <7ff0ed31-6326-9dc8-6003-0aab8370ad0d@rock-chips.com> Date: Sat, 14 May 2022 23:20:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v2] ASoC: hdmi-codec: Add option for ELD bypass To: Mark Brown , Maxime Ripard Cc: Dmitry Osipenko , Jaroslav Kysela , Jiapeng Chong , Kuninori Morimoto , Liam Girdwood , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org References: <20220430134006.v2.1.Ide2a04ad0c123cc6990a63632e6f9bb7d7f9be13@changeid> <20220503083852.be2aihvkd3gestdw@houat> From: sugar zhang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUhPN1dZLVlBSVdZDwkaFQgSH1lBWRlJTU5WSElJGU9PH0tKHk xIVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWU9LSFVKSktITk9VS1kG X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Nk06Kxw6Sj05TU0JSzJLFwo8 HilPCRJVSlVKTU5JTk9KTU9IT0JJVTMWGhIXVQgOHBoJVQETGhUcOwkUGBBWGBMSCwhVGBQWRVlX WRILWUFZSUlLVUlOS1VPTlVJSVlXWQgBWUFIQkhONwY+ X-HM-Tid: 0a80c32859c3b03akuuue939880017b X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.