Re: [PATCH 02/14] ASoC: codecs: Add HD-Audio codec driver

[Cezary Rojewski <cezary.rojewski@intel.com>]

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