On Mon, 26 Jan 2015 12:53:53 +0100 Lars-Peter Clausen lars@metafoo.de wrote:
a generic sound node in the case of multi controllers or multi codec levels (after dt-card extension):
sound { compatible = "linux,dt-card"; audio-root = <&audio1>; /* starting point of the graph */ ... card properties ... };
For the last case, the creation of the simple dt-card builder could be done by a node in the controller, avoiding the DT to have a knowledge of this piece of software:
&audio1 { ... audio-card { ... card properties ... } port@0 { ... }; ... };
Is there any advantage to putting the card node inside the controller node rather than having it as a separate node?
There is no advantage, but it seems to me that the sound device is a software entity which should not appear in the devicetree.
I think this is something that needs to be done in the ASoC/ALSA core itself. Create the graph, wait until all endpoints of the graph have been registered and then create the card. Or something similar.
To go further, such a function could fully replace snd_soc_register_card()!
Yes, if the graph is strongly connected (which it should be) the framework will be able to identify when all components that belong to the graph have been registered and is then able to create a card for it.
Russell's "Componentized device handling" would permit to synchronize all components avoiding the PROBE_DEFERs, but there is a problem with the tda998x: this one is a component of both the audio and video subsystems, and the bind() callback does not indicate by which master compoment it is called...
Are you by chance at FOSDEM? If you are maybe we can sit down for a moment and discuss things.
Sorry, I will not be at FOSDEM.