On Mon, Aug 26, 2019 at 11:56 AM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
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.
- 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.
We have SST and SOF coexisting, but the only reason it works is because they target separate platforms (bdw vs glk) which flows back to the above problem Pierre outlined.
- 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.
- 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 _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware