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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA948C433E0 for ; Fri, 26 Feb 2021 08:42:05 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 59E4B64EE7 for ; Fri, 26 Feb 2021 08:42:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59E4B64EE7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id C2FB5852; Fri, 26 Feb 2021 09:41:11 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C2FB5852 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1614328921; bh=eO4griKhhCUNZzuUmymgeG+OnTMkeuenYvSIi9+LwzU=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kHAXQylYb9iwt0UPT+XjZheGAzUrzowSW5ZIpNdtb65kdwL5agwkar4kR3j6wHP/k pH0/hz+0POsS7RSgHjARA9f5fu4+SB+a9CybwUQnBXLEiG9u73KtxzIuqlrCDmw7ML 9xcp4wxgNf3zX8zKonn+lRSYCQ2cbwzVtqA2SoGs= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 12E3DF8012C; Fri, 26 Feb 2021 09:41:11 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 062B8F8016C; Fri, 26 Feb 2021 09:41:09 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 497DFF80159 for ; Fri, 26 Feb 2021 09:41:05 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 497DFF80159 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B6DF1AC6E; Fri, 26 Feb 2021 08:41:04 +0000 (UTC) Date: Fri, 26 Feb 2021 09:41:04 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela Subject: Re: [RFC 2/2] ASoC: rt5670: Add LED trigger support In-Reply-To: <254af1a7-6ed4-60be-01b5-76cf08b7f8da@perex.cz> References: <20210215142419.308651-1-hdegoede@redhat.com> <20210215142419.308651-3-hdegoede@redhat.com> <20210223134506.GF5116@sirena.org.uk> <578b1ee3-f426-c5b5-bc78-5a91108ebdc8@redhat.com> <20210223140930.GH5116@sirena.org.uk> <5c6a21c1-7107-3351-25be-c007b0b946d3@perex.cz> <776b4ad9-2612-b08a-cb76-c3e1ce02388a@perex.cz> <4574088a-4676-131a-0065-499a516f80ae@perex.cz> <03068e15-2157-3ae6-ffd6-7ec315bb49a3@perex.cz> <9c74e8de-769c-cd98-3944-85bd75bc840b@perex.cz> <3c262ea6-2313-3af8-60ae-d59ae8be262d@perex.cz> <254af1a7-6ed4-60be-01b5-76cf08b7f8da@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Oder Chiou , alsa-devel@alsa-project.org, Liam Girdwood , Hans de Goede , Mark Brown , Bard Liao X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Thu, 25 Feb 2021 19:09:44 +0100, Jaroslav Kysela wrote: > > Dne 25. 02. 21 v 12:00 Takashi Iwai napsal(a): > > On Wed, 24 Feb 2021 18:57:42 +0100, > > Jaroslav Kysela wrote: > >> > >> Dne 24. 02. 21 v 13:42 Takashi Iwai napsal(a): > >>> On Wed, 24 Feb 2021 13:08:55 +0100, > >>> Jaroslav Kysela wrote: > >>>> > >>>> Dne 24. 02. 21 v 12:43 Takashi Iwai napsal(a): > >>>> > >>>>>>> So far, a user control is merely storing the value, let read/write via > >>>>>>> the control API. That's all, and nothing wrong can happen just by > >>>>>>> that. Now if it interacts with other subsystem... > >>>>>>> > >>>>>>> A more serious concern is rather the fragility of the setup; for > >>>>>>> enabling the mute LED control, you'd have to create a new user-space > >>>>>>> control, the function of the control has to be ignored by some > >>>>>>> application and some not, etc. This has to be done on each machine > >>>>>> > >>>>>> You're using "ignore", but as I explained before, the user space switch will > >>>>>> be used in the whole chain: > >>>>>> > >>>>>> capture stream -> > >>>>>> alsa-lib mute switch / silence PCM stream -> > >>>>>> PA mute switch / silence PCM stream > >>>>>> > >>>>>> So PA can use this switch like the traditional hardware mute switch. > >>>>> > >>>>> Does it mean PA would work as of now without any change? Or does it > >>>>> need patching? > >>>> > >>>> Yes, no PA modifications are required with my mechanism. The PA will just see > >>>> the new user space control - mute switch - created in alsa-lib - which will be > >>>> synced the internal PA path mute state like for the hardware mute > >>>> switch. > >>> > >>> OK, but how would we create and manage the user control element? And > >>> why it has to be user control? > >> > >> The softvol or alsactl can create the user control element. The alsa-lib > >> softvol plugin and PA can silence stream according the state. > > > > And that's tricky if it's only with PA, as PA won't open a softvol PCM > > stream... > > The protection is in alsa-lib, so we can skip to check this hint flag for this > particular case like: > > https://github.com/alsa-project/alsa-lib/pull/121/commits/1acc1c7eccab0359996b25de54a6b6e0aa1e0c17 > > So it may depend on the softvol config not PA itself. Thanks, that's what I missed from the big picture. > Even for the solution bellow, we need to modify softvol to handle the kernel > control elements, too. Actually softvol is not active, when the specified > control element is found and this element is not from the user space. Hm, that would certainly work, but as we discussed before, it enforces the softvol PCM process for PA. That isn't too bad for the capture, fortunately, but not ideal, OTOH. And, I'm not sure how PA can take any control as its main capture mute switch, if it's named differently. Wouldn't we need to change mixer path in PA as well? And, if we may change PA side, it sounds more natural to change a control directly in PA's mixer path. The softvol doesn't fit well with PA, after all. > >> I see your point to create this control in the kernel space, but any other > >> name than "Mic Capture Switch" (in the ACP case) will be misleading for users, > >> because the user-space does the appropriate real silencing job instead of hw. > >> > >> And if we create "Mic Capture Switch" in the kernel space, it may be > >> misleading for applications (they can think that there's hardware mute control). > >> > >> Perhaps, we can create "Mic Phantom Capture Switch" in kernel which may > >> resolve both problems (no hw mute information + no user confusion). > > > > Yes, something like that would work. > > The advantage of in-kernel implementation is that it's self-contained, > > so just deploying the new kernel makes everything working. > > Ok, so let settle the naming for those controls which depends on the user > space code which does the real work (silencing). Is "Phantom" prefix good - > we're using it for jacks, or someone has a better idea? If we have to go in this way, that's an acceptable name, I think. thanks, Takashi