On 08/24/2016 01:33 AM, Mark Brown wrote:
On Fri, Aug 19, 2016 at 06:12:35PM +0800, mengdong.lin@linux.intel.com wrote:
Topology will check with ASoC if a BE DAI already exists by checking its name. If the BE DAI doesn't exist, topology will create a new one and the dai_load ops will be called for device specific init.
This doesn't explain in what situation we'd want to dynamically create a back end, or why we're representing DPCM so directly in the topology - we really need more words about what the use case is and why this makes sense. The expectation would be that back ends refer to physical objects that exist in the system so it's not clear why we'd be loading them from topologies (and that even where this makes sense there wouldn't be any misuse by other users). This is a bit of a theme here, the series is adding a bunch of stuff but not explaining why.
Thanks for the review! Sorry for not giving enough background info.
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'll add this to the commit messages of next version.
Thanks Mengdong