From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DCD0C433EF for ; Wed, 20 Jul 2022 06:29:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231127AbiGTG3X (ORCPT ); Wed, 20 Jul 2022 02:29:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240081AbiGTG3S (ORCPT ); Wed, 20 Jul 2022 02:29:18 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E12BE4AD6B for ; Tue, 19 Jul 2022 23:29:17 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2831034440; Wed, 20 Jul 2022 06:29:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1658298556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Zjvb1z9IaC7dIvN5NfShCXWS4nB1nq2Q+yZq/HTN4ws=; b=sW/YrLKdNt/bnrOZ/QGfDKLpOts5h/51TWldGyLbRxZOaBJ9+n+o+C4oS/yjOb4nS+ai8Q YVVWdYqHEhkFEQ6y9J085E4wMOpDsOl2y+xAUet774ktuH7aY+b4MhT6F6b6a4bySpjvvo eYP0tJemWgpJcqukwK7RXU3gDmq/qHI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1658298556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Zjvb1z9IaC7dIvN5NfShCXWS4nB1nq2Q+yZq/HTN4ws=; b=jDMZixzs58wV9EsIAKPNw3wj4tTOSffRpZRyIgnv0WlXf0zkGzYFmR+vvY8CLE+0toM/JW BnfiKHhs81V7ZbAw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D947713AA1; Wed, 20 Jul 2022 06:29:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id XD4tNLug12IlPwAAMHmgww (envelope-from ); Wed, 20 Jul 2022 06:29:15 +0000 Date: Wed, 20 Jul 2022 08:29:15 +0200 Message-ID: <87zgh45mbo.wl-tiwai@suse.de> From: Takashi Iwai To: Kai-Heng Feng Cc: Jaroslav Kysela , tiwai@suse.com, Bard Liao , Pierre-Louis Bossart , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ALSA: hda: Skip creating captures in SOF context In-Reply-To: References: <20220719144753.252231-1-kai.heng.feng@canonical.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jul 2022 03:45:37 +0200, Kai-Heng Feng wrote: > > On Tue, Jul 19, 2022 at 11:41 PM Jaroslav Kysela wrote: > > > > Dne 19. 07. 22 v 16:47 Kai-Heng Feng napsal(a): > > > On HP laptops that use SOF driver for DMIC, the micmute LED doesn't > > > light up when mic is muted after commit 9b014266ef8a ("ASoC: SOF: > > > topology: use new sound control LED layer"). > > > > > > The micmute LED itself is still working via sysfs, but it doesn't follow > > > mute anymore. That's because unlike vendors like Dell and Lenovo, HP > > > laptops use HDA codec to control mute LEDs instead of ACPI. So on HP > > > laptops, both SOF and HDA create captures with > > > SNDRV_CTL_ELEM_ACCESS_MIC_LED access, snd_ctl_led_set_state() considers > > > there are two different kcontrols and one of them is not muted. > > > > It does not mean that it's a wrong behavior. When both controls are muted, the > > LED should be turned on. It just requires that all inputs are off (and it may > > be the default - probably we can set in UCM or so). If you turn the "Capture > > Switch" off in amixer / alsamixer, do things work as expected ? > > Yes. When all captures are muted the micmute LED is on. > > > > > > So skip creating captures for HDA when it's called from SOF, the > > > captures are already handled by SOF. > > > > The capture controls are for other inputs like external analog microphone. If > > it is required to suppress the MIC LED for some hardware, just skip the > > "spec->mic_mute_led = 1" assignment in hda_generic.c . Also, the check > > "codec->core.type != HDA_DEV_ASOC" is not sufficient, because you don't know, > > if the topology really sets the MIC LED flag. > > AFAIK the external analog microphone on DMIC laptop is driven by SOF driver too. > If those capture controls are indeed needed for external analog mics, > use UCM to mute them by default won't work either. > > Skip "mic_mute_led = 1" can be hard because it's still needed for legacy HDA. > If checking "HDA_DEV_ASOC" isn't sufficient, is it possible to just > check "card" in snd_ctl_led_set_state(), instead of kcontrols? > I think it's reasonable to assume a card has just one speaker LED and > one microphone LED. Hm, but skipping the whole create_capture_mixers() call doesn't sound right, either. I thought there are still external mic controls via codec, and those would be skipped by this patch? If the mic-mute LED is the problem, it should be rather checked in the caller of snd_hda_gen_add_micmute_led_cdev(), i.e. patch_realtek.c, instead, IMO. thanks, Takashi