On Mon, 26 Jan 2015 12:53:53 +0100
Lars-Peter Clausen <lars@xxxxxxxxxx> 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.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
