[Sound-open-firmware] Machine drivers for SOF/non-SOF Intel configurations
Hello,
As far as I understand Intel uses the same machine drivers for SOF/non-SOF configurations.
I don't exactly understand how this works.
1) Can SOF/non-SOF sound cards co-exist? 2) In SOF the DAI is managed by the FW, how one prevents Linux DAI driver to be loaded in SOF. 3) Is there any SOF related information in ACPI 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.
thanks, Daniel.
On Mon, 2019-08-26 at 15:44 +0300, Daniel Baluta wrote:
Hello,
As far as I understand Intel uses the same machine drivers for SOF/non-SOF configurations.
Yes, that's right. The intention here is reuse all existing machine drivers so that we don't have to reimplement any code.
I don't exactly understand how this works.
- Can SOF/non-SOF sound cards co-exist?
Yes. Intel has older legacy FW that can co-exist, this can based on PCI/ACPI ID, machine name, etc. The ACPI/PCI will logic will load the relevant FW depending on machine supported status.
- In SOF the DAI is managed by the FW, how one prevents Linux DAI
driver to be loaded in SOF.
BE DAI's are still registered by the machine driver, the SOF core driver just deletes and overwrites any machine driver FE DAI with the topology FE DAIs.
- Is there any SOF related information in ACPI tables.
The Intel SOF ACPI logic only reads BARs and IRQs form ACPI, however the legacy SKL driver would read I2S configuration (now read from topology).
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.
Liam
thanks, Daniel. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
- Is there any SOF related information in ACPI tables.
The Intel SOF ACPI logic only reads BARs and IRQs form ACPI, however the legacy SKL driver would read I2S configuration (now read from topology).
It's a case where for SOF we decided not to use information present in NHLT ACPI tables. That's different from what Daniel was asking: we don't have a case where we have SOF-specific information in ACPI tables.
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.
- 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
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
participants (4)
-
Curtis Malainey -
Daniel Baluta -
Liam Girdwood -
Pierre-Louis Bossart