ASoC: add audio card creation from graph of ports in DT

[...]

sound/soc/generic/dt-card.c line 244

Quoted 4 lines

sound/soc/generic/dt-card.c new file +4 -0

+	card->dai_link->dai_fmt =
+		snd_soc_of_parse_daifmt(of_cpu, "dt-audio-card,",
+					NULL, NULL) &
+			~SND_SOC_DAIFMT_MASTER_MASK;

This one does not seem to be in the bindings documentation.

I was also wondering about some of these properties, as widgets and routing. They seem to be software information and Linux specific. Must these properties appear in the DTs?

Quoted 8 lines · On Wed, 21 Jan 2015 21:14:07 +0100 Lars-Peter Clausen <[email protected]> wrote:

[...]

sound/soc/generic/dt-card.c line 244

Quoted 4 lines

sound/soc/generic/dt-card.c new file +4 -0

+	card->dai_link->dai_fmt =
+		snd_soc_of_parse_daifmt(of_cpu, "dt-audio-card,",
+					NULL, NULL) &
+			~SND_SOC_DAIFMT_MASTER_MASK;

This one does not seem to be in the bindings documentation.

Sorry, I forgot to remove it from the patch.

BTW, the graph of port should also contain pieces of the audio specific hardware information as the ones found in the simple-card (clock, GPIO, ...). This information could be written as generic device node properties. i.e without any prefix.

I was also wondering about some of these properties, as widgets and routing. They seem to be software information and Linux specific. Must these properties appear in the DTs?

Quoted 12 lines · Jean-Francois Moine

Quoted 8 lines · On Wed, 21 Jan 2015 21:14:07 +0100 Lars-Peter Clausen…

[...]

sound/soc/generic/dt-card.c line 244

Quoted 4 lines

sound/soc/generic/dt-card.c new file +4 -0

+	card->dai_link->dai_fmt =
+		snd_soc_of_parse_daifmt(of_cpu, "dt-audio-card,",
+					NULL, NULL) &
+			~SND_SOC_DAIFMT_MASTER_MASK;

This one does not seem to be in the bindings documentation.

Quoted 1 line

Sorry, I forgot to remove it from the patch.

Ah, too bad this was the part I was most interested in. I think that using

the generic of graph framework as a unified way for expressing non-control links is a good idea, whether it be for audio, video or something else.

But I think there are some open questions that need to be address when coming up with a specification for audio so we do not have to write yet another incompatible DT spec in 3 months time.

One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is a bus and can have more than one reader/writer.

The second issue is how to describe the clock and frame master relationships. Multiple different buses can share the same clock and frame generator. E.g. typically the capture and playback stream are linked in this way.

How are we going to handle bus specific properties. Properties which are neither a property of either of the endpoints on the link, but of the link itself.

Quoted 8 lines

BTW, the graph of port should also contain pieces of the audio specific hardware information as the ones found in the simple-card (clock, GPIO, ...). This information could be written as generic device node properties. i.e without any prefix.

I was also wondering about some of these properties, as widgets and routing. They seem to be software information and Linux specific. Must these properties appear in the DTs?

Well last time I checked the speaker on my board was hardware not software and wasn't Linux specific either ;) Those widgets and routing represent the (typically analog) audio fabric on the board and are part of the hardware description. This is not even ASoC or devicetree specific, e.g. HDA uses a similar concept where the BIOS provides a description of which pins of the audio CODEC is connected to which speaker, microphone, etc. And especially on embedded boards the audio fabric can become quite complex.

Your example is a relative simple one where you do not have any additional audio fabric on the board itself.

The DT should describe the hardware, and the simple-card mixes hardware and software.
For example, the kirkwood controller may create 2 CPU DAIs. With the simple-card, the DT contains a number to reference these DAIs (for example, implicitly, <audio1 0> references the I2S output). So, what if the controller creates only one DAI, or, what if the FreeBSD/OpenBSD/.. driver does not set the same references to these DAIs?
The graph of port fixes this problem.

More: a simple audio card may easily be created from a graph of ports as the simple-card does, but by the audio-controller (sorry, I also forgot the kirkwood patch for this in my previous patch request). In case of complex cards, the links and properties of this graph may also be used by board specific card devices.

Quoted 3 lines

One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is a bus and can have more than one reader/writer.

Quoted 4 lines

The second issue is how to describe the clock and frame master relationships. Multiple different buses can share the same clock and frame generator. E.g. typically the capture and playback stream are linked in this way.

The ports and endpoints may contain properties to describe these configurations. Complex cases should be handled by specific card builders.

Quoted 4 lines

How are we going to handle bus specific properties. Properties which are neither a property of either of the endpoints on the link, but of the link itself.

This is already the case for the bus types of the kirkwood controller, I2S or S/PDIF. Such properties may appear in either local or remote port, or in both.

Quoted 9 lines

Quoted 8 lines

BTW, the graph of port should also contain pieces of the audio specific hardware information as the ones found in the simple-card (clock, GPIO, ...). This information could be written as generic device node properties. i.e without any prefix.

I was also wondering about some of these properties, as widgets and routing. They seem to be software information and Linux specific. Must these properties appear in the DTs?

Quoted 7 lines

Well last time I checked the speaker on my board was hardware not software and wasn't Linux specific either ;) Those widgets and routing represent the (typically analog) audio fabric on the board and are part of the hardware description. This is not even ASoC or devicetree specific, e.g. HDA uses a similar concept where the BIOS provides a description of which pins of the audio CODEC is connected to which speaker, microphone, etc. And especially on embedded boards the audio fabric can become quite complex.

OK. I looked if the widgets and routes could also be described in a graph, but, it complexifies the syntax. So, this information could have the same syntax as in the simple-card.

On the other hand, where would this information appear in the graph? As I understood, on card creation, the widgets and routes, which appear at the card level, redefine the CPU and CODEC DAI definitions.

With a DT graph, each CPU/CODEC would know exactly the widgets and routes it has to define.

Quoted 3 lines

Your example is a relative simple one where you do not have any additional audio fabric on the board itself.

Right, and that's why I'd be glad to have quickly something in the kernel. More properties could be added later as there would be requests.

Quoted 2 lines · Jean-Francois Moine

Quoted 2 lines

Your example is a relative simple one where you do not have any additional audio fabric on the board itself.

Quoted 2 lines

Right, and that's why I'd be glad to have quickly something in the kernel. More properties could be added later as there would be requests.

I'd agree if this was some kind of kernel internal stuff, but this is creating ABI and we have to maintain it forever. Rushing this in without proper discussion and consideration of the more complex use-cases is in my opinion not a good idea.

On 01/23/2015 01:15 PM, Jean-Francois Moine wrote:
[...]

Quoted 8 lines

The DT should describe the hardware, and the simple-card mixes hardware and software.
For example, the kirkwood controller may create 2 CPU DAIs. With the simple-card, the DT contains a number to reference these DAIs (for example, implicitly, <audio1 0> references the I2S output). So, what if the controller creates only one DAI, or, what if the FreeBSD/OpenBSD/.. driver does not set the same references to these DAIs?
The graph of port fixes this problem.

Even with the simple-card bindings there are no software specific bits. The DAI that is referenced in your example is the physical DAI as it exists in the hardware. Which DAI maps to which specifier is defined in the devicetree bindings definition for the hardware unit.

Quoted 14 lines

More: a simple audio card may easily be created from a graph of ports as the simple-card does, but by the audio-controller (sorry, I also forgot the kirkwood patch for this in my previous patch request). In case of complex cards, the links and properties of this graph may also be used by board specific card devices.

Quoted 7 lines

One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is a bus and can have more than one reader/writer.

The second issue is how to describe the clock and frame master relationships. Multiple different buses can share the same clock and frame generator. E.g. typically the capture and playback stream are linked in this way.

Quoted 3 lines

The ports and endpoints may contain properties to describe these configurations. Complex cases should be handled by specific card builders.

Could you describe in detail what a card builder is and how to decide when and how a card builder is executed?

Quoted 3 lines

On the other hand, where would this information appear in the graph? As I understood, on card creation, the widgets and routes, which appear at the card level, redefine the CPU and CODEC DAI definitions.

What do you mean by "redefine the CPU and CODEC DAI definitions".

Quoted 3 lines

With a DT graph, each CPU/CODEC would know exactly the widgets and routes it has to define.

Which widgets/routes do you mean?

Quoted 5 lines

Quoted 2 lines

Your example is a relative simple one where you do not have any additional audio fabric on the board itself.

