On 2022-05-09 5:55 PM, Pierre-Louis Bossart wrote:> On 5/9/22 09:33, Kai Vehmanen wrote:
The fixed DAI capabilities of hdac_hda.c are indeed not ideal (although in practise hasn't really been an issue so far) and the approach in the new hda.c seems indeed more robust. We do have a lot of existing machine drivers (and shipping DSP topologies that we need to keep working), so transitioning e.g. SOF machine drivers is not going to be straightforward. For new mach drivers, this could be considered.
We've just simplified the HDAudio topologies to support the Analog playback and capture only, for both IPC3 and IPC4 cases, so there's really no plan to support such dynamic capabilities. I am not even aware of a single device available in our team where the digital inputs and outputs are exposed on a connector, so even if we wanted we couldn't test this dynamic part.
As I've explained in one of the previous posts, you can always use topology to limit the number of FE(s) available while still adhering to behavior found in sound/pci/hda. hda.c is a prime example of how ASoC HD-Audio can align with ALSA HD-Audio in 1:1 fashion. hdac_hda.c does not do that a) because of hardcodes b) following HDA_DEV_ASOC.
Having no behavioral differences is a major gain here, fix one place, enjoy both solutions. By 'one place' I mean sound/pci/hda of course as there should be no logic outside of that directory.
So while not ideal, maybe it makes sense to have two wrappers, hdac_hda.c for mach drivers with fixed DAI configuration, and the new hda.c that supports dynamic configuration (but requires mach drivers that match this). If the old SST driver is deprecated, we can then proceed to remove hdac_hdmi.c from the tree, so there's some savings.
Such removal isn't going to happen for at least 3+ years, the time it takes for the slowest distros and users to switch kernels.
that means we're going to have to maintain for the foreseeable future:
hdac_hdmi.c: used only by SST hdac_hda.c: used by both SST and SOF hda.c: used only by AVS.
I and the team maintained almost all the solutions found in sound/soc/intel for couple of years already, doing couple more with the old stuff is not a problem. Don't believe 'sit and do nothing' is the answer here, not sure if this is even an option - but I'm sure that the final effect is going to be worth the initial cost.
Regards, Czarek