All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hui Wang <hui.wang@canonical.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: alsa-devel@alsa-project.org, Hui Wang <jason77.wang@gmail.com>,
	tiwai@suse.de,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	alex.hung@canonical.com, yk@canonical.com,
	david.henningsson@canonical.com
Subject: Re: [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
Date: Mon, 30 Jun 2014 10:04:06 +0800	[thread overview]
Message-ID: <53B0C596.6090007@canonical.com> (raw)
In-Reply-To: <53AFF992.5030403@web.de>

On 06/29/2014 07:33 PM, Jan Kiszka wrote:
> On 2013-11-27 07:47, Hui Wang wrote:
>> Most Thinkpad Edge series laptops use conexant codec, so far although
>> the codecs have different minor Vendor Id and minor Subsystem Id,
>> they all belong to the cxt5066 family, this change can make the
>> mute/mic-mute LEDs support more generic among cxt_5066 family.
>>
>> This design refers to the similar solution for the realtek codec
>> ALC269 family in the patch_realtek.c.
>>
>> Cc: Alex Hung <alex.hung@canonical.com>
>> Cc: David Henningsson <david.henningsson@canonical.com>
>> Signed-off-by: Hui Wang <hui.wang@canonical.com>
>> ---
>>   sound/pci/hda/patch_conexant.c | 23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
>> index c205bb1..1f2717f 100644
>> --- a/sound/pci/hda/patch_conexant.c
>> +++ b/sound/pci/hda/patch_conexant.c
>> @@ -3244,9 +3244,29 @@ enum {
>>   #if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>>   
>>   #include <linux/thinkpad_acpi.h>
>> +#include <acpi/acpi.h>
>>   
>>   static int (*led_set_func)(int, bool);
>>   
>> +static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void *context,
>> +				 void **rv)
>> +{
>> +	bool *found = context;
>> +	*found = true;
>> +	return AE_OK;
>> +}
>> +
>> +static bool is_thinkpad(struct hda_codec *codec)
>> +{
>> +	bool found = false;
>> +	if (codec->subsystem_id >> 16 != 0x17aa)
>> +		return false;
>> +	if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, &found, NULL)) && found)
>> +		return true;
>> +	found = false;
>> +	return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb, &found, NULL)) && found;
>> +}
>> +
>>   static void update_tpacpi_mute_led(void *private_data, int enabled)
>>   {
>>   	struct hda_codec *codec = private_data;
>> @@ -3279,6 +3299,8 @@ static void cxt_fixup_thinkpad_acpi(struct hda_codec *codec,
>>   	bool removefunc = false;
>>   
>>   	if (action == HDA_FIXUP_ACT_PROBE) {
>> +		if (!is_thinkpad(codec))
>> +			return;
>>   		if (!led_set_func)
>>   			led_set_func = symbol_request(tpacpi_led_set);
>>   		if (!led_set_func) {
>> @@ -3494,6 +3516,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
>>   	SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
>>   	SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
>>   	SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC),
>> +	SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad", CXT_FIXUP_THINKPAD_ACPI),
>>   	SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004),
>>   	SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205),
>>   	{}
>>
> Starting with this patch, my Lenovo Thinkpad X121e netbook (it's without
> any mute LEDs, BTW, there is only a power LED) considers the power
> button as hard reset. I have to exclude my machine from that ACPI fixup
> (this is on top of current Linus master):
It seems more like a firmware issue, in the acpi code, the "SSMS" is for 
mute led, and the "MMTS" is for micmute led, I don't know why your 
machine can pass "SSMS" or "MMTS" scanning even without mute LEDs.



> diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c
> index 6ba0b55..7e1a179 100644
> --- a/sound/pci/hda/thinkpad_helper.c
> +++ b/sound/pci/hda/thinkpad_helper.c
> @@ -21,7 +21,8 @@ static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void *context,
>   static bool is_thinkpad(struct hda_codec *codec)
>   {
>   	bool found = false;
> -	if (codec->subsystem_id >> 16 != 0x17aa)
> +	if (codec->subsystem_id >> 16 != 0x17aa ||
> +	    codec->subsystem_id == 0x17aa21ec)
>   		return false;
>   	if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, &found, NULL)) && found)
>   		return true;
>
>
> Is that the way to address it? Then I can send a proper patch. Any hints
> regarding the "why" will be incorporated into its description.
>
> Thanks,
> Jan
>

WARNING: multiple messages have this Message-ID (diff)
From: Hui Wang <hui.wang@canonical.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Hui Wang <jason77.wang@gmail.com>,
	tiwai@suse.de, alsa-devel@alsa-project.org,
	alex.hung@canonical.com, yk@canonical.com,
	david.henningsson@canonical.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
Date: Mon, 30 Jun 2014 10:04:06 +0800	[thread overview]
Message-ID: <53B0C596.6090007@canonical.com> (raw)
In-Reply-To: <53AFF992.5030403@web.de>

