[PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Alexander Kaplan]

On Panther Lake the keep-alive engine poisons the display side of the
audio path for multichannel PCM.
Once KAE has been active in the running display power cycle, the first
6 or 8 channel stream on that pin plays silent and wedges the pin.
All subsequent streams stay silent regardless of their format.
Only a display power domain cycle recovers the pin, in practice a
reboot or one suspend cycle.

The wedge sits behind the audio converter.
Sample counters in the display audio register block keep running during
the silent playback while the output stays dead.
The wedge survives clearing the KAE bit ahead of the stream id
programming, fully quiescing the converter (KAE bit, stream id and
format cleared before the multichannel setup), a complete codec and
controller reset through a driver rebind with the keep-alive kept off,
and powering down the audio well for ten minutes.
The sequence is harmless when the keep-alive was never enabled in the
running display power cycle, which isolates the KAE hardware as the
trigger.

Easy reproducer on a sink whose LPCM capability is limited to
2 channels:
speaker-test -c2 plays, one speaker-test -c6 run plays silent and every
following speaker-test -c2 stays silent until reboot.
With enable_silent_stream=0 the same sequence plays normally.

This is the failure class already known from commit 6ab6f98fcdc9
("ALSA: hda/hdmi: disable KAE for Intel DG2").
Handle Panther Lake like DG2 and fall back to the older i915 silent
stream method, which uses the regular stream path instead of the
keep-alive engine.
Like on DG2 this keeps the codec powered while the silent stream runs.

Cc: stable@vger.kernel.org
Fixes: e9481d9b83f8 ("ALSA: hda: add HDMI codec ID for Intel PTL")
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
---
Found and verified on an ASUS NUC 16 Pro (Panther Lake H, codec
0x80862822) driving an LG TV through a Synaptics VMM7100 DP-to-HDMI
protocol converter, kernel 7.1-rc7.
The poisoning is independent of the sink and of the video mode.

This may also fix the silent Dolby TrueHD passthrough on Battlemage
reported in
https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7515.
Battlemage uses the same keep-alive code path and TrueHD passthrough
is the same first-multichannel-stream pattern, but I could not test
that hardware.

Workaround for affected systems without this patch:
snd_hda_codec_intelhdmi.enable_silent_stream=0.

 sound/hda/codecs/hdmi/intelhdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/hda/codecs/hdmi/intelhdmi.c b/sound/hda/codecs/hdmi/intelhdmi.c
index 6a7882544a..52997caae9 100644
--- a/sound/hda/codecs/hdmi/intelhdmi.c
+++ b/sound/hda/codecs/hdmi/intelhdmi.c
@@ -791,7 +791,7 @@ static const struct hda_device_id snd_hda_id_intelhdmi[] = {
 	HDA_CODEC_ID_MODEL(0x8086281e, "Battlemage HDMI",	MODEL_ADLP),
 	HDA_CODEC_ID_MODEL(0x8086281f, "Raptor Lake P HDMI",	MODEL_ADLP),
 	HDA_CODEC_ID_MODEL(0x80862820, "Lunar Lake HDMI",	MODEL_ADLP),
-	HDA_CODEC_ID_MODEL(0x80862822, "Panther Lake HDMI",	MODEL_ADLP),
+	HDA_CODEC_ID_MODEL(0x80862822, "Panther Lake HDMI",	MODEL_TGL),
 	HDA_CODEC_ID_MODEL(0x80862823, "Wildcat Lake HDMI",	MODEL_ADLP),
 	HDA_CODEC_ID_MODEL(0x80862824, "Nova Lake HDMI",	MODEL_ADLP),
 	HDA_CODEC_ID_MODEL(0x80862882, "Valleyview2 HDMI",	MODEL_BYT),
-- 
2.54.0

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Péter Ujfalusi]

Hi,

