On 08/24/2016 01:33 AM, Mark Brown wrote:
On Fri, Aug 19, 2016 at 06:12:35PM +0800, mengdong.lin@xxxxxxxxxxxxxxx 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