Right, and that's why I'd be glad to have quickly something in the kernel. More properties could be added later as there would be requests.

I'd agree if this was some kind of kernel internal stuff, but this is creating ABI and we have to maintain it forever. Rushing this in without proper discussion and consideration of the more complex use-cases is in my opinion not a good idea.

A card builder is a device which
- scans the graph of ports,
- fills the struct snd_soc_card according to the links between the ports and their properties,
- and, eventually, calls snd_soc_register_card().

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

Quoted 4 lines

Quoted 2 lines

With a DT graph, each CPU/CODEC would know exactly the widgets and routes it has to define.

Which widgets/routes do you mean?

Well, forget about this. I never clearly understood why some widgets and routes had to be defined at card level.

Quoted 4 lines

I'd agree if this was some kind of kernel internal stuff, but this is creating ABI and we have to maintain it forever. Rushing this in without proper discussion and consideration of the more complex use-cases is in my opinion not a good idea.

Using a graph of port to describe the audio subsystem has been pushed forwards by many people for a long time, as shown by the creation of the document Documentation/devicetree/bindings/graph.txt.

Quoted 9 lines · Jean-Francois Moine

A card builder is a device which
- scans the graph of ports,
- fills the struct snd_soc_card according to the links between the ports and their properties,
- and, eventually, calls snd_soc_register_card().

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

Which audio controller? There may be several CPU side audio interfaces in the same card. For example people often want to have both low latency and high latency audio paths from the CPU into the hardware (low latency tends to increase power burn). SoC centric system designs do sometimes also have PDM I/O, expecting to be directly connected to DMICs and so on, which results in a relatively large number of CPU interfaces.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

With a DT graph, each CPU/CODEC would know exactly the widgets and routes it has to define.

Which widgets/routes do you mean?

Well, forget about this. I never clearly understood why some widgets and routes had to be defined at card level.

Please do try to understand the idea of representing simple components on the board and analogue interconects between devices - it's really important and not something that can be neglected.

Quoted 8 lines

Quoted 4 lines

I'd agree if this was some kind of kernel internal stuff, but this is creating ABI and we have to maintain it forever. Rushing this in without proper discussion and consideration of the more complex use-cases is in my opinion not a good idea.

Using a graph of port to describe the audio subsystem has been pushed forwards by many people for a long time, as shown by the creation of the document Documentation/devicetree/bindings/graph.txt.

That DT binding was done entirely in the context of video applications IIRC, this is the first time it's been discussed in this context.

Quoted 6 lines · Mark Brown

Quoted 3 lines · Jean-Francois Moine

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

Quoted 6 lines

Which audio controller? There may be several CPU side audio interfaces in the same card. For example people often want to have both low latency and high latency audio paths from the CPU into the hardware (low latency tends to increase power burn). SoC centric system designs do sometimes also have PDM I/O, expecting to be directly connected to DMICs and so on, which results in a relatively large number of CPU interfaces.

The audio controller which creates the card depends on the complexity of the card. When there are many controllers, it is up to the designer to define either a master audio controller or to instantiate a 'card' device via the DT for doing the job.

Quoted 6 lines

Quoted 2 lines

Well, forget about this. I never clearly understood why some widgets and routes had to be defined at card level.

Please do try to understand the idea of representing simple components on the board and analogue interconects between devices - it's really important and not something that can be neglected.

The problem is that this understanding would stay abstract: I have no such a hardware. Anyway, if the representation can be done with the simple-card, it may also be done with a graph of ports.

Quoted 2 lines

That DT binding was done entirely in the context of video applications IIRC, this is the first time it's been discussed in this context.

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html

Quoted 13 lines · Jean-Francois Moine

Quoted 12 lines · Mark Brown

Quoted 3 lines · Jean-Francois Moine

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

Which audio controller? There may be several CPU side audio interfaces in the same card. For example people often want to have both low latency and high latency audio paths from the CPU into the hardware (low latency tends to increase power burn). SoC centric system designs do sometimes also have PDM I/O, expecting to be directly connected to DMICs and so on, which results in a relatively large number of CPU interfaces.

Quoted 4 lines

The audio controller which creates the card depends on the complexity of the card. When there are many controllers, it is up to the designer to define either a master audio controller or to instantiate a 'card' device via the DT for doing the job.

So how does the simple controller interact with a more complex one given that it's somehow picking some controller node to start from?

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

Well, forget about this. I never clearly understood why some widgets and routes had to be defined at card level.

Please do try to understand the idea of representing simple components on the board and analogue interconects between devices - it's really important and not something that can be neglected.

Quoted 3 lines

The problem is that this understanding would stay abstract: I have no such a hardware. Anyway, if the representation can be done with the simple-card, it may also be done with a graph of ports.

If you have a device with any sort of speaker or microphone, or any sort of external connector for interfacing with an external device like a headphone jack, then you have something that could be a widget.

Quoted 5 lines

Quoted 2 lines

That DT binding was done entirely in the context of video applications IIRC, this is the first time it's been discussed in this context.

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html

So there's been some in passing mentions, not really serious discussion though...

Quoted 2 lines · Mark Brown

So how does the simple controller interact with a more complex one given that it's somehow picking some controller node to start from?

A way to solve this problem could be to create only one card builder. This creation could be explicit (created by the first active audio controller) or implicit by the audio subsystem on the first controller or CODEC creation.

Then, the card builder could scan all the DT looking for the audio ports and create one or more cards according to the graph connectivity.

Quoted 3 lines

If you have a device with any sort of speaker or microphone, or any sort of external connector for interfacing with an external device like a headphone jack, then you have something that could be a widget.

I know what are the widgets and routes, I was just wondering why they (especially the widgets) need to appear at the card level instead of just being declared in the DAIs (from the platform or the DT).

And the same question may also be raised about the audio formats, clocks, tdm's...

Quoted 11 lines · On Fri, 23 Jan 2015 14:56:04 +0100 Lars-Peter Clausen…

On 01/23/2015 01:15 PM, Jean-Francois Moine wrote:
[...]

Quoted 8 lines

The DT should describe the hardware, and the simple-card mixes hardware and software.
For example, the kirkwood controller may create 2 CPU DAIs. With the simple-card, the DT contains a number to reference these DAIs (for example, implicitly, <audio1 0> references the I2S output). So, what if the controller creates only one DAI, or, what if the FreeBSD/OpenBSD/.. driver does not set the same references to these DAIs?
The graph of port fixes this problem.

Quoted 4 lines

Even with the simple-card bindings there are no software specific bits. The DAI that is referenced in your example is the physical DAI as it exists in the hardware. Which DAI maps to which specifier is defined in the devicetree bindings definition for the hardware unit.

There is no first or second output in the kirkwood controller; there are I2S and S/PDIF outputs. Their hardware controls are done by bits in the different registers. Then, the driver may define its DAIs in any order and assign any DAI ID to these DAIs. So, for a given DAI, there is no relation between its type (I2s or S/PDIF), index in the dai driver (= asoc component index) and ID.

In the simple-card DT, the CPU DAI (as the CODEC DAI) is referenced by a phandle (the audio-controller) and a number which should identify the DAI. This number is translated to a DAI name thanks to the function snd_soc_get_dai_name(). This function scans the components and returns the name of the DAI (component) supported by the audio controller with the searched number equal to the component index (there is no 'xlate' function).

So, with the simple-card, the CPU or CODEC DAI binding (phandle + number) identifies what the software has put in its table, but not a hardware entity.

Quoted 15 lines

Quoted 15 lines

More: a simple audio card may easily be created from a graph of ports as the simple-card does, but by the audio-controller (sorry, I also forgot the kirkwood patch for this in my previous patch request). In case of complex cards, the links and properties of this graph may also be used by board specific card devices.

Quoted 7 lines

One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is a bus and can have more than one reader/writer.

The second issue is how to describe the clock and frame master relationships. Multiple different buses can share the same clock and frame generator. E.g. typically the capture and playback stream are linked in this way.

Quoted 6 lines

Quoted 3 lines

The ports and endpoints may contain properties to describe these configurations. Complex cases should be handled by specific card builders.

Could you describe in detail what a card builder is and how to decide when and how a card builder is executed?

A card builder is a device which
- scans the graph of ports,
- fills the struct snd_soc_card according to the links between the ports and their properties,
- and, eventually, calls snd_soc_register_card().

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

For complex cards, a card builder would be the same as an actual card driver, but with the capability to know about the board thanks to the graph of ports. Its creation could be done by a compatible device in the DT (as actually) or by the unique or a 'master' audio controller.

A card builder is subject to a PROBE_DEFER after calling snd_soc_register_card(), so, when it is created by an audio controller, this last one should have created its own resources.

An audio controller does the following:
- initialize the hardware and software,
- create the DAIs from:
- the graph of ports or
- default values
- register these DAIs and
- if the DAIs where created by a graph of port,
create the card builder.

Quoted 19 lines · Jean-Francois Moine

Quoted 1 line · On Fri, 23 Jan 2015 14:56:04 +0100 Lars-Peter Clausen…

On 01/23/2015 01:15 PM, Jean-Francois Moine wrote:

There is no first or second output in the kirkwood controller; there are I2S and S/PDIF outputs. Their hardware controls are done by bits in the different registers. Then, the driver may define its DAIs in any order and assign any DAI ID to these DAIs. So, for a given DAI, there is no relation between its type (I2s or S/PDIF), index in the dai driver (= asoc component index) and ID.

In the simple-card DT, the CPU DAI (as the CODEC DAI) is referenced by a phandle (the audio-controller) and a number which should identify the DAI. This number is translated to a DAI name thanks to the function snd_soc_get_dai_name(). This function scans the components and returns the name of the DAI (component) supported by the audio controller with the searched number equal to the component index (there is no 'xlate' function).

Quoted 3 lines

So, with the simple-card, the CPU or CODEC DAI binding (phandle + number) identifies what the software has put in its table, but not a hardware entity.

Are you talking about the kirkwood driver or about things in general?

What you are saying is not true in general, if it is true for the kirkwood driver than the driver is broken in regards to DT bindings.

The specifier that follows after the phandle is hardware specific. This can be any number of integers. And the meaning of this is defined in the bindings specification for that hardware.

Many specifications define a binding in which either no specifier needs to be supplied, since there is only a single DAI, or one integer specifier which denotes which DAI is referenced for a multi-DAI controller. In the later case the bindings specification has to state which number maps to which physical DAI. Out of convenience many drivers use the same order as given in the bindings specification for their ASoC DAIs. Which is why the ASoC core provides a standard implementation for translating phandle + specifier to a ASoC DAI. But it is important to remember that the authoritative entity here is the bindings specification and not the driver.

If the bindings specification uses a different scheme for referencing the DAIs a custom xlate function needs to be provided by the driver confirms to this specification.

Quoted 22 lines

Quoted 2 lines

Could you describe in detail what a card builder is and how to decide when and how a card builder is executed?

A card builder is a device which
- scans the graph of ports,
- fills the struct snd_soc_card according to the links between the ports and their properties,
- and, eventually, calls snd_soc_register_card().

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

For complex cards, a card builder would be the same as an actual card driver, but with the capability to know about the board thanks to the graph of ports. Its creation could be done by a compatible device in the DT (as actually) or by the unique or a 'master' audio controller.

A card builder is subject to a PROBE_DEFER after calling snd_soc_register_card(), so, when it is created by an audio controller, this last one should have created its own resources.

Quoted 8 lines

An audio controller does the following:
- initialize the hardware and software,
- create the DAIs from:
- the graph of ports or
- default values
- register these DAIs and
- if the DAIs where created by a graph of port,
create the card builder.

I don't understand how invoking the card builder from the CPU side audio controller driver will work. The audio controller driver does not know what card it is part of, so how does it decide which builder to call, and what happens in the case of multiple CPU side audio controllers involved in the same card. In rare cases there might not even be a CPU side audio controller involved at all.

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.

Quoted 20 lines · On Sat, 24 Jan 2015 12:27:35 +0100 Lars-Peter Clausen…

Quoted 19 lines · Jean-Francois Moine

Quoted 1 line · On Fri, 23 Jan 2015 14:56:04 +0100 Lars-Peter Clausen…

On 01/23/2015 01:15 PM, Jean-Francois Moine wrote:

There is no first or second output in the kirkwood controller; there are I2S and S/PDIF outputs. Their hardware controls are done by bits in the different registers. Then, the driver may define its DAIs in any order and assign any DAI ID to these DAIs. So, for a given DAI, there is no relation between its type (I2s or S/PDIF), index in the dai driver (= asoc component index) and ID.