On 10/06/2026 20:48, Alexander Kaplan wrote:
> On Panther Lake the keep-alive engine poisons the display side of the
> audio path for multichannel PCM.
> Once KAE has been active in the running display power cycle, the first
> 6 or 8 channel stream on that pin plays silent and wedges the pin.
> All subsequent streams stay silent regardless of their format.
> Only a display power domain cycle recovers the pin, in practice a
> reboot or one suspend cycle.
> 
> The wedge sits behind the audio converter.
> Sample counters in the display audio register block keep running during
> the silent playback while the output stays dead.
> The wedge survives clearing the KAE bit ahead of the stream id
> programming, fully quiescing the converter (KAE bit, stream id and
> format cleared before the multichannel setup), a complete codec and
> controller reset through a driver rebind with the keep-alive kept off,
> and powering down the audio well for ten minutes.
> The sequence is harmless when the keep-alive was never enabled in the
> running display power cycle, which isolates the KAE hardware as the
> trigger.
> 
> Easy reproducer on a sink whose LPCM capability is limited to
> 2 channels:
> speaker-test -c2 plays, one speaker-test -c6 run plays silent and every
> following speaker-test -c2 stays silent until reboot.
> With enable_silent_stream=0 the same sequence plays normally.

Normally I have KAE disabled for power saving reasons on my laptops, but
did a quick test on my PTL:
# cat /proc/asound/card0/codec#2 | grep KAE
  Digital: Enabled KAE

speaker-test -c2 / -c6 works as many times as I run them in all permutation.

> 
> This is the failure class already known from commit 6ab6f98fcdc9
> ("ALSA: hda/hdmi: disable KAE for Intel DG2").
> Handle Panther Lake like DG2 and fall back to the older i915 silent
> stream method, which uses the regular stream path instead of the
> keep-alive engine.
> Like on DG2 this keeps the codec powered while the silent stream runs.
> 
> Cc: stable@vger.kernel.org
> Fixes: e9481d9b83f8 ("ALSA: hda: add HDMI codec ID for Intel PTL")
> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
> ---
> Found and verified on an ASUS NUC 16 Pro (Panther Lake H, codec
> 0x80862822) driving an LG TV through a Synaptics VMM7100 DP-to-HDMI
> protocol converter, kernel 7.1-rc7.
> The poisoning is independent of the sink and of the video mode.

My setup is: laptop HDMI -> SYNIC HDMI audio extractor -> HDMI KVM ->
monitor w/o speakers.
I use the extractor to grab the audio and it is clean every time I play
audio to HDMI.

Can this be somehow related to the DP-to-HDMI converter? Have you tested
that with other machine?
Or a combination of xe2+DP-to-HDMI?

Ccing Uma for display side
> This may also fix the silent Dolby TrueHD passthrough on Battlemage
> reported in
> https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7515.
> Battlemage uses the same keep-alive code path and TrueHD passthrough
> is the same first-multichannel-stream pattern, but I could not test
> that hardware.
> 
> Workaround for affected systems without this patch:
> snd_hda_codec_intelhdmi.enable_silent_stream=0.
> 
>  sound/hda/codecs/hdmi/intelhdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/hda/codecs/hdmi/intelhdmi.c b/sound/hda/codecs/hdmi/intelhdmi.c
> index 6a7882544a..52997caae9 100644
> --- a/sound/hda/codecs/hdmi/intelhdmi.c
> +++ b/sound/hda/codecs/hdmi/intelhdmi.c
> @@ -791,7 +791,7 @@ static const struct hda_device_id snd_hda_id_intelhdmi[] = {
>  	HDA_CODEC_ID_MODEL(0x8086281e, "Battlemage HDMI",	MODEL_ADLP),
>  	HDA_CODEC_ID_MODEL(0x8086281f, "Raptor Lake P HDMI",	MODEL_ADLP),
>  	HDA_CODEC_ID_MODEL(0x80862820, "Lunar Lake HDMI",	MODEL_ADLP),
> -	HDA_CODEC_ID_MODEL(0x80862822, "Panther Lake HDMI",	MODEL_ADLP),
> +	HDA_CODEC_ID_MODEL(0x80862822, "Panther Lake HDMI",	MODEL_TGL),
>  	HDA_CODEC_ID_MODEL(0x80862823, "Wildcat Lake HDMI",	MODEL_ADLP),
>  	HDA_CODEC_ID_MODEL(0x80862824, "Nova Lake HDMI",	MODEL_ADLP),
>  	HDA_CODEC_ID_MODEL(0x80862882, "Valleyview2 HDMI",	MODEL_BYT),

-- 
Péter

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Péter Ujfalusi]

