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

[Curtis Malainey]

On Mon, Aug 26, 2019 at 11:56 AM Pierre-Louis Bossart
<pierre-louis.bossart at 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.
> >
> > 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.
>
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.
> > 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
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware