All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Limonciello, Mario" <Mario.Limonciello@dell.com>,
	"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	"Yuan, Perry" <Perry.Yuan@dell.com>
Cc: "mgross@linux.intel.com" <mgross@linux.intel.com>,
	"pali@kernel.org" <pali@kernel.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] platform/x86: dell-privacy: Add support for new privacy driver
Date: Thu, 12 Nov 2020 16:55:07 +0100	[thread overview]
Message-ID: <544bc53f-c260-9e46-15a9-2ec2ea41343c@redhat.com> (raw)
In-Reply-To: <DM6PR19MB2636D792A7CCEE8937579EA6FAE70@DM6PR19MB2636.namprd19.prod.outlook.com>

Hi,

On 11/12/20 4:31 PM, Limonciello, Mario wrote:
>>> Pressing the mute key activates a time delayed circuit to physically cut
>>> off the mute.  The LED is in the same circuit, so it reflects the true
>>> state of the HW mute.  The reason for the EC "ack" is so that software
>>> can first invoke a SW mute before the HW circuit is cut off.  Without SW
>>> cutting this off first does not affect the time delayed muting or status
>>> of the LED but there is a possibility of a "popping" noise leading to a
>>> poor user experience.
>>
>> how long is that timeout ?
> 
> The exact duration is controlled by component selection in the circuit.
> Linux is typically able to respond faster than Windows in this case.
> 
>>
>>> Exposing as an LED device allows the codec drivers notification path to
>>> EC ACK to work.
>>
>> Which driver exactly ? Who's gonna access this LED ?
> 
> The flow is like this:
> 
> 1) User presses key.  HW does stuff with this key (timeout is started)
> 2) Event is emitted from FW
> 3) Event received by dell-privacy
> 4) KEY_MICMUTE emitted from dell-privacy
> 5) Userland picks up key and modifies kcontrol for SW mute
> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
> 
> ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led ? LED_ON : LED_OFF);
> 
> 7) If "LED" is set to on dell-privacy notifies ec, and timeout is cancelled,
> HW mic mute activated.
> 
> Again, if anything in this flow doesn't happen HW mic mute is still activated,
> just will take longer (for duration of timeout) and have popping noise.

Thank you, can we put this in a comment in the driver please ?

I guess this also means that the led_class device is just there to
catch the ledtrig_audio_set() call so that dell-firmware can tell the
EC that the sw-mute is done and that it can move ahead with the hw-mute.

While the real, physical LED is fully under hardware control, right ?

That should probably also be in the same comment in the driver
(feel free to re-use part of my wording for that if that helps).

Regards,

Hans



> 
>>
>>
>> --mtx
>>
>> --
>> ---
>> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
>> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
>> GPG/PGP-Schlüssel zu.
>> ---
>> Enrico Weigelt, metux IT consult
>> Free software and Linux embedded engineering
>> info@metux.net -- +49-151-27565287


  reply	other threads:[~2020-11-12 15:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03 12:55 [PATCH] platform/x86: dell-privacy: Add support for new privacy driver Perry Yuan
2020-11-03 16:22 ` kernel test robot
2020-11-03 16:22   ` kernel test robot
2020-11-03 16:50 ` kernel test robot
2020-11-03 16:50   ` kernel test robot
2020-11-03 19:14 ` Barnabás Pőcze
2020-11-04  1:49 ` Matthew Garrett
2020-11-11  7:21   ` Yuan, Perry
2020-11-11  7:24     ` Matthew Garrett
2020-11-11 14:30       ` Limonciello, Mario
2020-11-12 15:06         ` Enrico Weigelt, metux IT consult
2020-11-12 15:31           ` Limonciello, Mario
2020-11-12 15:55             ` Hans de Goede [this message]
2020-11-12 15:57               ` Limonciello, Mario
2020-11-04  6:43 ` kernel test robot
2020-11-04  6:43   ` kernel test robot
2020-11-09 11:16 ` Hans de Goede
2020-11-11  7:24   ` Yuan, Perry

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=544bc53f-c260-9e46-15a9-2ec2ea41343c@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=Mario.Limonciello@dell.com \
    --cc=Perry.Yuan@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@metux.net \
    --cc=mgross@linux.intel.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=pali@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.