On 11/06/2026 12:08, Péter Ujfalusi wrote:
> My setup is: laptop HDMI -> SYNIC HDMI audio extractor -> HDMI KVM ->
> monitor w/o speakers.
> I use the extractor to grab the audio and it is clean every time I play
> audio to HDMI.

Just to rule out iffy equipment on my side, I have connected the PTL
laptop to my Denon AVR both in SOF and legacy HDA mode. I cannot hear
any issue regarding to audio on my 5.1 speaker set.

> Can this be somehow related to the DP-to-HDMI converter? Have you tested
> that with other machine?
> Or a combination of xe2+DP-to-HDMI?
> 
> Ccing Uma for display side
>> This may also fix the silent Dolby TrueHD passthrough on Battlemage
>> reported in
>> https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7515.
>> Battlemage uses the same keep-alive code path and TrueHD passthrough
>> is the same first-multichannel-stream pattern, but I could not test
>> that hardware.
>>
>> Workaround for affected systems without this patch:
>> snd_hda_codec_intelhdmi.enable_silent_stream=0.
>>
>>  sound/hda/codecs/hdmi/intelhdmi.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sound/hda/codecs/hdmi/intelhdmi.c b/sound/hda/codecs/hdmi/intelhdmi.c
>> index 6a7882544a..52997caae9 100644
>> --- a/sound/hda/codecs/hdmi/intelhdmi.c
>> +++ b/sound/hda/codecs/hdmi/intelhdmi.c
>> @@ -791,7 +791,7 @@ static const struct hda_device_id snd_hda_id_intelhdmi[] = {
>>  	HDA_CODEC_ID_MODEL(0x8086281e, "Battlemage HDMI",	MODEL_ADLP),
>>  	HDA_CODEC_ID_MODEL(0x8086281f, "Raptor Lake P HDMI",	MODEL_ADLP),
>>  	HDA_CODEC_ID_MODEL(0x80862820, "Lunar Lake HDMI",	MODEL_ADLP),
>> -	HDA_CODEC_ID_MODEL(0x80862822, "Panther Lake HDMI",	MODEL_ADLP),
>> +	HDA_CODEC_ID_MODEL(0x80862822, "Panther Lake HDMI",	MODEL_TGL),
>>  	HDA_CODEC_ID_MODEL(0x80862823, "Wildcat Lake HDMI",	MODEL_ADLP),
>>  	HDA_CODEC_ID_MODEL(0x80862824, "Nova Lake HDMI",	MODEL_ADLP),
>>  	HDA_CODEC_ID_MODEL(0x80862882, "Valleyview2 HDMI",	MODEL_BYT),
> 

-- 
Péter

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Alexander Kaplan]

On 11/06/2026 12:33, Péter Ujfalusi wrote:
>> My setup is: laptop HDMI -> SYNIC HDMI audio extractor -> HDMI KVM ->
>> monitor w/o speakers.
>> I use the extractor to grab the audio and it is clean every time I play
>> audio to HDMI.
>
> Just to rule out iffy equipment on my side, I have connected the PTL
> laptop to my Denon AVR both in SOF and legacy HDA mode. I cannot hear
> any issue regarding to audio on my 5.1 speaker set.

Hi Péter,

thanks for testing this and for pulling in Uma.

Your two setups have one thing in common.
Both use the native HDMI port of the laptop.
That turned out to be the missing piece.
I spent the day on a discrimination matrix here and your result now fits the picture exactly.

This machine also has a native HDMI port next to the USB-C ports.
On native HDMI the wedge does not reproduce at all.
With KAE enabled the same stereo to 6 and 8 channel transitions play fine on the same TV.

>> Can this be somehow related to the DP-to-HDMI converter? Have you tested
>> that with other machine?
>> Or a combination of xe2+DP-to-HDMI?

I only have this one PTL machine, so no cross machine data from me.
But the converter question was the right direction, with one important refinement.
The DP path is required to trigger the wedge, while the stuck state itself sits on the host side.

