Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4109704pxb; Sat, 13 Feb 2021 22:48:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJwwSON+WKW/Y4od5afQoRS+egU5WmBBNjn8SwaCM+wtThxGxkUA2ULp5OAOj0U6lMh3SRQS X-Received: by 2002:a17:906:3e14:: with SMTP id k20mr10125517eji.42.1613285304821; Sat, 13 Feb 2021 22:48:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613285304; cv=none; d=google.com; s=arc-20160816; b=B3CvPnD6ItEaZ9avWYQ4ZaFfEINnWPkR3BMiiJnrCePZ2GK61r8UYBK5SM016mocMr Dtx2vl1PxoIpUEYjFpUdQGj7hPtSRc4IIjVCayhh+zl/KW4s1ks+39W4OfbtNHX2Ppyh CI7X7Tmcr+DV88bjKl/Uv6Y4VFCMoUu+KFiU+08WhMbkzqiJo2eNlW2p+2Hw2goCaH07 5RMgeH2XNsrFjxdXc08BuHy4PFlIRIVaWNywXt6IrH6luGRrVjxPo77HokfryMidCT9g ndrU9Kp9LSkIGhuMr8nyoWHO0mA14WYdNzqHyuBbj1RU+IPXHQbeVgJQVMrbr3OJvuqC hHBA== 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 :mime-version:user-agent:date:message-id:from:references:cc:to :subject:dkim-signature; bh=aUQN0SZkwCC+2sHkMRBo4eVveaM2m59ClyPi/TCSgJI=; b=tLInvLAw2tNTExwisBcY+vvkTHkWFNwh+zvs1U1NcaK7A/DzTNVcoA7tdEMmX1CN/C PcCRURgO6D46b+fGmncoqgoIDgtoCrPjYZGnFbF5XQ5S1/kS7KDHLe+Dw3yDhgDMItwd F1Wp7lmfpCv/vhGRqVI9G0RGTYvfHqVRCC2G5XCVJzHHhmvglgUxNY5AMc9WEjxY83u/ ksOGFJWKmKZpkyTpjhwTmOZO3htmRVwSM63B90Xxs1B+0ckAEWAY7DD/m7yRIrXh0cyA qZSF8wJMMoMllp478eNTclk33U10jiTtAcv5OOzainTme2ImyMwq+Yx0w/hov++mHkh0 y+NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="h/mDIbri"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o25si10467896edv.3.2021.02.13.22.47.50; Sat, 13 Feb 2021 22:48:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="h/mDIbri"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229806AbhBNGoG (ORCPT + 99 others); Sun, 14 Feb 2021 01:44:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229790AbhBNGoF (ORCPT ); Sun, 14 Feb 2021 01:44:05 -0500 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9525C061756; Sat, 13 Feb 2021 22:43:24 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id n4so1817951wrx.1; Sat, 13 Feb 2021 22:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aUQN0SZkwCC+2sHkMRBo4eVveaM2m59ClyPi/TCSgJI=; b=h/mDIbriPlQZGWb9Eb+iLQ2zUlvMmcy9awHJpqDHlnzTnWOsQH0vqNZO0tg7gvYlh3 h1HoSIjmKogwHw8RFpjBJ7uocWEfbdZjB1koiQq6K76Qh8VztTJUIE0XDc3dVr3bDXvB Qvr8BMnXtxJCREViPxKu4XP4vecJXZaj9I0dv1Nn/mzvM8XGc91//KKyg9RTyvDAYjgj iqDAUkXf4jncjNS8Pqr9fGbDuFGrAssQYNlIR/K8zW7W+rL9+EEmKdg0yCPavKc30FCK GPt3DR3382ijOTCvAEqAyCDomOVT6W889vWolxIP2H+Saoq5w9y1TvNITlaZ/TnqXhPK mJgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aUQN0SZkwCC+2sHkMRBo4eVveaM2m59ClyPi/TCSgJI=; b=hngI7kOwJYAtoS3hwBTOZLOBSr/+aB5e6WYK3okjwMWHc1aUdsUXIvAdWAmbdMutTU uTueMrBkTT40E4QRdquXl4oqLP+1wQ+hUsIbmiPmXAgXtumSRAw9pXi/0JI2PzpPNFY4 nPf37jrRhQjIF2kEajW+R4FdUz/cI+gahLP0rNg7HzcKAxx3V8OUO/8ev8sbxwNCJfen ViaOW+60pofap6Wl0lp1fbYDp5vKmvZagHUi70xBwvoi0bmG0gG0Mwo/oYYgj+z2arwA DRA4I7QUwuZO5RpZNXn2tPodfw7dz+2KsWMipgtCmSfTQQ8p29NOlMdcGUXQyqJBLCeJ ZzgA== X-Gm-Message-State: AOAM531B3DlI9500FGANGciOF7Wc8UU5CPkl4QoDRJUFNdAZGHnRxxAd rYh6xfA7DzgqDHaX9NaO/5DpMgrvfBAppOEHq+Y= X-Received: by 2002:a5d:4849:: with SMTP id n9mr12536800wrs.159.1613285001726; Sat, 13 Feb 2021 22:43:21 -0800 (PST) Received: from [0.0.0.0] ([2a01:4f8:c17:e10a::1]) by smtp.gmail.com with ESMTPSA id z15sm4013712wrs.72.2021.02.13.22.43.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Feb 2021 22:43:21 -0800 (PST) Subject: Re: [PATCH v3 3/3] ASoC: rt715:add micmute led state control supports To: Mark Brown , Perry Yuan Cc: oder_chiou@realtek.com, perex@perex.cz, tiwai@suse.com, hdegoede@redhat.com, mgross@linux.intel.com, lgirdwood@gmail.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, Mario.Limonciello@dell.com References: <20210112171814.5404-1-Perry_Yuan@Dell.com> <20210112175406.GF4646@sirena.org.uk> From: Perry Yuan Message-ID: <43507ba7-74b8-2d18-57ca-271f89a752de@gmail.com> Date: Sun, 14 Feb 2021 14:43:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210112175406.GF4646@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark: Thanks for your review. On 2021/1/13 1:54, Mark Brown wrote: > On Wed, Jan 13, 2021 at 01:18:14AM +0800, Perry Yuan wrote: > >> Some new Dell system is going to support audio internal micphone >> privacy setting from hardware level with micmute led state changing >> When micmute hotkey pressed by user, soft mute will need to be enabled >> firstly in case of pop noise, and codec driver need to react to mic >> mute event to EC(embedded controller) notifying that SW mute is completed >> Then EC will do the hardware mute physically within the timeout reached > >> This patch allow codec rt715 driver to ack EC when micmute key pressed >> through this micphone led control interface like hda_generic provided >> ACPI method defined in dell-privacy micmute led trigger will be called >> for notifying the EC that software mute has been completed > > It feels like there's an abstraction problem here with this being hard > coded in a specific CODEC driver. > >> #include >> @@ -244,6 +245,7 @@ static int rt715_sdca_get_volsw(struct snd_kcontrol *kcontrol, >> unsigned int max = mc->max; >> int val; >> >> + pr_err("++++++rt715_sdca_get_volsw++\n"); >> val = snd_soc_component_read(component, mc->reg); >> if (val < 0) >> return -EINVAL; > > This shouldn't be in the patch. Removed in V4, I forget to clear this debug code > >> @@ -287,6 +291,18 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol, >> return err; >> } >> >> +#if IS_ENABLED(CONFIG_DELL_PRIVACY) >> + /* dell privacy LED trigger state changed by muted/unmute switch */ >> + if (mc->invert) { >> + if (ucontrol->value.integer.value[0] || ucontrol->value.integer.value[1]) { >> + rt715->micmute_led = LED_OFF; >> + } else { >> + rt715->micmute_led = LED_ON; >> + } >> + ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led); >> + } >> +#endif >> + > > This doesn't look good. There's nothing Dell specific here, and nothing > about this is conditional on any sort of runtime detection of Dell > systems, it's not obvious why this is conditional on DELL_PRIVACY or why > we only report the state if the control is inverted. > I will remove the CONFIG_DELL_PRIVACY from V4 patch and allow it to run if CONFIG_DELL_PRIVACY is not set, the result will be a no-op. > I'm also not convinced that it's a good idea to set the mute LED if only > one channel in a stereo microphone is muted, that seems likely to lead > to surprising behaviour for users. > https://github.com/thesofproject/linux/pull/2660#discussion_r555480210 There is a discussion for the channel mute changing behavior. If the anyone of value[0] or value[1] is 1, it means mic is NOT muted The muted state will be LED_ON state need to set. > TBH I don't understand why this isn't being done in generic code. > >> + bool micmute_led; > > What is this for, it never seems to be read except for in the function > where it's set? > I have moved this part code to the local definition of rt715_set_amp_gain_put and removed from rt715_priv. new code will be like this in V4. @@ -88,6 +89,7 @@ static int rt715_set_amp_gain_put(struct snd_kcontrol *kcontrol, RT715_SET_GAIN_MIX_ADC2_L}; unsigned int addr_h, addr_l, val_h, val_ll, val_lr; unsigned int read_ll, read_rl, i, j, loop_cnt; + bool micmute_led;