From: Takashi Iwai <tiwai@suse.de>
To: Steven Kendall <skend@chromium.org>
Cc: Takashi Iwai <tiwai@suse.de>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect
Date: Wed, 15 Jul 2026 09:47:33 +0200 [thread overview]
Message-ID: <87se5ky9re.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAB1bpFCNC1NWYpBRzzuxQMFN2wugSYUq2G6tkeoiT=ThUE094A@mail.gmail.com>
On Tue, 14 Jul 2026 21:51:21 +0200,
Steven Kendall wrote:
>
> > This makes the remaining text not taken by git-am.
> > And, I guess the text above should have been combined with the below?
>
> Sorry about that! I'm using b4 and that was the result of having a
> cover letter in addition to the commit.
If you want to give additional comments that shouldn't be included in
the commit log, put it under '---' line, instead. Then it'll be cut
off.
> > The jack polling is really the last resort, and I'd like to know why
> > the normal jack detection doesn't work at first. Is it the missing
> > unsol event? Or the jack detection itself doesn't work?
> > If it's a missing unsol event, this drop happens always? Or on
> > certain runtime PM state?
>
> In my debugging output I could never get the unsol event to trigger.
> I'm not sure if that's the same as jack detection not working. I tried
> a few timing changes and pin changes but to no effect. From the user's
> perspective, audio plays both from the headphones and the speakers
> when headphones are plugged in. According to my notes, I also observed
> this on Ubuntu 22.04 LTS on its initial image, but applying its
> latest update resolved the issue. One notable clue is that currently
> on Chrome OS (with no patch), sleeping and resuming the machine does
> fix jack detection, but I've been unable to fix initial boot behavior
> thus far besides an approach like the patch here.
Have you tried to turn off the runtime PM for HD-audio?
The question is whether the unsol event doesn't work *at all*, or it
just stops when the codec (or the controller) is powered down.
Also, CS8409 driver enables the per-node power-save feature, and this
might influence, too.
Takashi
next prev parent reply other threads:[~2026-07-15 7:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 21:21 Steven 'Steve' Kendall
2026-07-14 5:50 ` Takashi Iwai
2026-07-14 19:51 ` Steven Kendall
2026-07-15 7:47 ` Takashi Iwai [this message]
2026-07-17 21:18 ` Steven Kendall
2026-07-14 16:17 ` Stefan Binding
2026-07-14 19:26 ` Steven Kendall
2026-07-15 15:16 ` Stefan Binding
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=87se5ky9re.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=skend@chromium.org \
--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