The wedge reproduces on all three DP-alt to HDMI converters I have.
A Club3D CAC-2505 with Synaptics VMM7100 firmware 7.1, a Cable Matters adapter on the VMM7100 7.2 firmware line and a Thunderbolt 4 dock with an integrated Synaptics converter.

Once wedged, the state survives a converter replug, a move to the other USB-C port and a full TV power cycle (forced reboot of the TV over the network while everything stayed connected).
Only a host suspend cycle or reboot clears it.
While wedged on the converter path, moving the TV cable to the native HDMI port plays immediately.
Moving it back to the converter wedges again.
So nothing downstream of the host holds the state.
It lives in the display side of the PTL audio path and only shows on DP.

Some register level observations from the wedged state, maybe they help locating it internally.
During the wedged silent playback the sample counters in the display audio register block at 0x65e04 and 0x650d0 keep advancing at the expected rate for the stream format.
So the samples still arrive at the display side and the stream dies further down, behind the audio converter.
There is also a register at 0x65f20 in that block which the driver does not define anywhere, directly behind AUD_CHICKENBIT_REG3 at 0x65f1c.
With a 2 channel stream running its low bits read 0x482 in the healthy state and 0x4a1 in the wedged state.
The same readback shows 0x4a1 as the normal value while a 6 channel stream plays, so it has to be sampled with a stereo stream.
That readback follows the wedge through everything that does not power cycle the display.
And 0x65e04 only counts at all while KAE is enabled, with this patch applied it stays at zero, so it seems to belong to the keep-alive machinery itself.

There are also visible display side effects while KAE is in use, maybe interesting for Uma.
Starting a 6 channel stream through the converter makes the TV drop from HDR to SDR.
Starting an 8 channel stream blanks the picture for a moment and HDR survives.
Stereo does neither.
Both effects are gone with the patch applied.
So the KAE to stream transition seems to disturb more of the SDP transmission on the DP path than just the audio samples.

Two caveats I want to be transparent about.
All my DP sinks are Synaptics protocol converters and I have no plain DP monitor here.
So I cannot tell whether plain DP audio is affected or only the DP plus PCON combination.
That should be quick to check on your side.
And the native HDMI immunity is based on this one machine and one TV.

For completeness, the sink does not explain the split.
The TV advertises 2 channel LPCM only, on the converter path and on native HDMI alike, and native HDMI still plays every format.

One unrelated observation from the native HDMI tests, in case someone trips over it while reproducing.
This TV takes anywhere between a second and a few minutes to lock onto a new channel layout on native HDMI.
The delay is the same with KAE enabled and with this patch applied, so KAE plays no role in it.
During that time the host output is provably healthy, the PCM keeps running and the audio infoframe is correct for the new layout.
Stopping the player for a few seconds and starting it again makes the TV lock immediately.
That is a sink quirk.

On the patch form.
I am aware the model change gives up the KAE power benefit for the whole platform, like the DG2 change did, and PTL is mostly a mobile platform.
If you prefer a narrower fix I can gate the silent stream type on the ELD connection type instead, so native HDMI pins keep KAE and only DP pins fall back to the older method.
Given that the HDMI immunity rests on a single machine I did not want to make that call unilaterally.

If you want to reproduce, a VMM7100 based USB-C to HDMI adapter plus one multichannel PCM stream should show it within a minute.

Should the Battlemage boards drive their HDMI ports through an onboard protocol converter like the DG2 boards did, the TrueHD report in issue 7515 would fit this same pattern.

Regards,
Alexander

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Péter Ujfalusi]

Hi Alexander,

On 11/06/2026 17:44, Alexander Kaplan wrote:
> On 11/06/2026 12:33, Péter Ujfalusi wrote:
>>> My setup is: laptop HDMI -> SYNIC HDMI audio extractor -> HDMI KVM ->
>>> monitor w/o speakers.
>>> I use the extractor to grab the audio and it is clean every time I play
>>> audio to HDMI.
>>
>> Just to rule out iffy equipment on my side, I have connected the PTL
>> laptop to my Denon AVR both in SOF and legacy HDA mode. I cannot hear
>> any issue regarding to audio on my 5.1 speaker set.
> 
> Hi Péter,
> 
> thanks for testing this and for pulling in Uma.
> 
> Your two setups have one thing in common.
> Both use the native HDMI port of the laptop.
> That turned out to be the missing piece.
> I spent the day on a discrimination matrix here and your result now fits the picture exactly.
> 
> This machine also has a native HDMI port next to the USB-C ports.
> On native HDMI the wedge does not reproduce at all.
> With KAE enabled the same stereo to 6 and 8 channel transitions play fine on the same TV.

