[Sound-open-firmware] Machine drivers for SOF/non-SOF Intel configurations

[Pierre-Louis Bossart]

Hi Daniel,

> As far as I understand Intel uses the same machine drivers for SOF/non-SOF
> configurations.

Yes, but with restrictions: the BE dailinks make references to CPU DAIs 
whose names are exactly the same for SOF/non-SOF configurations. So 
that's an implicit naming compatibility requirement, e.g. 'SSP0 Pin'

In addition when the machine drivers define hard-coded FE-related 
dailinks, we tag and ignore them so that topology-defined ones are used.

> I don't exactly understand how this works.
> 
> 1) Can SOF/non-SOF sound cards co-exist?

it cannot happen since the SOF/non-SOF drivers cannot be probed at the 
same time, e.g. for Baytrail when you probe for a given ACPI ID you will 
have a single SOF/non-SOF driver probed, and as a result a single 
machine driver probed once the platform_device is created.

So the problem is rather SOF/non-SOF driver coexistence, not a machine 
driver problem.

> 2) In SOF the DAI is managed by the FW, how one prevents Linux DAI
> driver to be loaded in SOF.

there are different concepts here.

the topology and machine driver share the dai_link ID.
the topology and firmware share the dai_index information.

The dai->id is not something that the topology and firmware know about.

The DAI will be created by the Linux driver based on topology 
information (and a lookup of supported DAIs), and then the firmware will 
be configured with the topology-provided information.

I don't get how you see a conflict between driver and firmware, the 
driver is a proxy dealing with topology information and the firmware 
only deals with configurations provided by the driver.

> 3) Is there any SOF related information in ACPI tables.

no. ACPI tables are typically OS-independent, they only describe the DSP 
ID or codec ID.

Even when we use the initrd overlay method to add ACPI tables that 
aren't in the initial BIOS, there is nothing SOF-specific in those tables.

> 
> I am still trying to wrap my head around the idea implemented in sof-acpi-dev.c
> to make it work in the same way for sof-of-dev.c so sorry if the
> questions are not clear.

I think the key concept is that for ACPI we don't have a representation 
of the machine driver, which does exist for DeviceTree. This is not an 
ACPI limitation but rather the fact that Windows does not need anything 
in the firmware so we don't have anything to probe a machine driver. So 
we probe indirectly by looking for 'hints', e.g. a combination of other 
codec IDs and the CPU type, to manually probe the machine driver.

In the past for some Android-specific devices the machine driver was 
probed directly, but we've aligned with Windows usages. For prototyping 
we *could* go back in time and add a pretend device for machine drivers 
with the initrd overlays, that may be a way to test commonality with how 
DeviceTree works.

Hope this helps
Regards
-Pierre