Hi Mark,
Here is the info from our audio platform enabling team that answers why we need this feature. Please review.
Intel platform supports too many different types of DAIs based on the platform variant e.g. I2S, HDA, DMIC and in future there are few more like soundwire in the pipelines.
Using this framework our attempt is to create DAI based on what is supported on the platform. If the platform does not support HDA then we would like not to create the HDA DAIs. e.g. SKL Chrome topology does not use HDA Codec and so there is only I2S and DMIC DAIs.
Based on the SoC pin count limitation not all the interface pins are taken out of the SoC to connect various peripherals. So even though technically hardware supports many physical interfaces but the platform may have limited what can be connected on the platform.
Surely we can create worst case number of DAIs but that would be too much.
Here is the example of SKL/BXT: 6 SSP Ports Rx and Tx, 2 DMIC Ports, 7 Playback DMA channels, 6 Capture DMA channels.We are creating topology diagram in text to explain different configuration for different use case,like Android, Linux, Chrome and Automotive.
Thanks Mengdong
On 08/28/2016 10:12 PM, Mark Brown wrote:
On Thu, Aug 25, 2016 at 02:40:34PM +0800, Mengdong Lin wrote:
In previous design, we had thought that BE DAI and BE DAI links should be created based on ACPI info in BIOS. But unfortunately, the BIOS doesn't have enough physical information, so BE DAI & DAI links are hard coded in platform and machine driver. But when new platforms are coming out with different physical connections, this BIOS gap blocks us from sharing a generic driver across platforms. Now the gap in BIOS ACPI info still exists, the implementations also vary for different generations of platforms, BIOS for public shipped machines cannot change ... So finally we fall back to topology to overcome the BIOS gap and make driver sharing possible. We have tried creating BE DAI & DAI links to new platforms and plan to back port this to upstream drivers for existing platforms like SKL.
I don't understand why we're not able to just enumerate all the possible back ends in the driver and then select the required one at runtime
- even if we do this there's going to be some fairly strict limits on
the set of back ends that can be added. Do we have any concrete examples here?