I did not had too much time to test this, but I did found an old Dell
TB16 Dock stashed away.
With that I can reproduce the same issue on my PTL laptop. Out of
curiosity I gave this a try on an LNL laptop and the same thing happens.

Note: via TB16 dock I can _never_ hear 6ch audio, it is always silent,
only stereo goes through:
options snd_hda_codec_intelhdmi enable_silent_stream=false
-c2 - audible, clips the start
-c6 - not audible
-c2 - audible, takes time, but works

options snd_hda_codec_intelhdmi enable_silent_stream=true
-c2 - audible, clips the start
-c6 - not audible
-c2 - not audible
nothing will be audible from this point, I need to disconnect dock,
power cycle it, suspend/resume laptop, reconnect type-c and -c2 audible
again.

I'm not sure where the bug is and I'm not sure how a fix would look
like, this needs help from the display guys, but globally disabling
silent stream for PTL is most likely not the right track.

>>> Can this be somehow related to the DP-to-HDMI converter? Have you tested
>>> that with other machine?
>>> Or a combination of xe2+DP-to-HDMI?
> 
> I only have this one PTL machine, so no cross machine data from me.
> But the converter question was the right direction, with one important refinement.
> The DP path is required to trigger the wedge, while the stuck state itself sits on the host side.
> 
> The wedge reproduces on all three DP-alt to HDMI converters I have.
> A Club3D CAC-2505 with Synaptics VMM7100 firmware 7.1, a Cable Matters adapter on the VMM7100 7.2 firmware line and a Thunderbolt 4 dock with an integrated Synaptics converter.
> 
> Once wedged, the state survives a converter replug, a move to the other USB-C port and a full TV power cycle (forced reboot of the TV over the network while everything stayed connected).
> Only a host suspend cycle or reboot clears it.
> While wedged on the converter path, moving the TV cable to the native HDMI port plays immediately.
> Moving it back to the converter wedges again.
> So nothing downstream of the host holds the state.
> It lives in the display side of the PTL audio path and only shows on DP.
> 
> Some register level observations from the wedged state, maybe they help locating it internally.
> During the wedged silent playback the sample counters in the display audio register block at 0x65e04 and 0x650d0 keep advancing at the expected rate for the stream format.
> So the samples still arrive at the display side and the stream dies further down, behind the audio converter.
> There is also a register at 0x65f20 in that block which the driver does not define anywhere, directly behind AUD_CHICKENBIT_REG3 at 0x65f1c.
> With a 2 channel stream running its low bits read 0x482 in the healthy state and 0x4a1 in the wedged state.
> The same readback shows 0x4a1 as the normal value while a 6 channel stream plays, so it has to be sampled with a stereo stream.
> That readback follows the wedge through everything that does not power cycle the display.
> And 0x65e04 only counts at all while KAE is enabled, with this patch applied it stays at zero, so it seems to belong to the keep-alive machinery itself.
> 
> There are also visible display side effects while KAE is in use, maybe interesting for Uma.
> Starting a 6 channel stream through the converter makes the TV drop from HDR to SDR.
> Starting an 8 channel stream blanks the picture for a moment and HDR survives.
> Stereo does neither.
> Both effects are gone with the patch applied.
> So the KAE to stream transition seems to disturb more of the SDP transmission on the DP path than just the audio samples.
> 
> Two caveats I want to be transparent about.
> All my DP sinks are Synaptics protocol converters and I have no plain DP monitor here.
> So I cannot tell whether plain DP audio is affected or only the DP plus PCON combination.
> That should be quick to check on your side.
> And the native HDMI immunity is based on this one machine and one TV.
> 
> For completeness, the sink does not explain the split.
> The TV advertises 2 channel LPCM only, on the converter path and on native HDMI alike, and native HDMI still plays every format.
> 
> One unrelated observation from the native HDMI tests, in case someone trips over it while reproducing.
> This TV takes anywhere between a second and a few minutes to lock onto a new channel layout on native HDMI.
> The delay is the same with KAE enabled and with this patch applied, so KAE plays no role in it.
> During that time the host output is provably healthy, the PCM keeps running and the audio infoframe is correct for the new layout.
> Stopping the player for a few seconds and starting it again makes the TV lock immediately.
> That is a sink quirk.
> 
> On the patch form.
> I am aware the model change gives up the KAE power benefit for the whole platform, like the DG2 change did, and PTL is mostly a mobile platform.
> If you prefer a narrower fix I can gate the silent stream type on the ELD connection type instead, so native HDMI pins keep KAE and only DP pins fall back to the older method.
> Given that the HDMI immunity rests on a single machine I did not want to make that call unilaterally.
> 
> If you want to reproduce, a VMM7100 based USB-C to HDMI adapter plus one multichannel PCM stream should show it within a minute.
> 
> Should the Battlemage boards drive their HDMI ports through an onboard protocol converter like the DG2 boards did, the TrueHD report in issue 7515 would fit this same pattern.
> 
> Regards,
> Alexander
> 