On 06/29/2014 07:33 PM, Jan Kiszka wrote:
> On 2013-11-27 07:47, Hui Wang wrote:
>> Most Thinkpad Edge series laptops use conexant codec, so far although
>> the codecs have different minor Vendor Id and minor Subsystem Id,
>> they all belong to the cxt5066 family, this change can make the
>> mute/mic-mute LEDs support more generic among cxt_5066 family.
>>
>> This design refers to the similar solution for the realtek codec
>> ALC269 family in the patch_realtek.c.
>>
>> Cc: Alex Hung <alex.hung@canonical.com>
>> Cc: David Henningsson <david.henningsson@canonical.com>
>> Signed-off-by: Hui Wang <hui.wang@canonical.com>
>> ---
>>   sound/pci/hda/patch_conexant.c | 23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
>> index c205bb1..1f2717f 100644
>> --- a/sound/pci/hda/patch_conexant.c
>> +++ b/sound/pci/hda/patch_conexant.c
>> @@ -3244,9 +3244,29 @@ enum {
>>   #if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>>   
>>   #include <linux/thinkpad_acpi.h>
>> +#include <acpi/acpi.h>
>>   
>>   static int (*led_set_func)(int, bool);
>>   
>> +static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void *context,
>> +				 void **rv)
>> +{
>> +	bool *found = context;
>> +	*found = true;
>> +	return AE_OK;
>> +}
>> +
>> +static bool is_thinkpad(struct hda_codec *codec)
>> +{
>> +	bool found = false;
>> +	if (codec->subsystem_id >> 16 != 0x17aa)
>> +		return false;
>> +	if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, &found, NULL)) && found)
>> +		return true;
>> +	found = false;
>> +	return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb, &found, NULL)) && found;
>> +}
>> +
>>   static void update_tpacpi_mute_led(void *private_data, int enabled)
>>   {
>>   	struct hda_codec *codec = private_data;
>> @@ -3279,6 +3299,8 @@ static void cxt_fixup_thinkpad_acpi(struct hda_codec *codec,
>>   	bool removefunc = false;
>>   
>>   	if (action == HDA_FIXUP_ACT_PROBE) {
>> +		if (!is_thinkpad(codec))
>> +			return;
>>   		if (!led_set_func)
>>   			led_set_func = symbol_request(tpacpi_led_set);
>>   		if (!led_set_func) {
>> @@ -3494,6 +3516,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
>>   	SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
>>   	SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
>>   	SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC),
>> +	SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad", CXT_FIXUP_THINKPAD_ACPI),
>>   	SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004),
>>   	SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205),
>>   	{}
>>
> Starting with this patch, my Lenovo Thinkpad X121e netbook (it's without
> any mute LEDs, BTW, there is only a power LED) considers the power
> button as hard reset. I have to exclude my machine from that ACPI fixup
> (this is on top of current Linus master):
It seems more like a firmware issue, in the acpi code, the "SSMS" is for 
mute led, and the "MMTS" is for micmute led, I don't know why your 
machine can pass "SSMS" or "MMTS" scanning even without mute LEDs.



> diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c
> index 6ba0b55..7e1a179 100644
> --- a/sound/pci/hda/thinkpad_helper.c
> +++ b/sound/pci/hda/thinkpad_helper.c
> @@ -21,7 +21,8 @@ static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void *context,
>   static bool is_thinkpad(struct hda_codec *codec)
>   {
>   	bool found = false;
> -	if (codec->subsystem_id >> 16 != 0x17aa)
> +	if (codec->subsystem_id >> 16 != 0x17aa ||
> +	    codec->subsystem_id == 0x17aa21ec)
>   		return false;
>   	if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, &found, NULL)) && found)
>   		return true;
>
>
> Is that the way to address it? Then I can send a proper patch. Any hints
> regarding the "why" will be incorporated into its description.
>
> Thanks,
> Jan
>


  reply	other threads:[~2014-06-30  2:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27  6:47 [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec Hui Wang
2013-11-27  7:49 ` David Henningsson
2014-06-29 11:33 ` Jan Kiszka
2014-06-30  2:04   ` Hui Wang [this message]
2014-06-30  2:04     ` Hui Wang
2014-06-30  6:45     ` Jan Kiszka
2014-07-01  2:15       ` Hui Wang
2014-07-01  7:38         ` Jan Kiszka
2014-07-01  7:38           ` Jan Kiszka
2014-07-01  9:26           ` Hui Wang
2014-07-03  7:04             ` Jan Kiszka
2014-07-03  8:59               ` Hui Wang
2014-07-03  9:05                 ` Jan Kiszka
2014-07-03  9:05                   ` Jan Kiszka
2014-07-03  9:24                   ` Hui Wang
2014-07-03  9:24                     ` Hui Wang
2015-05-23  8:49                     ` Jan Kiszka
2015-05-23  8:49                       ` Jan Kiszka
2015-05-23 16:06                       ` Raymond Yau
2015-05-23 16:22                         ` Jan Kiszka
2015-05-23 16:22                           ` [alsa-devel] " Jan Kiszka
2015-06-24  5:37                           ` Jan Kiszka
2015-06-24  8:46                             ` Hui Wang
2015-06-25 11:02                               ` Jan Kiszka
2015-06-26  2:22                                 ` Hui Wang
2015-06-26  4:06                                   ` Jan Kiszka
2015-06-26 22:49                                   ` Henrique de Moraes Holschuh
2015-06-27  5:59                                     ` Jan Kiszka
2015-06-27 15:50                                       ` Henrique de Moraes Holschuh
2015-06-27 15:50                                         ` [alsa-devel] " Henrique de Moraes Holschuh
2015-06-29  9:06                                         ` Takashi Iwai
2015-06-29  9:06                                           ` [alsa-devel] " Takashi Iwai
2015-06-27  3:03                       ` Raymond Yau
2015-06-29  0:49                         ` Hui Wang
2015-06-29  0:49                           ` [alsa-devel] " Hui Wang
2015-07-01  9:51                           ` Hui Wang

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=53B0C596.6090007@canonical.com \
    --to=hui.wang@canonical.com \
    --cc=alex.hung@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.com \
    --cc=jan.kiszka@web.de \
    --cc=jason77.wang@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.de \
    --cc=yk@canonical.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 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.