In the simple-card DT, the CPU DAI (as the CODEC DAI) is referenced by a phandle (the audio-controller) and a number which should identify the DAI. This number is translated to a DAI name thanks to the function snd_soc_get_dai_name(). This function scans the components and returns the name of the DAI (component) supported by the audio controller with the searched number equal to the component index (there is no 'xlate' function).

Quoted 5 lines

Quoted 3 lines

So, with the simple-card, the CPU or CODEC DAI binding (phandle + number) identifies what the software has put in its table, but not a hardware entity.

Are you talking about the kirkwood driver or about things in general?

I was talking about the kirkwood driver for the I2S and S/PDIF numbers. Other drivers may have the same problems.

Quoted 17 lines

What you are saying is not true in general, if it is true for the kirkwood driver than the driver is broken in regards to DT bindings.

The specifier that follows after the phandle is hardware specific. This can be any number of integers. And the meaning of this is defined in the bindings specification for that hardware.

Many specifications define a binding in which either no specifier needs to be supplied, since there is only a single DAI, or one integer specifier which denotes which DAI is referenced for a multi-DAI controller. In the later case the bindings specification has to state which number maps to which physical DAI. Out of convenience many drivers use the same order as given in the bindings specification for their ASoC DAIs. Which is why the ASoC core provides a standard implementation for translating phandle + specifier to a ASoC DAI. But it is important to remember that the authoritative entity here is the bindings specification and not the driver.

Quoted 3 lines

If the bindings specification uses a different scheme for referencing the DAIs a custom xlate function needs to be provided by the driver confirms to this specification.

I did not have a look at any other multi-DAI audio CPU/CODEC, so, I can be wrong.

All I can say is:
- the driver is responsible to define its DAIs,
- it may create them in any order,
- the index of these DAIs is used in the DT.

Then, for you, the DT binding should clearly indicate the relation between the specifier that follows the phandle and the hardware DAI.

For the kirkwood audio controller, with a DT as:

	audio-ports = "spdif", "i2s";

the DT documentation should say:

- option 1: "the DAI specifier is always '0' for I2S and '1' for S/PDIF"

- option 2: "the DAI specifier is the index of the port in the port declaration"

The actual problem is that there is no port definition in the DT for the kirkwood audio controller.

On the other side, referencing the DAI by an endpoint nullifies the DAI specifier problem: this last one does not exist anymore!

Quoted 31 lines

Quoted 22 lines

Quoted 2 lines

Could you describe in detail what a card builder is and how to decide when and how a card builder is executed?

A card builder is a device which
- scans the graph of ports,
- fills the struct snd_soc_card according to the links between the ports and their properties,
- and, eventually, calls snd_soc_register_card().

The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller.

For complex cards, a card builder would be the same as an actual card driver, but with the capability to know about the board thanks to the graph of ports. Its creation could be done by a compatible device in the DT (as actually) or by the unique or a 'master' audio controller.

A card builder is subject to a PROBE_DEFER after calling snd_soc_register_card(), so, when it is created by an audio controller, this last one should have created its own resources.

Quoted 8 lines

An audio controller does the following:
- initialize the hardware and software,
- create the DAIs from:
- the graph of ports or
- default values
- register these DAIs and
- if the DAIs where created by a graph of port,
create the card builder.

Quoted 6 lines

I don't understand how invoking the card builder from the CPU side audio controller driver will work. The audio controller driver does not know what card it is part of, so how does it decide which builder to call, and what happens in the case of multiple CPU side audio controllers involved in the same card. In rare cases there might not even be a CPU side audio controller involved at all.

Each entity referenced in the graph knows each other one and the simple dt-card builder works only for one audio controller and one CODEC level (each audio link in the graph has the controller as an endpoint).

For more complex cards, a DT information must exist. It can be:

- a board specific sound node:

	sound {
		compatible = "myboard,audio-card";
		... card properties ...
	};

- a device specific sound node:

	sound {
		compatible = "mydevice,audio-card";
		audio-root = <&audio1>;	/* starting point of the graph */
		... card properties ...
	};

- 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 {
			...
		};
		...
	};

Quoted 4 lines

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()!

Quoted 13 lines

- 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:

Quoted 10 lines

	&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?

Quoted 6 lines

Quoted 3 lines

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.

Are you by chance at FOSDEM? If you are maybe we can sit down for a moment and discuss things.