-- 
Péter

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Alexander Kaplan]

On 12/06/2026 15:45, Péter Ujfalusi wrote:
> I did not had too much time to test this, but I did found an old Dell
> TB16 Dock stashed away.
> With that I can reproduce the same issue on my PTL laptop. Out of
> curiosity I gave this a try on an LNL laptop and the same thing happens.

Hi Péter,

thanks for digging out the dock.
The LNL result is the important one.
It shows this is not Panther Lake specific and points at the KAE plus DP combination as the trigger.
It might also explain the Battlemage TrueHD report.

> Note: via TB16 dock I can _never_ hear 6ch audio, it is always silent,
> only stereo goes through:

That is probably just the sink.
As long as KAE was never active in the display power cycle, my TV plays multichannel LPCM audibly on the front pair, even though its ELD advertises 2 channel LPCM only.
The bug signal is the switch to multichannel itself.
The first 6 or 8 channel stream after KAE activity plays silent, wedges the pin and everything after it stays silent.

> I'm not sure where the bug is and I'm not sure how a fix would look
> like, this needs help from the display guys, but globally disabling
> silent stream for PTL is most likely not the right track.

One small clarification on what the patch does.
It does not disable silent stream globally.
It falls back from SILENT_STREAM_KAE to SILENT_STREAM_I915, so the silent stream keeps running through the regular stream path, exactly like the DG2 change did.
What is lost is the KAE power benefit, not the feature.

That said, after your LNL result I agree a PTL only model change is the wrong shape.
I can gate the silent stream type per pin on the ELD connection type instead.
DP pins fall back to the SILENT_STREAM_I915 path and native HDMI pins keep KAE, on all KAE platforms.
That matches the failure boundary on both of our machines and keeps the power benefit where it works.
If that shape works for you I will send it as v2.

Of course a real fix from someone who can look behind these registers would be better than any variant of my patch.
I have no access to that side, so working around KAE from the codec driver is the only lever I have.

If Uma or the display folks want data from the wedged state, the reproducer here is deterministic and takes under a minute.

Regards,
Alexander

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Kai Vehmanen]

Hi Alexander,

On Fri, 12 Jun 2026, Alexander Kaplan wrote:

> That is probably just the sink.
> As long as KAE was never active in the display power cycle, my TV plays multichannel LPCM audibly on the front pair, even though its ELD advertises 2 channel LPCM only.
> The bug signal is the switch to multichannel itself.
> The first 6 or 8 channel stream after KAE activity plays silent, wedges the pin and everything after it stays silent.
[...]
> That said, after your LNL result I agree a PTL only model change is the wrong shape.
> I can gate the silent stream type per pin on the ELD connection type instead.
> DP pins fall back to the SILENT_STREAM_I915 path and native HDMI pins keep KAE, on all KAE platforms.
> That matches the failure boundary on both of our machines and keeps the power benefit where it works.
> If that shape works for you I will send it as v2.

