Update some topology matching for newer laptops
Subsystems (4)
cover Update some topology matching for newer laptops
Now function topologies are being used more routinely we are hitting a couple of issues on some new laptops. Firstly, several laptops ship with devices in the ACPI which don't physically exist in the laptop, this confuses the function topology code as it tries to add those into the card. Add some quirks to ignore these. Secondly, remove some unnecessary matches and quirk the ones that remain so they only match the laptops that require them.
Thanks,
Charles
Charles Keepax (3):
ASoC: soc-acpi-intel-ptl-match: Make Chrome matches conditional
ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43
match
soundwire: dmi-quirks: Disable ghost Realtek devices
drivers/soundwire/dmi-quirks.c | 35 ++++++ .../intel/common/soc-acpi-intel-ptl-match.c | 119 +----------------- .../intel/common/soc-acpi-intel-sdca-quirks.c | 16 +++ .../intel/common/soc-acpi-intel-sdca-quirks.h | 1 + 4 files changed, 53 insertions(+), 118 deletions(-)
Signature · 1 line
2.47.3
PATCH 1/3 ASoC: soc-acpi-intel-ptl-match: Make Chrome matches conditional
For PTL onwards Cirrus are intending to rely on function topologies, rather than using a match table for each system type. Chrome systems tend to have custom magic in the topology and thus need to load a specific file. This causes problems as these system can have the same layout as generic laptops causing the match to apply to other laptops. Add a DMI quirk that forces these matches to only apply to specific devices.
--- .../soc/intel/common/soc-acpi-intel-ptl-match.c | 1 + .../intel/common/soc-acpi-intel-sdca-quirks.c | 16 ++++++++++++++++ .../intel/common/soc-acpi-intel-sdca-quirks.h | 1 + 3 files changed, 18 insertions(+)
sound/soc/intel/common/soc-acpi-intel-ptl-match.c +1 -0
@@ -632,6 +632,7 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_ptl_sdw_machines[] = { .link_mask = BIT(2) | BIT(3), .links = ptl_cs42l43_agg_l3_cs35l56_l2, .drv_name = "sof_sdw", + .machine_check = snd_soc_acpi_intel_no_function_topology, .sof_tplg_filename = "sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg", }, {
sound/soc/intel/common/soc-acpi-intel-sdca-quirks.c +16 -0
@@ -6,6 +6,7 @@* */ +#include <linux/dmi.h> #include <linux/soundwire/sdw_intel.h> #include <sound/sdca.h> #include <sound/soc-acpi.h>
@@ -37,6 +38,21 @@ bool snd_soc_acpi_intel_sdca_is_device_rt712_vb(void *arg) }EXPORT_SYMBOL_NS (snd_soc_acpi_intel_sdca_is_device_rt712_vb,"SND_SOC_ACPI_INTEL_SDCA_QUIRKS" ); +static const struct dmi_system_id function_topology_quirk_table[] = { + { + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Google" ), + }, + }, + {} +}; + +bool snd_soc_acpi_intel_no_function_topology (void *arg) +{ +return !!dmi_check_system (function_topology_quirk_table); +} +EXPORT_SYMBOL_NS (snd_soc_acpi_intel_no_function_topology,"SND_SOC_ACPI_INTEL_SDCA_QUIRKS" ); +MODULE_DESCRIPTION ("ASoC ACPI Intel SDCA quirks" );MODULE_LICENSE ("GPL" );MODULE_IMPORT_NS ("SND_SOC_SDCA" );
sound/soc/intel/common/soc-acpi-intel-sdca-quirks.h +1 -0
@@ -10,5 +10,6 @@#define _SND_SOC_ACPI_INTEL_SDCA_QUIRKSbool snd_soc_acpi_intel_sdca_is_device_rt712_vb (void *arg); +bool snd_soc_acpi_intel_no_function_topology (void *arg);#endif
Signature · 1 line
2.47.3
PATCH 2/3 ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43 match
In reply to Charles KeepaxFor PTL onwards Cirrus are intending to rely on function topologies, rather than using a match table for each system type. Remove this unnecessary match table entry. Having the match entries can mean that systems match when they should use function topologies instead, resulting in incorrect audio configurations. Although, admittedly this is not too likely with this 6x amp configuration as those are quite rare, but best to follow best practice.
--- .../intel/common/soc-acpi-intel-ptl-match.c | 118 ------------------ 1 file changed, 118 deletions(-)
sound/soc/intel/common/soc-acpi-intel-ptl-match.c +0 -118
@@ -92,48 +92,6 @@ static const struct snd_soc_acpi_endpoint spk_r_endpoint = { .group_id = 1, }; -static const struct snd_soc_acpi_endpoint spk_1_endpoint = { - .num =0 , - .aggregated =1 , - .group_position =1 , - .group_id =1 , -}; - -static const struct snd_soc_acpi_endpoint spk_2_endpoint = { - .num =0 , - .aggregated =1 , - .group_position =2 , - .group_id =1 , -}; - -static const struct snd_soc_acpi_endpoint spk_3_endpoint = { - .num =0 , - .aggregated =1 , - .group_position =3 , - .group_id =1 , -}; - -static const struct snd_soc_acpi_endpoint spk_4_endpoint = { - .num =0 , - .aggregated =1 , - .group_position =4 , - .group_id =1 , -}; - -static const struct snd_soc_acpi_endpoint spk_5_endpoint = { - .num =0 , - .aggregated =1 , - .group_position =5 , - .group_id =1 , -}; - -static const struct snd_soc_acpi_endpoint spk_6_endpoint = { - .num =0 , - .aggregated =1 , - .group_position =6 , - .group_id =1 , -}; -static const struct snd_soc_acpi_endpoint jack_dmic_endpoints[] = {/* Jack Endpoint */ {
@@ -202,15 +160,6 @@ static const struct snd_soc_acpi_endpoint cs42l43_amp_spkagg_endpoints[] = { }, }; -static const struct snd_soc_acpi_adr_device cs42l43_2_adr[] = { - { - .adr =0x00023001fa424301ull , - .num_endpoints =ARRAY_SIZE (cs42l43_amp_spkagg_endpoints), - .endpoints = cs42l43_amp_spkagg_endpoints, - .name_prefix ="cs42l43" - } -}; -static const struct snd_soc_acpi_adr_device cs42l43_3_agg_adr[] = { { .adr =0x00033001FA424301ull ,
@@ -235,48 +184,6 @@ static const struct snd_soc_acpi_adr_device cs35l56_2_lr_adr[] = { } }; -static const struct snd_soc_acpi_adr_device cs35l56_1_3amp_adr[] = { - { - .adr =0x00013001fa355601ull , - .num_endpoints =1 , - .endpoints = &spk_1_endpoint, - .name_prefix ="AMP1" - }, - { - .adr =0x00013101fa355601ull , - .num_endpoints =1 , - .endpoints = &spk_2_endpoint, - .name_prefix ="AMP2" - }, - { - .adr =0x00013201fa355601ull , - .num_endpoints =1 , - .endpoints = &spk_3_endpoint, - .name_prefix ="AMP3" - } -}; - -static const struct snd_soc_acpi_adr_device cs35l56_3_3amp_adr[] = { - { - .adr =0x00033301fa355601ull , - .num_endpoints =1 , - .endpoints = &spk_4_endpoint, - .name_prefix ="AMP4" - }, - { - .adr =0x00033401fa355601ull , - .num_endpoints =1 , - .endpoints = &spk_5_endpoint, - .name_prefix ="AMP5" - }, - { - .adr =0x00033501fa355601ull , - .num_endpoints =1 , - .endpoints = &spk_6_endpoint, - .name_prefix ="AMP6" - } -}; -static const struct snd_soc_acpi_adr_device rt711_sdca_0_adr[] = { { .adr =0x000030025D071101ull ,
@@ -408,25 +315,6 @@ static const struct snd_soc_acpi_link_adr ptl_cs42l43_agg_l3_cs35l56_l2[] = { {} }; -static const struct snd_soc_acpi_link_adr ptl_cs42l43_l2_cs35l56x6_l13[] = { - { - .mask =BIT (2 ), - .num_adr =ARRAY_SIZE (cs42l43_2_adr), - .adr_d = cs42l43_2_adr, - }, - { - .mask =BIT (1 ), - .num_adr =ARRAY_SIZE (cs35l56_1_3amp_adr), - .adr_d = cs35l56_1_3amp_adr, - }, - { - .mask =BIT (3 ), - .num_adr =ARRAY_SIZE (cs35l56_3_3amp_adr), - .adr_d = cs35l56_3_3amp_adr, - }, - {} -}; -static const struct snd_soc_acpi_link_adr ptl_rt722_l0_rt1320_l23[] = { { .mask =BIT (0 ),
@@ -599,12 +487,6 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_ptl_sdw_machines[] = { .sof_tplg_filename = "sof-ptl-rt713-l3-rt1320-l1.tplg", .get_function_tplg_files = sof_sdw_get_tplg_files, }, - { - .link_mask = BIT(1) | BIT(2) | BIT(3), - .links = ptl_cs42l43_l2_cs35l56x6_l13, - .drv_name = "sof_sdw", - .sof_tplg_filename = "sof-ptl-cs42l43-l2-cs35l56x6-l13.tplg", - }, { .link_mask = BIT(0) | BIT(2) | BIT(3), .links = ptl_rt722_l0_rt1320_l23,
Signature · 1 line
2.47.3
PATCH 3/3 soundwire: dmi-quirks: Disable ghost Realtek devices
In reply to Charles KeepaxMany systems ship with a Realtek audio codec in the ACPI that doesn't physically exist in the system. This confuses the newer function topology system that creates the soundcard, as it builds the card based on the ACPI information.
Whilst we are working with the laptop vendors to try and stop this happening there are quite a few systems where this has shipped. Add a quirk to disable this "ghost" device.
Currently this patch should cover:
- Asus UX5406AA
- Lenovo Yoga Pro 9i (83SF)
- Lenovo Yoga Slim 7 Ultra (83QK)
--- drivers/soundwire/dmi-quirks.c | 35 ++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
drivers/soundwire/dmi-quirks.c +35 -0
@@ -90,6 +90,19 @@ static const struct adr_remap intel_rooks_county[] = { {} }; +/* +* Many platforms have ghost realtek devices in the ACPI that don't physically +* exist, remove those devices. +*/ +static const struct adr_remap ghost_realtek[] = { +/* rt722 on link3 */ + { +0x000330025d072201ull , +0x0000000000000000ull + }, + {} +}; +static const struct dmi_system_id adr_remap_quirk_table[] = {/* TGL devices */ {
@@ -164,6 +177,28 @@ static const struct dmi_system_id adr_remap_quirk_table[] = { }, .driver_data = (void *)hp_omen_16, }, +/* PTL devices */ + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUS"), + DMI_MATCH(DMI_BOARD_NAME, "UX5406AA"), + }, + .driver_data = (void *)ghost_realtek, + }, + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "83QK"), + }, + .driver_data = (void *)ghost_realtek, + }, + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "83SF"), + }, + .driver_data = (void *)ghost_realtek, + }, {} };
Signature · 1 line
2.47.3
Pierre-Louis Bossart
reviewerRe: [PATCH 3/3] soundwire: dmi-quirks: Disable ghost Realtek devices
Quoted 5 lines · Charles Keepax
Many systems ship with a Realtek audio codec in the ACPI that doesn't physically exist in the system. This confuses the newer function topology system that creates the soundcard, as it builds the card based on the ACPI information.
Quoted 8 lines
Whilst we are working with the laptop vendors to try and stop this happening there are quite a few systems where this has shipped. Add a quirk to disable this "ghost" device.
Currently this patch should cover:
- Asus UX5406AA
- Lenovo Yoga Pro 9i (83SF)
- Lenovo Yoga Slim 7 Ultra (83QK)
if this broken ACPI stuff works for Windows then it'll be an uphill battle...
Could we filter instead those 'ghost' devices if they fail to appear in the new ACPI table that describes all the endpoints and card topology?
RE: [PATCH 3/3] soundwire: dmi-quirks: Disable ghost Realtek devices
Quoted 23 lines
-----Original Message-----
From: Pierre-Louis Bossart <[email protected]>
Sent: Thursday, May 21, 2026 1:17 AM
To: Charles Keepax <[email protected]>; [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 3/3] soundwire: dmi-quirks: Disable ghost Realtek devicesQuoted 9 lines · Charles Keepax
Many systems ship with a Realtek audio codec in the ACPI that doesn't physically exist in the system. This confuses the newer function topology system that creates the soundcard, as it builds the card based on the ACPI information.
Whilst we are working with the laptop vendors to try and stop this happening there are quite a few systems where this has shipped. Add a quirk to disable this "ghost" device.
Quoted 6 lines
Quoted 4 lines
Currently this patch should cover:
- Asus UX5406AA
- Lenovo Yoga Pro 9i (83SF)
- Lenovo Yoga Slim 7 Ultra (83QK)if this broken ACPI stuff works for Windows then it'll be an uphill battle...
We already informed the OEMs. Hope they can fix in the next generation products.
Quoted 3 lines
Could we filter instead those 'ghost' devices if they fail to appear in the new ACPI table that describes all the endpoints and card topology?
Sorry Pierre, I am not sure if I get your question correctly. The 'ghost' device has a complete DisCo properties description in the ACPI table. We could check if the device is ever attached. But we need to set a timeout time and wait until timeout to claim the device is not present. It seems not be realistic to wait say 3 seconds in each boot.
Re: [PATCH 3/3] soundwire: dmi-quirks: Disable ghost Realtek devices
In reply to Pierre-Louis BossartQuoted 4 lines · Pierre-Louis Bossart
On 5/20/26 18:36, Charles Keepax wrote:
Could we filter instead those 'ghost' devices if they fail to appear in the new ACPI table that describes all the endpoints and card topology?
Eventually perhaps once that makes it out of the standardisation process (I believe the committee is looking at it), but for now that is all Microsoft magic that I would rather avoid.
Thanks,
Charles
Re: [PATCH 3/3] soundwire: dmi-quirks: Disable ghost Realtek devices
Quoted 9 lines · Charles Keepax
Quoted 4 lines · Pierre-Louis Bossart
On 5/20/26 18:36, Charles Keepax wrote:
Could we filter instead those 'ghost' devices if they fail to appear in the new ACPI table that describes all the endpoints and card topology?Eventually perhaps once that makes it out of the standardisation process (I believe the committee is looking at it), but for now that is all Microsoft magic that I would rather avoid.
Nothing prevents developers from reverse-engineering DSDT contents. I remember seeing all the information needed in the DSDT of one of the Dell devices. The standardization was supposed to happen before Covid, I looked at this in 2020-2021. If it hasn't happened by now it's unlikely it ever will... This DSDT information is interesting for Intel platforms, it could help probe a generic machine driver for the card but raises other problems with deferred probe, c.f. https://lore.kernel.org/alsa-devel/[email protected]/
Anyways this patchset isn't wrong either, so
Re: [PATCH 3/3] soundwire: dmi-quirks: Disable ghost Realtek devices
Quoted 11 lines · Pierre-Louis Bossart
Quoted 9 lines · Charles Keepax
Quoted 4 lines · Pierre-Louis Bossart
On 5/20/26 18:36, Charles Keepax wrote:
Could we filter instead those 'ghost' devices if they fail to appear in the new ACPI table that describes all the endpoints and card topology?Eventually perhaps once that makes it out of the standardisation process (I believe the committee is looking at it), but for now that is all Microsoft magic that I would rather avoid.
Quoted 8 lines
Nothing prevents developers from reverse-engineering DSDT contents. I remember seeing all the information needed in the DSDT of one of the Dell devices. The standardization was supposed to happen before Covid, I looked at this in 2020-2021. If it hasn't happened by now it's unlikely it ever will... This DSDT information is interesting for Intel platforms, it could help probe a generic machine driver for the card but raises other problems with deferred probe, c.f. https://lore.kernel.org/alsa-devel/[email protected]/
Anyways this patchset isn't wrong either, so
Reviewed-by Pierre-Louis Bossart <[email protected]>
There is I guess an argument for starting to attempt to work through that stuff, although still very nervous about it being all Microsoft magic. But yeah we need to merge this guy anyway as doing that will be a very large task and we have a lot of shipping laptops that are failing now.
Thanks,
Charles
Mark Brown
maintainerRe: (subset) [PATCH 0/3] Update some topology matching for newer laptops
In reply to Charles KeepaxQuoted 11 lines · Charles Keepax
Update some topology matching for newer laptops
Now function topologies are being used more routinely we are hitting a couple of issues on some new laptops. Firstly, several laptops ship with devices in the ACPI which don't physically exist in the laptop, this confuses the function topology code as it tries to add those into the card. Add some quirks to ignore these. Secondly, remove some unnecessary matches and quirk the ones that remain so they only match the laptops that require them.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
Thanks!
[1/3] ASoC: soc-acpi-intel-ptl-match: Make Chrome matches conditional
https://git.kernel.org/broonie/sound/c/e0fb794d67f8 [2/3] ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43 match https://git.kernel.org/broonie/sound/c/45cf24da0a10
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks,
Mark
Re: (subset) [PATCH 0/3] Update some topology matching for newer laptops
In reply to Charles KeepaxQuoted 9 lines · Charles Keepax
Now function topologies are being used more routinely we are hitting a couple of issues on some new laptops. Firstly, several laptops ship with devices in the ACPI which don't physically exist in the laptop, this confuses the function topology code as it tries to add those into the card. Add some quirks to ignore these. Secondly, remove some unnecessary matches and quirk the ones that remain so they only match the laptops that require them.
[...]
Applied, thanks!
[3/3] soundwire: dmi-quirks: Disable ghost Realtek devices
commit: 4dab2b904414fac53535c4e4cdad808132f4cdc2
Best regards,
Signature · 1 line
~Vinod