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