gating on DP pin type is less than ideal as this would impact USB-C dock
usage, which is probably the most common scenario where the display audio 
keepalive helps (to ensure desktop/UI sounds are played out from the start 
and not eaten up by the HDMI/DP receiver taking their time waking up).

I'm asking around internally for more test results based on your findings, 
but one quick test to make if you have time:
--cut--
--- a/sound/hda/codecs/hdmi/intelhdmi.c
+++ b/sound/hda/codecs/hdmi/intelhdmi.c
@@ -445,6 +445,12 @@ static int i915_hsw_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid,
                                        stream_tag, format);

        if (spec->silent_stream_type == SILENT_STREAM_KAE && per_pin && per_pin->silent_stream) {
+               /* do not reenable KAE if multichannel streaming started */
+               if ((format & AC_FMT_TYPE_NON_PCM) || (format & AC_FMT_CHAN_MASK) > 1) {
+                       codec_dbg(codec, "HDMI: multichannel stream, disable KAE\n");
+                       return res;
+               }
+
--cut--

The driver has disabled KAE just before this, so this is worth a shot. 
If pin is still wedged, then the problem occurs already earlier in the 
sequence.

Br, Kai

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Alexander Kaplan]

Hi Kai,

thanks for the quick test patch.

I ran it on Panther Lake with PTL kept at MODEL_ADLP so the KAE path is
active.
The codec debug log confirms your hunk is in and fires only on the
multichannel stream.
Full sequence, one speaker-test run per format, codec dynamic debug on:

  # speaker-test -D hw:0,3 -c2   (plays, front pair audible)
  HDMI: KAE 0 cvt-NID=0x3
  hdmi_pin_hbr_setup: NID=0xa, pinctl=0x40
  HDMI: KAE 1 cvt-NID=0x3

  # speaker-test -D hw:0,3 -c6   (silent)
  hdmi_pin_setup_infoframe: pin NID=0xa channels=6 ca=0x0b
  HDMI: KAE 0 cvt-NID=0x3
  hdmi_pin_hbr_setup: NID=0xa, pinctl=0x40
  i915_hsw_setup_stream: HDMI: multichannel stream, disable KAE

  # speaker-test -D hw:0,3 -c2   (stays silent)
  hdmi_pin_setup_infoframe: pin NID=0xa channels=2 ca=0x00
  HDMI: KAE 0 cvt-NID=0x3
  hdmi_pin_hbr_setup: NID=0xa, pinctl=0x40
  HDMI: KAE 1 cvt-NID=0x3

On the 6 channel stream KAE is disabled and not re-armed, exactly as
your patch intends.
On the following 2 channel stream the driver re-arms KAE as usual.
The kernel side state machine looks correct throughout, yet the audio is
dead from the 6 channel stream onward.

The sink is my LG TV with LPCM limited to 2 channels, on a fresh boot.
The first 2 channel stream after the 6 channel run is silent and every
following stream stays silent until a display power cycle.

This matches an earlier experiment where I cleared the KAE bit before the
multichannel stream and skipped the re-arm by hand, with the same result.
Fully quiescing the converter before the stream (KAE bit, stream id and
format cleared, then a wait) did not help either.

So the wedge happens earlier in the sequence, as you suspected, not at
the re-arm.
The trigger looks like the multichannel DMA start itself once the KAE
block has been active in the running power cycle, below the codec verb
level.

That is the same failure class as commit 6ab6f98fcdc9 on DG2, which is
why the patch falls back to the i915 silent stream method for the whole
platform instead of gating per pin.
I agree the DP pin gating shape was wrong for the dock case.

Happy to run more tests if your internal results point at a narrower
condition.

Br,
Alexander

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Kai Vehmanen]

Hello Alexander,

On Sat, 20 Jun 2026, Alexander Kaplan wrote:

