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

[Pierre-Louis Bossart]

On 5/9/22 09:33, Kai Vehmanen wrote:
> Hi,
> 
> On Fri, 6 May 2022, Pierre-Louis Bossart wrote:
> 
>>>> On 5/6/22 10:28, Cezary Rojewski wrote:
>>>>> My suggestion is different: have all HD-Audio ASoC users switch to this
>>>>> implementation when possible and remove the existing code along with
>>>>> skylake-driver.
> [...]
>> I am however concerned about the lack of long-term plans and confusion
>> coming having 3 different ways of dealing with HDaudio codecs on the
>> same hardware platform (legacy, ASoC/SOF-Skylake, ASoC-AVS). 2 was
>> already bad, I don't see how 3 is better?
> 
> fortunately most of the actual logic is in the codec drivers (in 
> sound/pci/hda/), so redundancy in the asoc-to-hda wrappers is not that 
> bad.
> 
> As a slight correction to the thread, hdac_hda.c does support HDMI and all 
> SOF machine drivers transitioned to this a few years back (and dropped 
> use of hdac_hdmi.c which is mostly duplicating code in patch_hdmi.c).
> 
> In last few years, most of the changes have been to the actual codec 
> drivers and we've not really had many fixes to hdac_hda.c anymore (there 
> has been a few, and indeed PM related). So in this sense this has worked 
> well enough. Patches to fix bugs and add support for new hardware, have 
> benefitted all users (DSP and no-DSP) and changes have been only needed at 
> a single location. So this is all good.
> 
> 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.

> 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.