From: Takashi Iwai <tiwai@suse.de>
To: "Christopher Höner" <christopher-hoener@web.de>
Cc: tiwai@suse.de, linux-kernel@vger.kernel.org,
linux-sound@vger.kernel.org, perex@perex.cz, tiwai@suse.com
Subject: Re: [PATCH v2] ALSA: hda/realtek: Enable internal speakers on Razer Blade 16 (2025)
Date: Tue, 23 Jun 2026 12:42:25 +0200 [thread overview]
Message-ID: <87cxxhczce.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260622174309.5873-1-christopher-hoener@web.de>
On Mon, 22 Jun 2026 19:43:09 +0200,
Christopher Höner wrote:
>
> Hi Takashi,
>
> Thanks for the review.
>
> On the size: agreed, that was too much to sit inline. v3 moves the
> captured DSP tables into a separate header (alc298_rb16_2025.h) that the
> codec includes, so alc269.c keeps only the apply helper, the PCM hook
> and the fixup.
Thanks! We have this kind of large code in sound/hda/codecs/helpers,
and you can follow the pattern, too.
> On power_save_node: I tried it and it does work. The catch is that the
> amp wake and park have to come out of the init sequence first, the park
> in particular. If the amp is parked at the end of init, nothing wakes it
> again, since power_save_node only toggles the codec's own widgets and the
> amp isn't one of them; it sits behind the coef mailbox on NID 0x20 and
> isn't a power-managed node. Dropping the init wake as well seemed fine
> here, though I'm less sure about that one, since the Windows driver does
> send a wake at init.
>
> With the amp left on and power_save_node handling the widget PM, playback
> is fine. The one thing I noticed is that every stream then starts with a
> small but audible click, the speaker DAC and pin going D3->D0 in a single
> step. The mailbox wake/park ramps the amp up and down instead, so the
> hook path doesn't click, and for me that transition is the nicer result.
>
> The trade-offs run the other way too. power_save_node would let the codec
> power its widgets down when idle, which on a laptop is probably worth
> having, and I can't really put a number on what the hook costs by leaving
> them up, so I'm not weighing that part heavily. The fact that it's
> codec-wide is presumably a good thing for the headphone and the mics too;
> I don't know that side well enough to have a strong opinion there.
>
> Where I landed for v3 was the pcm_playback_hook with power_save_node left
> at its default, mostly for the cleaner transition, and because it matches
> the other ALC298 external-amp fixups: Samsung and LG Gram both drive the
> amp from a pcm_playback_hook and leave power_save_node alone,
> alc274_fixup_bind_dacs sets it to 0, and alc_fixup_tpt440_dock sets it to
> 0 specifically to avoid click noises.
>
> That said, you've seen far more of these than I have, and I don't have a
> strong stake in the PM side beyond that transition. If you'd rather this
> used power_save_node, say so and I'll switch v3 over: drop the wake/park
> and let the widgets manage themselves.
Hm, indeed there is no direct hook associated to each widget node for
the power amp. A tricky way would be, though, to use the existing
codec->power_filter callback; you can define something like:
static int razer_amp_power_filter(struct hda_codec *codec, hda_nid_t nid,
unsigned int power_state)
{
int state = snd_hda_gen_path_power_filter(codec, nid, power_state);
if (nid == SOME_OUTPUT_PIN) {
if (state == AC_PWRST_D0)
power_up_amp(codec, nid);
else
power_down_amp(codec, nid);
}
return state;
}
and set codec->power_filter = razer_amp_power_filter in the fixup,
together with codec->power_save_node = 1.
It's just an idea, and if this doesn't look working well, we can go
with your approach with the PCM hook, too.
thanks,
Takashi
next prev parent reply other threads:[~2026-06-23 10:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-20 14:41 [PATCH] ALSA: hda/realtek: Enable internal speakers on Razer Blade 16 (2025) Christopher Höner
2026-06-21 20:57 ` [PATCH v2] " Christopher Höner
2026-06-22 8:55 ` Takashi Iwai
2026-06-22 17:43 ` Christopher Höner
2026-06-23 10:42 ` Takashi Iwai [this message]
2026-06-23 19:02 ` [PATCH v3] " Christopher Höner
2026-06-26 5:48 ` Takashi Iwai
2026-06-23 19:14 ` [PATCH v4] " Christopher Höner
2026-06-22 17:51 ` [PATCH v3] " Christopher Höner
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=87cxxhczce.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=christopher-hoener@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--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 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.