> thanks for the quick test patch.
> 
> I ran it on Panther Lake with PTL kept at MODEL_ADLP so the KAE path is
> active.
[...]
>   # speaker-test -D hw:0,3 -c6   (silent)
>   hdmi_pin_setup_infoframe: pin NID=0xa channels=6 ca=0x0b
>   HDMI: KAE 0 cvt-NID=0x3
>   hdmi_pin_hbr_setup: NID=0xa, pinctl=0x40
>   i915_hsw_setup_stream: HDMI: multichannel stream, disable KAE
> 
>   # speaker-test -D hw:0,3 -c2   (stays silent)
>   hdmi_pin_setup_infoframe: pin NID=0xa channels=2 ca=0x00
>   HDMI: KAE 0 cvt-NID=0x3
>   hdmi_pin_hbr_setup: NID=0xa, pinctl=0x40
>   HDMI: KAE 1 cvt-NID=0x3
[...]
> So the wedge happens earlier in the sequence, as you suspected, not at
> the re-arm.
> The trigger looks like the multichannel DMA start itself once the KAE
> block has been active in the running power cycle, below the codec verb
> level.

thanks for the quick test. I'm working with our display folks to test
this out with some Synaptic DP-alt HDMI converter. This same test
worked ok with one converter (Lenovo USB-C to HDMI Adapter GX90K37871),
but I'll try to get someone to test with more converters. Given you see
this with multiple DP-HDMI converters, we should be able to hit this.

And a bit suspicious how this could work with the Lenovo adapter. I wonder 
if we have something else differing in the test setup. Given you cannot 
recover by unplugging and reconnecting the converter, it would seem the 
issue is on transmitter side and should be visible with all DP-alt 
receivers.

I filed a bug to Xe/display to track this effort:
https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412

Br, Kai

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Kai Vehmanen]

Hi,

On Wed, 24 Jun 2026, Kai Vehmanen wrote:

> On Sat, 20 Jun 2026, Alexander Kaplan wrote:
> 
[...]
> > So the wedge happens earlier in the sequence, as you suspected, not at
> > the re-arm.
> > The trigger looks like the multichannel DMA start itself once the KAE
> > block has been active in the running power cycle, below the codec verb
> > level.
> 
> thanks for the quick test. I'm working with our display folks to test
> this out with some Synaptic DP-alt HDMI converter. This same test
> worked ok with one converter (Lenovo USB-C to HDMI Adapter GX90K37871),
[...]
> I filed a bug to Xe/display to track this effort:
> https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412

some progress with this. I attached a work-in-progress patch that fixes 
the issue with at least one setup using Club3D CAC-2505 DP-alt HDMI 
converter to the bug at:
https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412#note_3543741

Needs more work still, but if this approach works, I'll send a proper 
patch later to the list.

Br, Kai

Re: [PATCH] ALSA: hda/hdmi: disable KAE for Intel Panther Lake

[Alexander Kaplan]

On 01/07/2026 01:45, Kai Vehmanen wrote:
> some progress with this. I attached a work-in-progress patch that fixes
> the issue with at least one setup using Club3D CAC-2505 DP-alt HDMI
> converter to the bug at:
> https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412#note_3543741
>
> Needs more work still, but if this approach works, I'll send a proper
> patch later to the list.

Hi Kai,

sorry for the late reply, a busy stretch at work kept me away from
this.

I tested the second, more generic patch from the work item (disable
keep-alive before audio format change) on the Panther Lake NUC.
Base was 7.1.2 with my KAE disable patch removed, so the KAE path is
active again (PTL on MODEL_ADLP), and your patch on top.

Results with two Synaptics VMM7100 based converters:

- Club3D CAC-2505 (SYNAq 7.1 firmware)
- Cable Matters USB-C to HDMI (7.02.123 firmware)

Test sequence on each, from a fresh boot:

- 2ch baseline, 6ch speaker-test, back to 2ch
- 5 rapid 6ch/2ch cycles
- PipeWire card profile switching between stereo, 5.1 and 7.1

Audio stayed audible through every step on both converters.
The register fingerprint I used during the original debugging
(AUD_DP_2DOT0_CTRL low bits sticking at 0x4a1 after the first
multichannel stream) now stays at the healthy 0x482 value
throughout.

So the reordering fixes the issue on my setups as well, and with that
my KAE disable patch can be dropped in favor of your fix.
Feel free to add, once you post the proper patch:

Tested-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>

One note, unrelated to your patch: the roughly 200 ms display
blanking on an audio channel count down transition (6ch to 2ch) is
still there.
That one sits downstream of the host (converter firmware or TV
resync) and behaves the same before and after the patch.

Thanks,
Alex