From: Hans de Goede <hdegoede@redhat.com>
To: Jaroslav Kysela <perex@perex.cz>,
"Yuan, Perry" <Perry.Yuan@dell.com>,
Mark Brown <broonie@kernel.org>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"Limonciello, Mario" <Mario.Limonciello@dell.com>
Cc: "pobrn@protonmail.com" <pobrn@protonmail.com>,
"oder_chiou@realtek.com" <oder_chiou@realtek.com>,
"tiwai@suse.com" <tiwai@suse.com>,
"mgross@linux.intel.com" <mgross@linux.intel.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>
Subject: Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state control supports
Date: Mon, 22 Mar 2021 16:01:41 +0100 [thread overview]
Message-ID: <5cad3045-7948-3282-c999-926095818d5f@redhat.com> (raw)
In-Reply-To: <604693cc-08c7-2b5f-632a-58ed537c54a0@perex.cz>
Hi,
On 3/22/21 3:37 PM, Jaroslav Kysela wrote:
> Dne 22. 03. 21 v 10:25 Yuan, Perry napsal(a):
>> Hi Mark:
>>
>>> -----Original Message-----
>>> From: Mark Brown <broonie@kernel.org>
>>> Sent: Tuesday, March 9, 2021 1:24 AM
>>> To: Yuan, Perry
>>> Cc: pobrn@protonmail.com; pierre-louis.bossart@linux.intel.com;
>>> oder_chiou@realtek.com; perex@perex.cz; tiwai@suse.com;
>>> hdegoede@redhat.com; mgross@linux.intel.com; Limonciello, Mario;
>>> lgirdwood@gmail.com; alsa-devel@alsa-project.org; linux-
>>> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org
>>> Subject: Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state control
>>> supports
>>>
>>> On Mon, Mar 01, 2021 at 05:38:34PM +0800, Perry Yuan wrote:
>>>
>>>> + /* Micmute LED state changed by muted/unmute switch */
>>>> + if (mc->invert) {
>>>> + if (ucontrol->value.integer.value[0] || ucontrol-
>>>> value.integer.value[1]) {
>>>> + micmute_led = LED_OFF;
>>>> + } else {
>>>> + micmute_led = LED_ON;
>>>> + }
>>>> + ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led);
>>>> + }
>>>
>>> These conditionals on inversion seem weird and counterintuitive. If we're
>>> going with this approach it would probably be clearer to define a custom
>>> operation for the affected controls that wraps the standard one and adds the
>>> LED setting rather than keying off invert like this.
>>
>> Currently the sof soundwire driver has no generic led control yet.
>> This patch can handle the led control needs for MIC mute LED, definitely the patch is a short term solution.
>> There is a feature request discussion when we started to implement this solution.
>> https://github.com/thesofproject/linux/issues/2496#issuecomment-713892620
>>
>> The workable way for now is that we put the LED mute control to the codec driver.
>> When there is new and full sound LED solution implemented, this part will be also optimized.
>> The Hardware privacy feature needs this patch to handle the Mic mute led state change.
>> Before that full solution ready in kernel, could we take this as short term solution?
>
> Perry, it's about the machine detection. Your code is too much generic even
> for the top-level LED trigger implementation. We need an extra check, if the
> proper LED's are really controlled on the specific hardware. Other hardware
> may use RT715 for a different purpose. Use DMI / ACPI checks to detect this
> hardware and don't misuse the inversion flag to enable this code.
I think this would be a goo candidate for the new generic LED handling:
https://lore.kernel.org/alsa-devel/20210317172945.842280-1-perex@perex.cz/
And then use a udev-rule + hwdb and/or UCM profiles to configure the LED trigger
for specific models from userspace ?
Regards,
Hans
next prev parent reply other threads:[~2021-03-22 15:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 9:38 Perry Yuan
2021-03-01 14:30 ` Pierre-Louis Bossart
2021-03-08 17:24 ` Mark Brown
2021-03-22 9:25 ` Yuan, Perry
2021-03-22 14:37 ` Jaroslav Kysela
2021-03-22 15:01 ` Hans de Goede [this message]
2021-03-25 14:11 ` Yuan, Perry
2021-03-25 15:07 ` Hans de Goede
2021-03-26 7:20 ` Yuan, Perry
2021-03-25 8:19 ` Yuan, Perry
2021-03-25 9:37 ` Jaroslav Kysela
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=5cad3045-7948-3282-c999-926095818d5f@redhat.com \
--to=hdegoede@redhat.com \
--cc=Mario.Limonciello@dell.com \
--cc=Perry.Yuan@dell.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgross@linux.intel.com \
--cc=oder_chiou@realtek.com \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pobrn@protonmail.com \
--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®