[alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card
Hi Mark
Current simple-card is using "sound-dai" base connection on DT, but V4L2 is using graph base connection. For example HDMI case, we would like to use both connection. To above confusable connection method, and to reuse current resource, this patch adds new function, and detect both "sound-dai" and "remote-endpoint" on simple-card. like this
sound { compatible = "simple-audio-card"; ... sndcpu: simple-audio-card,cpu { sound-dai = <&xxx>; }; sndcodec: simple-audio-card,codec { => remote-endpoint = <&out_hdmi>; }; };
xxx { ... ports { ... port@0 { reg = <0>; out_rgb: endpoint { }; }; port@1 { reg = <1>; => out_hdmi: endpoint { }; }; ... }; };
Kuninori Morimoto (4): of_graph: add of_graph_get_endpoint_count() ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection ASoC: snd_soc_of_get_dai_name() uses of_parse_snd_soc_connection_with_args() ASoC: simple-card: probe both sound-dai and remote-endpoint
Documentation/devicetree/bindings/sound/simple-card.txt | 19 +++++++++++++++++++ include/linux/of_graph.h | 11 +++++++++++ include/sound/soc.h | 2 ++ sound/soc/generic/simple-card.c | 9 ++++++--- sound/soc/soc-core.c | 45 +++++++++++++++++++++++++++++++++++++++++++-- 5 files changed, 81 insertions(+), 5 deletions(-)
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
same as of_get_child_count()
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com --- include/linux/of_graph.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h index f8bcd0e..4b9c3c5 100644 --- a/include/linux/of_graph.h +++ b/include/linux/of_graph.h @@ -91,4 +91,15 @@ static inline struct device_node *of_graph_get_remote_port(
#endif /* CONFIG_OF */
+static inline int of_graph_get_endpoint_count(const struct device_node *np) +{ + struct device_node *child; + int num = 0; + + for_each_endpoint_of_node(np, child) + num++; + + return num; +} + #endif /* __LINUX_OF_GRAPH_H */
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Current ASoC card connection is based on "sound-dai" on DT, but V4L2 connection is using graph base. This patch adds common function which can detect both connection.
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com --- include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h index 02b4a21..17ddc25 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1669,6 +1669,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node *np, const char *prefix, struct device_node **bitclkmaster, struct device_node **framemaster); +int of_parse_snd_soc_connection_with_args(const struct device_node *np, + struct of_phandle_args *out_args); int snd_soc_of_get_dai_name(struct device_node *of_node, const char **dai_name); int snd_soc_of_get_dai_link_codecs(struct device *dev, diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d2e62b15..643b244 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -34,6 +34,7 @@ #include <linux/ctype.h> #include <linux/slab.h> #include <linux/of.h> +#include <linux/of_graph.h> #include <sound/core.h> #include <sound/jack.h> #include <sound/pcm.h> @@ -3839,6 +3840,47 @@ static int snd_soc_get_dai_name(struct of_phandle_args *args, return ret; }
+int of_parse_snd_soc_connection_with_args(const struct device_node *np, + struct of_phandle_args *out_args) +{ + int ret; + + ret = of_parse_phandle_with_args(np, "sound-dai", + "#sound-dai-cells", 0, out_args); + if (ret) { + struct device_node *p_node = NULL; + struct device_node *ep_node = NULL; + struct of_endpoint ep; + + /* try graph base parse */ + p_node = of_graph_get_remote_port_parent(np); + if (!p_node) + return -EINVAL; + + ep_node = of_graph_get_remote_port(np); + if (!p_node) { + ret = -EINVAL; + goto graph_err_parent; + } + + ret = of_graph_parse_endpoint(ep_node, &ep); + if (ret < 0) + goto graph_err_endpoint; + + out_args->np = p_node; + out_args->args_count = (1 != of_graph_get_endpoint_count(p_node)); + out_args->args[0] = ep.port; + +graph_err_endpoint: + of_node_put(ep_node); +graph_err_parent: + of_node_put(p_node); + } + + return ret; +} +EXPORT_SYMBOL_GPL(of_parse_snd_soc_connection_with_args); + int snd_soc_of_get_dai_name(struct device_node *of_node, const char **dai_name) {
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com --- sound/soc/soc-core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 643b244..fed5076 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3887,8 +3887,7 @@ int snd_soc_of_get_dai_name(struct device_node *of_node, struct of_phandle_args args; int ret;
- ret = of_parse_phandle_with_args(of_node, "sound-dai", - "#sound-dai-cells", 0, &args); + ret = of_parse_snd_soc_connection_with_args(of_node, &args); if (ret) return ret;
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Current simple-card can probe "sound-dai" base connection on DT. OTOH, V4L2 soc is using graph base connection. Because of this different style, DT will be confusable if it support both video/sound in same time.
This patch enables both "sound-dai" (= current simple-card style) and "remote-endpoint" (= current V4L2 style) on simple-card.
sound { compatible = "simple-audio-card"; ... sndcpu: simple-audio-card,cpu { sound-dai = <&xxxx>; }; sndcodec: simple-audio-card,codec { remote-endpoint = <&yyyy>; }; };
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com --- .../devicetree/bindings/sound/simple-card.txt | 19 +++++++++++++++++++ sound/soc/generic/simple-card.c | 9 ++++++--- 2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index cf3979e..030edca 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -70,6 +70,7 @@ properties should also be placed in the codec node if needed. Required CPU/CODEC subnodes properties:
- sound-dai : phandle and port of CPU/CODEC +- remote-endpoint : graph endpoint of CPU/CODEC
Optional CPU/CODEC subnodes properties:
@@ -162,3 +163,21 @@ sound { }; }; }; + +Example 3 - sound-dai and remote-endpoint + +rsnd_ak4613: sound { + compatible = "simple-audio-card"; + + simple-audio-card,name = "R-Sound"; + simple-audio-card,format = "left_j"; + simple-audio-card,bitclock-master = <&sndcpu>; + simple-audio-card,frame-master = <&sndcpu>; + + sndcpu: simple-audio-card,cpu { + sound-dai = <&rcar_sound 1>; + }; + sndcodec: simple-audio-card,codec { + remote-endpoint = <&du_out_hdmi0>; + }; +}; diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c index 2389ab4..a1d6001 100644 --- a/sound/soc/generic/simple-card.c +++ b/sound/soc/generic/simple-card.c @@ -14,6 +14,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_gpio.h> +#include <linux/of_graph.h> #include <linux/platform_device.h> #include <linux/string.h> #include <sound/jack.h> @@ -224,11 +225,13 @@ asoc_simple_card_sub_parse_of(struct device_node *np, int ret;
/* - * Get node via "sound-dai = <&phandle port>" + * Get node via + * sound-dai = <&phandle port> + * or + * remote-endpoint = <&phandle> * it will be used as xxx_of_node on soc_bind_dai_link() */ - ret = of_parse_phandle_with_args(np, "sound-dai", - "#sound-dai-cells", 0, &args); + ret = of_parse_snd_soc_connection_with_args(np, &args); if (ret) return ret;
On Thu, 14 Apr 2016 05:45:41 +0000 Kuninori Morimoto kuninori.morimoto.gx@renesas.com wrote:
Current simple-card is using "sound-dai" base connection on DT, but V4L2 is using graph base connection. For example HDMI case, we would like to use both connection. To above confusable connection method, and to reuse current resource, this patch adds new function, and detect both "sound-dai" and "remote-endpoint" on simple-card. like this
sound { compatible = "simple-audio-card"; ... sndcpu: simple-audio-card,cpu { sound-dai = <&xxx>; }; sndcodec: simple-audio-card,codec { => remote-endpoint = <&out_hdmi>; }; };
xxx { ... ports { ... port@0 { reg = <0>; out_rgb: endpoint { }; }; port@1 { reg = <1>; => out_hdmi: endpoint { }; }; ... }; };
[snip]
Hi Kuninori,
Thanks for this first step towards the graph of ports in audio, but I don't see exactly the use of this remote-endpoint.
According to Documentation/devicetree/bindings/graph.txt section "Links between endpoints", the endpoint/remote-endpoint links are bi-directional and describe the physical links: the audio port of the codec is connected to the audio controller and reverse. There is no reverse link from the codec to the 'simple-card'.
If the codec has only one DAI, using the remote-port just complexifies the access to the codec (remote-port -> endpoint -> parent [->parent]).
If the codec has more than one audio input, a DT may look like:
hdmi_transmitter { ... port@1 { /* audio from I2S */ reg = <1>; ... i2s: endpoint { remote-endpoint = <&audio_i2s>; }; }; port@2 { /* audio from S/PDIF */ reg = <2>; ... spdif: endpoint { remote-endpoint = <&audio_spdif>; }; }; }; (the video port is not shown and may be declared before, between or after the audio ports)
The codec associated to the HDMI transmitter declares 2 DAIs. It may choose to define the DAI numbers either in a fixed order (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
As the DAI numbers are used by the simple card to get the DAI names, their values must be know.
With the standard declaration of the codec DAIs in the simple card (phandle to the codec - hdmi - plus DAI number), either numbering scheme works (the documentation of the hdmi transmitter tells which scheme is used and the DAI number in the DT is set accordingly).
When using a phandle to the remote-endpoint (without DAI number), the simple card has no direct way to find the DAI number: - with a fixed order, some more information must be set in the DT (audio port type), - with a dynamic order, a loop on all ports must be done, counting the audio ports and skipping the video port(s).
Hi Jean
Thank you for your feedback
According to Documentation/devicetree/bindings/graph.txt section "Links between endpoints", the endpoint/remote-endpoint links are bi-directional and describe the physical links: the audio port of the codec is connected to the audio controller and reverse. There is no reverse link from the codec to the 'simple-card'.
(snip)
The codec associated to the HDMI transmitter declares 2 DAIs. It may choose to define the DAI numbers either in a fixed order (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
My assumption was video/audio are using same port, but indeed we need to care about more.
But, if we need to describe both "video port" and "audio port" separately in graph, simple-card side doesn't need graph style IMO. Because normal phandle style (= non graph style) is working already.
I thought that describing both "video" and "audio" is too much. -> assume that video/audio can share same port -> this patch -> but thoughtless :P
I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name can works for us ?
My concern is if audio side need to care/support "formal" graph style, I think all cpu/codec/card driver (and soc-core too ?) need to be updated, but it is too much for me. if fake graph style (like this patch) is OK, I'm happy to hack it more.
Best regards --- Kuninori Morimoto
Hi again
According to Documentation/devicetree/bindings/graph.txt section "Links between endpoints", the endpoint/remote-endpoint links are bi-directional and describe the physical links: the audio port of the codec is connected to the audio controller and reverse. There is no reverse link from the codec to the 'simple-card'.
(snip)
The codec associated to the HDMI transmitter declares 2 DAIs. It may choose to define the DAI numbers either in a fixed order (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
My assumption was video/audio are using same port, but indeed we need to care about more.
But, if we need to describe both "video port" and "audio port" separately in graph, simple-card side doesn't need graph style IMO. Because normal phandle style (= non graph style) is working already.
I thought that describing both "video" and "audio" is too much. -> assume that video/audio can share same port -> this patch -> but thoughtless :P
I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name can works for us ?
My concern is if audio side need to care/support "formal" graph style, I think all cpu/codec/card driver (and soc-core too ?) need to be updated, but it is too much for me. if fake graph style (like this patch) is OK, I'm happy to hack it more.
This "fake graph style" means it is supporting both graph's "remote-endpoint" and current simple-card's "sound-dai" (= not 100% graph style).
On Fri, 15 Apr 2016 09:26:03 +0000 Kuninori Morimoto kuninori.morimoto.gx@renesas.com wrote:
According to Documentation/devicetree/bindings/graph.txt section "Links between endpoints", the endpoint/remote-endpoint links are bi-directional and describe the physical links: the audio port of the codec is connected to the audio controller and reverse. There is no reverse link from the codec to the 'simple-card'.
(snip)
The codec associated to the HDMI transmitter declares 2 DAIs. It may choose to define the DAI numbers either in a fixed order (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
My assumption was video/audio are using same port, but indeed we need to care about more.
But, if we need to describe both "video port" and "audio port" separately in graph, simple-card side doesn't need graph style IMO. Because normal phandle style (= non graph style) is working already.
I thought that describing both "video" and "audio" is too much. -> assume that video/audio can share same port -> this patch -> but thoughtless :P
I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name can works for us ?
My concern is if audio side need to care/support "formal" graph style, I think all cpu/codec/card driver (and soc-core too ?) need to be updated, but it is too much for me. if fake graph style (like this patch) is OK, I'm happy to hack it more.
This "fake graph style" means it is supporting both graph's "remote-endpoint" and current simple-card's "sound-dai" (= not 100% graph style).
Hi Kuninori,
Maybe I was not clear. Here is more information.
The simple-card must know the codec (DAI) device node and the DAI name (found from the DAI number thanks to snd_soc_get_dai_name ()::of_xlate_dai_name()).
The actual definition "sound-dai" works directly in any case, with or without a graph of ports. Indeed, the DAI of the codec must be known (option fixed/dynamic number).
A graph of ports describes the links between the hardware components. Fox example, in the (Dove) Cubox, the HDMI transmitter receives video (one port) from the video controller and audio (2 ports) from the audio controller. The graph is:
video <-----------------------\ v | i2s <------> CODEC = HDMI transmitter audio < ^ | s/pdif <-----/ ---> S/PDIF connector
In the DT, the HDMI is described by:
hdmi: hdmi-encoder { ... port@0 { port-type = "video"; port-value = <0x230145>; hdmi_0: endpoint { remote-endpoint = <&lcd0_0>; }; }; port@1 { /* AP1 = I2S */ port-type = "audio-i2s"; port-value = <0x03>; tda998x_i2s: endpoint { remote-endpoint = <&audio1_i2s>; }; }; port@2 { /* AP2 = S/PDIF */ port-type = "audio-spdif"; port-value = <0x04>; tda998x_spdif: endpoint { remote-endpoint = <&audio1_spdif1>; }; }; };
As you may see, there is no port link to any audio card definition as the 'simple-card'.
When using the simple-card, my definition was: sound { compatible = "simple-audio-card"; simple-audio-card,name = "Cubox Audio";
simple-audio-card,dai-link@0 { /* S/PDIF -> HDMI & S/PDIF */ format = "i2s"; cpu { sound-dai = <&audio1 1>; }; codec { sound-dai = <&hdmi 0>, <&spdif_codec>; }; };
simple-audio-card,dai-link@1 { /* I2S -> HDMI */ format = "i2s"; cpu { sound-dai = <&audio1 0>; }; codec { sound-dai = <&hdmi 1>; }; }; };
This worked fine, but I found that the simple-card was redondant with the graph of ports, so, now, in my system, the card creation is done only from the graph of ports (without any more information in the DT - this system was proposed in january 2015 http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086837.htm... but rejected).
At startup time, the audio driver scans its ports in the graph. This permits for it to create its own DAIs. Then, it looks at the remote-ports. These ones define the DAI links: the CPU side is a local DAI, and the CODEC side is the parent of the remote port plus a DAI number. The problem is that the DAI number is not in the DT. It must be computed. This is simply done scanning the ports of the codec (remote) node and skipping the non-audio ports (indeed, this works because the hdmi codec uses a dynamic port numbering scheme).
For information here is the DT of the audio controller:
audio1: audio-controller@b4000 { audio-card,format = "i2s"; port@0 { port-type = "spdif"; audio1_spdif0: endpoint@0 { remote-endpoint = <&spdif_out>; }; audio1_spdif1: endpoint@1 { remote-endpoint = <&tda998x_spdif>; }; }; port@1 { port-type = "i2s"; audio1_i2s: endpoint { remote-endpoint = <&tda998x_i2s>; }; };
So, in brief: - the simple-card with only "sound-dai" works fine with or without a graph of ports, - for a full use of the graph of ports, forget about the simple-card.
Hi Jean
Thank you for clearing your problem. Sorry for my confusable email. But can I ask something ?
My concern is if audio side need to care/support "formal" graph style, I think all cpu/codec/card driver (and soc-core too ?) need to be updated, but it is too much for me. if fake graph style (like this patch) is OK, I'm happy to hack it more.
This "fake graph style" means it is supporting both graph's "remote-endpoint" and current simple-card's "sound-dai" (= not 100% graph style).
(snip)
So, in brief:
- the simple-card with only "sound-dai" works fine with or without a graph of ports,
- for a full use of the graph of ports, forget about the simple-card.
Q1 If we use full graph style card, and if it would like to reuse current existing CPU/CODEC driver, then, I think CPU/CODEC driver should support graph style too. (Now, I'm checking v4l2 side existing graph style driver) I know it is based on its current implementation, but basically YES ?
Q2 If Q1 was Yes, to keeping ABI compatibility, that CPU/CODEC driver should support both "phandle" and "graph" style ?
On Mon, 18 Apr 2016 02:43:21 +0000 Kuninori Morimoto kuninori.morimoto.gx@renesas.com wrote:
But can I ask something ?
My concern is if audio side need to care/support "formal" graph style, I think all cpu/codec/card driver (and soc-core too ?) need to be updated, but it is too much for me. if fake graph style (like this patch) is OK, I'm happy to hack it more.
This "fake graph style" means it is supporting both graph's "remote-endpoint" and current simple-card's "sound-dai" (= not 100% graph style).
(snip)
So, in brief:
- the simple-card with only "sound-dai" works fine with or without a graph of ports,
- for a full use of the graph of ports, forget about the simple-card.
Q1 If we use full graph style card, and if it would like to reuse current existing CPU/CODEC driver, then, I think CPU/CODEC driver should support graph style too. (Now, I'm checking v4l2 side existing graph style driver) I know it is based on its current implementation, but basically YES ?
Q2 If Q1 was Yes, to keeping ABI compatibility, that CPU/CODEC driver should support both "phandle" and "graph" style ?
Hi Kuninori,
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.
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 ?
On Wed, 20 Apr 2016 02:55:39 +0000 Kuninori Morimoto kuninori.morimoto.gx@renesas.com wrote:
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 ?
Hi Kuninori,
I have no plan. My Cubox machine has too many specific code and it is used in an organ as the sound synthesizer. I will not do any more development in its kernel. In my new machine, an Orange PI 2, while audio on HDMI is working for me, there is still a lot of job to do aside (YUV video, analog audio, embedded wifi...) and I am blocked by the HDMI driver which has no free license nor documentation about the hardware. So, I have not submitted yet a patch series about audio for this machine.
Otherwise, if you read the previous discussions, I think the most important is Mark's remark (Sat, 7 Feb 2015 16:33:55 +0800 in the alsa-devel mailing-list):
We already have simple-card to provide a binding for trivial systems and don't want to end up with a never ending series of slightly more complicated bindings which each cover slightly different sets of systems in ways that users struggle to differentiate between.
On Thu, Apr 14, 2016 at 05:45:41AM +0000, Kuninori Morimoto wrote:
Hi Mark
Current simple-card is using "sound-dai" base connection on DT, but V4L2 is using graph base connection. For example HDMI case, we would like to use both connection. To above confusable connection method, and to reuse current resource, this patch adds new function, and detect both "sound-dai" and "remote-endpoint" on simple-card. like this
sound { compatible = "simple-audio-card"; ... sndcpu: simple-audio-card,cpu { sound-dai = <&xxx>; }; sndcodec: simple-audio-card,codec { => remote-endpoint = <&out_hdmi>;
This is not valid usage of the graph binding. You are only using half of it.
};};
xxx { ... ports { ... port@0 { reg = <0>; out_rgb: endpoint { }; }; port@1 { reg = <1>; => out_hdmi: endpoint { }; }; ... }; };
Kuninori Morimoto (4): of_graph: add of_graph_get_endpoint_count() ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection ASoC: snd_soc_of_get_dai_name() uses of_parse_snd_soc_connection_with_args() ASoC: simple-card: probe both sound-dai and remote-endpoint
Documentation/devicetree/bindings/sound/simple-card.txt | 19 +++++++++++++++++++ include/linux/of_graph.h | 11 +++++++++++ include/sound/soc.h | 2 ++ sound/soc/generic/simple-card.c | 9 ++++++--- sound/soc/soc-core.c | 45 +++++++++++++++++++++++++++++++++++++++++++-- 5 files changed, 81 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
participants (3)
-
Jean-Francois Moine -
Kuninori Morimoto -
Rob Herring