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 ?