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?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
