* [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
@ 2021-07-21 17:01 ` Alexander Monakov
0 siblings, 0 replies; 12+ messages in thread
From: Alexander Monakov @ 2021-07-21 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Chris Chiu, Jian-Hong Pan, Kailang Yang, alsa-devel, Jeremy Szu,
Alexander Monakov, Takashi Iwai, Hui Wang, PeiSen Hou
The Acer Swift SF314-42 laptop is using Realtek ALC255 codec. Add a
quirk so microphone in a headset connected via the right-hand side jack
is usable.
Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Hui Wang <hui.wang@canonical.com>
Cc: Kailang Yang <kailang@realtek.com>
Cc: Jeremy Szu <jeremy.szu@canonical.com>
Cc: Jian-Hong Pan <jhp@endlessos.org>
Cc: Chris Chiu <chris.chiu@canonical.com>
Cc: PeiSen Hou <pshou@realtek.com>
Cc: alsa-devel@alsa-project.org
---
Hello,
Acer Swift SF314-42 laptop is using AMD Ryzen SoC audio with Realtek
ALC255 codec. The are three ALSA cards: HDMI audio, AMD ACP card, and
AMD HDA card. There is an internal stereo microphone connected to the
ACP card, and a mini-jack connected to the Realtek codec. There are no
LEDs.
I'd like to be able to use a mic+headphones headset. Unfortunately, out
of the box ALSA does not correctly detect the microphone input of the
Realtek codec. The suggested patch fixes that, though I cannot be sure
it's 100% correct.
With the patch, the experience is unfortunately still not ideal. I have
noticed a couple of issues:
1) at high enough gain, recording the microphone is picking up what is
being played via the headphones; maybe it's supposed to be like that,
but it surprised me;
2) there is a very noticeable "pop" when plugging the headset in/out,
accompanied by
pcieport 0000:00:08.1: PME: Spurious native interrupt!
pcieport 0000:00:08.1: PME: Spurious native interrupt!
in dmesg. I'd appreciate info and any help about this issue.
Thanks.
Alexander
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ab5113cccffa..87ad8469dbc5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8191,6 +8191,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", ALC255_FIXUP_ACER_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x142b, "Acer Swift SF314-42", ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1466, "Acer Aspire A515-56", ALC255_FIXUP_ACER_HEADPHONE_AND_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
base-commit: 62fb9874f5da54fdb243003b386128037319b219
--
2.31.1
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-07-21 17:01 ` Alexander Monakov
@ 2021-07-28 17:02 ` Takashi Iwai
-1 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2021-07-28 17:02 UTC (permalink / raw)
To: Alexander Monakov
Cc: linux-kernel, Jaroslav Kysela, Takashi Iwai, Hui Wang,
Kailang Yang, Jeremy Szu, Jian-Hong Pan, Chris Chiu, PeiSen Hou,
alsa-devel
On Wed, 21 Jul 2021 19:01:41 +0200,
Alexander Monakov wrote:
>
> The Acer Swift SF314-42 laptop is using Realtek ALC255 codec. Add a
> quirk so microphone in a headset connected via the right-hand side jack
> is usable.
>
> Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.com>
> Cc: Hui Wang <hui.wang@canonical.com>
> Cc: Kailang Yang <kailang@realtek.com>
> Cc: Jeremy Szu <jeremy.szu@canonical.com>
> Cc: Jian-Hong Pan <jhp@endlessos.org>
> Cc: Chris Chiu <chris.chiu@canonical.com>
> Cc: PeiSen Hou <pshou@realtek.com>
> Cc: alsa-devel@alsa-project.org
> ---
> Hello,
>
> Acer Swift SF314-42 laptop is using AMD Ryzen SoC audio with Realtek
> ALC255 codec. The are three ALSA cards: HDMI audio, AMD ACP card, and
> AMD HDA card. There is an internal stereo microphone connected to the
> ACP card, and a mini-jack connected to the Realtek codec. There are no
> LEDs.
>
> I'd like to be able to use a mic+headphones headset. Unfortunately, out
> of the box ALSA does not correctly detect the microphone input of the
> Realtek codec. The suggested patch fixes that, though I cannot be sure
> it's 100% correct.
>
> With the patch, the experience is unfortunately still not ideal. I have
> noticed a couple of issues:
>
> 1) at high enough gain, recording the microphone is picking up what is
> being played via the headphones; maybe it's supposed to be like that,
> but it surprised me;
Hrm, that doesn't sound right. Some internal loopback in the codec?
Dunno. It doesn't pick up the sound physically, right?
> 2) there is a very noticeable "pop" when plugging the headset in/out,
> accompanied by
>
> pcieport 0000:00:08.1: PME: Spurious native interrupt!
> pcieport 0000:00:08.1: PME: Spurious native interrupt!
>
> in dmesg. I'd appreciate info and any help about this issue.
The pop noise is often a thing with the codec and there are a bunch of
different workarounds found in the driver. But the spurious interrupt
is more worrisome. Is the PCI slot corresponding to the HD-audio
controller?
As of now, I'm inclined to take your patch as is, at least as a
first-aid workaround. Let's see whether we get a better development
soonish.
thanks,
Takashi
>
> Thanks.
> Alexander
>
> sound/pci/hda/patch_realtek.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index ab5113cccffa..87ad8469dbc5 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -8191,6 +8191,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", ALC233_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", ALC255_FIXUP_ACER_HEADSET_MIC),
> + SND_PCI_QUIRK(0x1025, 0x142b, "Acer Swift SF314-42", ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1025, 0x1466, "Acer Aspire A515-56", ALC255_FIXUP_ACER_HEADPHONE_AND_MIC),
> SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
>
> base-commit: 62fb9874f5da54fdb243003b386128037319b219
> --
> 2.31.1
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
@ 2021-07-28 17:02 ` Takashi Iwai
0 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2021-07-28 17:02 UTC (permalink / raw)
To: Alexander Monakov
Cc: Chris Chiu, Jian-Hong Pan, Kailang Yang, alsa-devel, Jeremy Szu,
Takashi Iwai, linux-kernel, Hui Wang, PeiSen Hou
On Wed, 21 Jul 2021 19:01:41 +0200,
Alexander Monakov wrote:
>
> The Acer Swift SF314-42 laptop is using Realtek ALC255 codec. Add a
> quirk so microphone in a headset connected via the right-hand side jack
> is usable.
>
> Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.com>
> Cc: Hui Wang <hui.wang@canonical.com>
> Cc: Kailang Yang <kailang@realtek.com>
> Cc: Jeremy Szu <jeremy.szu@canonical.com>
> Cc: Jian-Hong Pan <jhp@endlessos.org>
> Cc: Chris Chiu <chris.chiu@canonical.com>
> Cc: PeiSen Hou <pshou@realtek.com>
> Cc: alsa-devel@alsa-project.org
> ---
> Hello,
>
> Acer Swift SF314-42 laptop is using AMD Ryzen SoC audio with Realtek
> ALC255 codec. The are three ALSA cards: HDMI audio, AMD ACP card, and
> AMD HDA card. There is an internal stereo microphone connected to the
> ACP card, and a mini-jack connected to the Realtek codec. There are no
> LEDs.
>
> I'd like to be able to use a mic+headphones headset. Unfortunately, out
> of the box ALSA does not correctly detect the microphone input of the
> Realtek codec. The suggested patch fixes that, though I cannot be sure
> it's 100% correct.
>
> With the patch, the experience is unfortunately still not ideal. I have
> noticed a couple of issues:
>
> 1) at high enough gain, recording the microphone is picking up what is
> being played via the headphones; maybe it's supposed to be like that,
> but it surprised me;
Hrm, that doesn't sound right. Some internal loopback in the codec?
Dunno. It doesn't pick up the sound physically, right?
> 2) there is a very noticeable "pop" when plugging the headset in/out,
> accompanied by
>
> pcieport 0000:00:08.1: PME: Spurious native interrupt!
> pcieport 0000:00:08.1: PME: Spurious native interrupt!
>
> in dmesg. I'd appreciate info and any help about this issue.
The pop noise is often a thing with the codec and there are a bunch of
different workarounds found in the driver. But the spurious interrupt
is more worrisome. Is the PCI slot corresponding to the HD-audio
controller?
As of now, I'm inclined to take your patch as is, at least as a
first-aid workaround. Let's see whether we get a better development
soonish.
thanks,
Takashi
>
> Thanks.
> Alexander
>
> sound/pci/hda/patch_realtek.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index ab5113cccffa..87ad8469dbc5 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -8191,6 +8191,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", ALC233_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", ALC255_FIXUP_ACER_HEADSET_MIC),
> + SND_PCI_QUIRK(0x1025, 0x142b, "Acer Swift SF314-42", ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1025, 0x1466, "Acer Aspire A515-56", ALC255_FIXUP_ACER_HEADPHONE_AND_MIC),
> SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
>
> base-commit: 62fb9874f5da54fdb243003b386128037319b219
> --
> 2.31.1
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-07-28 17:02 ` Takashi Iwai
@ 2021-07-28 20:03 ` Alexander Monakov
-1 siblings, 0 replies; 12+ messages in thread
From: Alexander Monakov @ 2021-07-28 20:03 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-kernel, Jaroslav Kysela, Takashi Iwai, Hui Wang,
Kailang Yang, Jeremy Szu, Jian-Hong Pan, Chris Chiu, PeiSen Hou,
alsa-devel
On Wed, 28 Jul 2021, Takashi Iwai wrote:
> > 1) at high enough gain, recording the microphone is picking up what is
> > being played via the headphones; maybe it's supposed to be like that,
> > but it surprised me;
>
> Hrm, that doesn't sound right. Some internal loopback in the codec?
> Dunno. It doesn't pick up the sound physically, right?
How can I tell? If I don't have anything plugged into the jack, playback
uses the built-in speakers. In that case there's no feedback. And if I
plug in a headset or common headphones, then built-in speakers are automatically
muted, and recording the mic can pick up the output signal.
Is there a way to forcefully direct output to the jack instead of built-in
speakers even when there isn't anything plugged in?
I am sure it is not picking the sound over the air, but I'm considering it's
picking it up electrically near the jack somehow.
> > 2) there is a very noticeable "pop" when plugging the headset in/out,
> > accompanied by
> >
> > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> >
> > in dmesg. I'd appreciate info and any help about this issue.
>
> The pop noise is often a thing with the codec and there are a bunch of
> different workarounds found in the driver. But the spurious interrupt
> is more worrisome. Is the PCI slot corresponding to the HD-audio
> controller?
No, it's actually the PCI bridge under which the HDA core resides:
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
00:08.1/03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
Note that I have autosuspend enabled for PCI devices. If I disable PCI
autosuspend for the 03:00.6 HDA device, there's no "pop" and no spurious
interrupt. My understanding that the chip generates a power management event
when it senses a jack plug/unplug event while suspended. Apparently something
about the PME interrupt is not fully in order?
> As of now, I'm inclined to take your patch as is, at least as a
> first-aid workaround. Let's see whether we get a better development
> soonish.
*nod*, I will appreciate it!
Thank you.
Alexander
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
@ 2021-07-28 20:03 ` Alexander Monakov
0 siblings, 0 replies; 12+ messages in thread
From: Alexander Monakov @ 2021-07-28 20:03 UTC (permalink / raw)
To: Takashi Iwai
Cc: Chris Chiu, Jian-Hong Pan, Kailang Yang, alsa-devel, Jeremy Szu,
Takashi Iwai, linux-kernel, Hui Wang, PeiSen Hou
On Wed, 28 Jul 2021, Takashi Iwai wrote:
> > 1) at high enough gain, recording the microphone is picking up what is
> > being played via the headphones; maybe it's supposed to be like that,
> > but it surprised me;
>
> Hrm, that doesn't sound right. Some internal loopback in the codec?
> Dunno. It doesn't pick up the sound physically, right?
How can I tell? If I don't have anything plugged into the jack, playback
uses the built-in speakers. In that case there's no feedback. And if I
plug in a headset or common headphones, then built-in speakers are automatically
muted, and recording the mic can pick up the output signal.
Is there a way to forcefully direct output to the jack instead of built-in
speakers even when there isn't anything plugged in?
I am sure it is not picking the sound over the air, but I'm considering it's
picking it up electrically near the jack somehow.
> > 2) there is a very noticeable "pop" when plugging the headset in/out,
> > accompanied by
> >
> > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> >
> > in dmesg. I'd appreciate info and any help about this issue.
>
> The pop noise is often a thing with the codec and there are a bunch of
> different workarounds found in the driver. But the spurious interrupt
> is more worrisome. Is the PCI slot corresponding to the HD-audio
> controller?
No, it's actually the PCI bridge under which the HDA core resides:
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
00:08.1/03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
Note that I have autosuspend enabled for PCI devices. If I disable PCI
autosuspend for the 03:00.6 HDA device, there's no "pop" and no spurious
interrupt. My understanding that the chip generates a power management event
when it senses a jack plug/unplug event while suspended. Apparently something
about the PME interrupt is not fully in order?
> As of now, I'm inclined to take your patch as is, at least as a
> first-aid workaround. Let's see whether we get a better development
> soonish.
*nod*, I will appreciate it!
Thank you.
Alexander
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-07-28 20:03 ` Alexander Monakov
@ 2021-08-03 11:47 ` Takashi Iwai
-1 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2021-08-03 11:47 UTC (permalink / raw)
To: Alexander Monakov
Cc: linux-kernel, Jaroslav Kysela, Takashi Iwai, Hui Wang,
Kailang Yang, Jeremy Szu, Jian-Hong Pan, Chris Chiu, PeiSen Hou,
alsa-devel
On Wed, 28 Jul 2021 22:03:45 +0200,
Alexander Monakov wrote:
>
> On Wed, 28 Jul 2021, Takashi Iwai wrote:
>
> > > 1) at high enough gain, recording the microphone is picking up what is
> > > being played via the headphones; maybe it's supposed to be like that,
> > > but it surprised me;
> >
> > Hrm, that doesn't sound right. Some internal loopback in the codec?
> > Dunno. It doesn't pick up the sound physically, right?
>
> How can I tell? If I don't have anything plugged into the jack, playback
> uses the built-in speakers. In that case there's no feedback. And if I
> plug in a headset or common headphones, then built-in speakers are automatically
> muted, and recording the mic can pick up the output signal.
>
> Is there a way to forcefully direct output to the jack instead of built-in
> speakers even when there isn't anything plugged in?
>
> I am sure it is not picking the sound over the air, but I'm considering it's
> picking it up electrically near the jack somehow.
>
> > > 2) there is a very noticeable "pop" when plugging the headset in/out,
> > > accompanied by
> > >
> > > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> > > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> > >
> > > in dmesg. I'd appreciate info and any help about this issue.
> >
> > The pop noise is often a thing with the codec and there are a bunch of
> > different workarounds found in the driver. But the spurious interrupt
> > is more worrisome. Is the PCI slot corresponding to the HD-audio
> > controller?
>
> No, it's actually the PCI bridge under which the HDA core resides:
>
> 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
> 00:08.1/03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
>
> Note that I have autosuspend enabled for PCI devices. If I disable PCI
> autosuspend for the 03:00.6 HDA device, there's no "pop" and no spurious
> interrupt. My understanding that the chip generates a power management event
> when it senses a jack plug/unplug event while suspended. Apparently something
> about the PME interrupt is not fully in order?
>
> > As of now, I'm inclined to take your patch as is, at least as a
> > first-aid workaround. Let's see whether we get a better development
> > soonish.
>
> *nod*, I will appreciate it!
FYI, I merged the fix to for-linus branch, which will be likely
included in Linus tree in this week.
For the rest issue, at least about the bogus messages from PCI bridge,
better to report to the PCI subsystem. It's possibly some missing PCI
quirk for the specific chip.
thanks,
Takashi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
@ 2021-08-03 11:47 ` Takashi Iwai
0 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2021-08-03 11:47 UTC (permalink / raw)
To: Alexander Monakov
Cc: Chris Chiu, Jian-Hong Pan, Kailang Yang, alsa-devel, Jeremy Szu,
Takashi Iwai, linux-kernel, Hui Wang, PeiSen Hou
On Wed, 28 Jul 2021 22:03:45 +0200,
Alexander Monakov wrote:
>
> On Wed, 28 Jul 2021, Takashi Iwai wrote:
>
> > > 1) at high enough gain, recording the microphone is picking up what is
> > > being played via the headphones; maybe it's supposed to be like that,
> > > but it surprised me;
> >
> > Hrm, that doesn't sound right. Some internal loopback in the codec?
> > Dunno. It doesn't pick up the sound physically, right?
>
> How can I tell? If I don't have anything plugged into the jack, playback
> uses the built-in speakers. In that case there's no feedback. And if I
> plug in a headset or common headphones, then built-in speakers are automatically
> muted, and recording the mic can pick up the output signal.
>
> Is there a way to forcefully direct output to the jack instead of built-in
> speakers even when there isn't anything plugged in?
>
> I am sure it is not picking the sound over the air, but I'm considering it's
> picking it up electrically near the jack somehow.
>
> > > 2) there is a very noticeable "pop" when plugging the headset in/out,
> > > accompanied by
> > >
> > > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> > > pcieport 0000:00:08.1: PME: Spurious native interrupt!
> > >
> > > in dmesg. I'd appreciate info and any help about this issue.
> >
> > The pop noise is often a thing with the codec and there are a bunch of
> > different workarounds found in the driver. But the spurious interrupt
> > is more worrisome. Is the PCI slot corresponding to the HD-audio
> > controller?
>
> No, it's actually the PCI bridge under which the HDA core resides:
>
> 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
> 00:08.1/03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
>
> Note that I have autosuspend enabled for PCI devices. If I disable PCI
> autosuspend for the 03:00.6 HDA device, there's no "pop" and no spurious
> interrupt. My understanding that the chip generates a power management event
> when it senses a jack plug/unplug event while suspended. Apparently something
> about the PME interrupt is not fully in order?
>
> > As of now, I'm inclined to take your patch as is, at least as a
> > first-aid workaround. Let's see whether we get a better development
> > soonish.
>
> *nod*, I will appreciate it!
FYI, I merged the fix to for-linus branch, which will be likely
included in Linus tree in this week.
For the rest issue, at least about the bogus messages from PCI bridge,
better to report to the PCI subsystem. It's possibly some missing PCI
quirk for the specific chip.
thanks,
Takashi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-07-21 17:01 ` Alexander Monakov
(?)
(?)
@ 2021-07-31 22:37 ` Nikos Liolios
2021-08-01 7:00 ` Alexander Monakov
-1 siblings, 1 reply; 12+ messages in thread
From: Nikos Liolios @ 2021-07-31 22:37 UTC (permalink / raw)
To: Alexander Monakov; +Cc: alsa-devel, Takashi Iwai
On Wed, 21 Jul 2021 20:01:41 +0300,
Alexander Monakov <amonakov@ispras.ru> wrote:
> The Acer Swift SF314-42 laptop is using Realtek ALC255 codec. Add a
> quirk so microphone in a headset connected via the right-hand side jack
> is usable.
>
>
> sound/pci/hda/patch_realtek.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index ab5113cccffa..87ad8469dbc5 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -8191,6 +8191,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", ALC233_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", ALC255_FIXUP_ACER_HEADSET_MIC),
> + SND_PCI_QUIRK(0x1025, 0x142b, "Acer Swift SF314-42", ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1025, 0x1466, "Acer Aspire A515-56", ALC255_FIXUP_ACER_HEADPHONE_AND_MIC),
> SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
>
> base-commit: 62fb9874f5da54fdb243003b386128037319b219
Other quirks for Acer Swift (for Acer SWIFT SF314-54/55/56) they describe the model using capital letters ("SWIFT" instead of "Swift").
I do think that "Swift" is better than (caps locked) "SWIFT". Thinking to create a patch for it since I helped to create this mess.
From my understanding it only affects the dmesg of which quirk was used, nothing important, but lets keep code clean.
What do you think? Rename "SWIFT"s to "Swift"s?
If no disagreement or no reply I am doing it like tomorrow.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-07-31 22:37 ` Nikos Liolios
@ 2021-08-01 7:00 ` Alexander Monakov
2021-08-01 7:39 ` Takashi Iwai
0 siblings, 1 reply; 12+ messages in thread
From: Alexander Monakov @ 2021-08-01 7:00 UTC (permalink / raw)
To: Nikos Liolios; +Cc: alsa-devel, Takashi Iwai
On Sun, 1 Aug 2021, Nikos Liolios wrote:
> Other quirks for Acer Swift (for Acer SWIFT SF314-54/55/56) they describe the
> model using capital letters ("SWIFT" instead of "Swift"). I do think that
> "Swift" is better than (caps locked) "SWIFT". Thinking to create a patch for
> it since I helped to create this mess. From my understanding it only affects
> the dmesg of which quirk was used, nothing important, but lets keep code
> clean.
>
> What do you think? Rename "SWIFT"s to "Swift"s?
> If no disagreement or no reply I am doing it like tomorrow.
I agree "Swift" would be better: as far as I can tell, Acer mostly uses "Swift"
(both in marketing materials and DMI information). I would support the rename.
Thanks.
Alexander
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-08-01 7:00 ` Alexander Monakov
@ 2021-08-01 7:39 ` Takashi Iwai
2021-08-01 11:01 ` Nikos Liolios
0 siblings, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2021-08-01 7:39 UTC (permalink / raw)
To: Alexander Monakov; +Cc: alsa-devel, Nikos Liolios, Takashi Iwai
On Sun, 01 Aug 2021 09:00:48 +0200,
Alexander Monakov wrote:
>
> On Sun, 1 Aug 2021, Nikos Liolios wrote:
>
> > Other quirks for Acer Swift (for Acer SWIFT SF314-54/55/56) they describe the
> > model using capital letters ("SWIFT" instead of "Swift"). I do think that
> > "Swift" is better than (caps locked) "SWIFT". Thinking to create a patch for
> > it since I helped to create this mess. From my understanding it only affects
> > the dmesg of which quirk was used, nothing important, but lets keep code
> > clean.
> >
> > What do you think? Rename "SWIFT"s to "Swift"s?
> > If no disagreement or no reply I am doing it like tomorrow.
>
> I agree "Swift" would be better: as far as I can tell, Acer mostly uses "Swift"
> (both in marketing materials and DMI information). I would support the rename.
That's a really bikeshed topic, and I don't think we need an extra
patch to correct it. The message is only for debug prints, usually
you don't see it.
thanks,
Takashi
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42
2021-08-01 7:39 ` Takashi Iwai
@ 2021-08-01 11:01 ` Nikos Liolios
0 siblings, 0 replies; 12+ messages in thread
From: Nikos Liolios @ 2021-08-01 11:01 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Alexander Monakov, Takashi Iwai
On Sun, 01 Aug 2021 10:39:13 +0300,
Takashi Iwai <tiwai@suse.de> wrote:
> On Sun, 01 Aug 2021 09:00:48 +0200,
> Alexander Monakov wrote:
>>
>> On Sun, 1 Aug 2021, Nikos Liolios wrote:
>>
>>> Other quirks for Acer Swift (for Acer SWIFT SF314-54/55/56) they describe the
>>> model using capital letters ("SWIFT" instead of "Swift"). I do think that
>>> "Swift" is better than (caps locked) "SWIFT". Thinking to create a patch for
>>> it since I helped to create this mess. From my understanding it only affects
>>> the dmesg of which quirk was used, nothing important, but lets keep code
>>> clean.
>>>
>>> What do you think? Rename "SWIFT"s to "Swift"s?
>>> If no disagreement or no reply I am doing it like tomorrow.
>>
>> I agree "Swift" would be better: as far as I can tell, Acer mostly uses "Swift"
>> (both in marketing materials and DMI information). I would support the rename.
>
> That's a really bikeshed topic, and I don't think we need an extra
> patch to correct it. The message is only for debug prints, usually
> you don't see it.
>
>
> thanks,
>
> Takashi
>
I will respect your/Takashi's opinion. Won't do any such patch.
Thank you for letting me know beforehand.
^ permalink raw reply [flat|nested] 12+ messages in thread