Hi Jean Thank you for your kindly explanation. > When the cards are defined from a graph of ports, the CPU/CODEC drivers > do not need to know about this graph if they use a fixed numbering of > their DAIs (I think this is the case of all existing drivers but the > ones in my system). There is no useful information for these drivers > in the DT, so, they don't need any change when moving to a graph of > ports. > > Such a move is done first in the DT by removing the simple-card node > and replacing the previous 'dai-link' definitions by couples of ports > in the CPU (audio controller) and in the CODEC device nodes. > > The previous DAI properties (tdm-slots, clocks...) must also be moved > to the graph (ports of the graph links). As nothing exists about these > port properties in the DT documentation, they must be added. > > The previous global (simple-)card properties (widgets, routing..) must > also be moved. Where? Simply to the main audio controller node. > They could be named 'audio-xxx' or included in an audio container. > > Now, let's talk about the code. As there is no simple-card device to > create the card, an other piece of code must do the job. > The simplest way to run it is to put it in the audio controller: > when the audio controller scans the DT, it sees the card definitions > (audio-xxx' or audio container), so, it has all elements to create the > card. > This card is as generic as the simple-card, so it could be in the > sound/soc core. > > So, in brief again: when using a full graph style card: > - there is no change in the CPU/CODEC drivers, > - there is no simple-card, > - the 'audio-graph-card's are created by the audio controllers which > run a generic code. I could understand your idea, and had read previous some discussions. I would like to have it on upstream too. Can you show me about your plan for next step ?
