> This means we get back to the assumption we started off with - what are > we gaining by partitioning things into cards when that's not really > what's going on with the hardware? The main benefit is reuse of 'generic' cards. Take for example HDMI support, it's typically exactly the same from one board to the other - it's completely standard. And yet, for every card, we have to add a path in the topology and the machine driver to represent exactly the same information multiple times. see below how many times we add the same 'late_probe' callback for HDMI support in machine drivers. BT audio is a similar case, the interface configuration and settings are defined by profiles, so there's almost no variation from one board to the other except for which I2S number is used. A peripheral directly attached to an SOC or chipset, such as digital microphones, is a similar case. The point is really to try to split what will be variable from board to board due to different choices of headset codecs, amplifiers, microphones, from what is generic and reusable. The logic can be pushed further, as done in the AVS patch series, to split the card by codec type. This would avoid having to deal with the permutations that we have to handle in machine drivers. See e.g. how complicated the initially generic sof-rt5682 machine driver has become, it now supports rt5682s, rt1011, rt1015, rt1015p, max98373 and max98360a. I will accept this comes from ACPI limitations, but if we could split cards it would also reduce the machine driver complexity. In terms of functionality, I don't think there will be any performance or power improvement coming from a multi-card solution, it's mostly a maintenance simplification: less duplicated code, more reuse. One key point is "who defines the split". That's really one of the main problems and different people could have different opinions - Cezary and I have a shared goal of enabling multiple cards but different takes on what the 'optimal' split might be. My take is that the integrator for a given hardware is responsible for making the decision - not the provider of a DSP driver. In case you have coupling between interfaces, playback or capture, it can become really difficult to define a split that will work for all cases, or conversely if you don't have 'self-contained' cards that can be tested independently then splitting the functionality was probably a really bad idea. If one needs to add dependencies and quirks for a local device, the notion of split cards is probably not so good either. In other words, I think we need to agree on the means to create and expose multiple cards, and agree not to debate on what the functionality of individual cards might be. Hope this helps clarify the ask? -Pierre sound/soc/intel/boards$ git grep '\.late_probe' bxt_da7219_max98357a.c: .late_probe = bxt_card_late_probe, bxt_rt298.c: .late_probe = bxt_card_late_probe, bxt_rt298.c: .late_probe = bxt_card_late_probe, cml_rt1011_rt5682.c: .late_probe = sof_card_late_probe, ehl_rt5660.c: .late_probe = card_late_probe, glk_rt5682_max98357a.c: .late_probe = glk_card_late_probe, kbl_da7219_max98357a.c: .late_probe = kabylake_card_late_probe, kbl_da7219_max98927.c: .late_probe = kabylake_card_late_probe, kbl_da7219_max98927.c: .late_probe = kabylake_card_late_probe, kbl_da7219_max98927.c: .late_probe = kabylake_card_late_probe, kbl_da7219_max98927.c: .late_probe = kabylake_card_late_probe, kbl_rt5660.c: .late_probe = kabylake_card_late_probe, kbl_rt5663_max98927.c: .late_probe = kabylake_card_late_probe, kbl_rt5663_max98927.c: .late_probe = kabylake_card_late_probe, kbl_rt5663_rt5514_max98927.c: .late_probe = kabylake_card_late_probe, skl_hda_dsp_generic.c: .late_probe = skl_hda_card_late_probe, skl_nau88l25_max98357a.c: .late_probe = skylake_card_late_probe, skl_nau88l25_ssm4567.c: .late_probe = skylake_card_late_probe, skl_rt286.c: .late_probe = skylake_card_late_probe, sof_cs42l42.c: .late_probe = sof_card_late_probe, sof_da7219_max98373.c: .late_probe = card_late_probe, sof_da7219_max98373.c: .late_probe = card_late_probe, sof_es8336.c: .late_probe = sof_es8336_late_probe, sof_nau8825.c: .late_probe = sof_card_late_probe, sof_pcm512x.c: .late_probe = sof_card_late_probe, sof_rt5682.c: .late_probe = sof_card_late_probe, sof_sdw.c: if (!codec_info_list[i].late_probe) sof_sdw.c: .late_probe = sof_sdw_card_late_probe, sof_ssp_amp.c: .late_probe = sof_card_late_probe,
