On Sun, Dec 04, 2016 at 11:48:49PM +0000, Kuninori Morimoto wrote:
Hi Rob, Mark
+++ b/Documentation/devicetree/bindings/sound/simple-graph-card.txt @@ -0,0 +1,67 @@ +Simple-Graph-Card:
There's nothing simple about this. graph-audio-card or audio-card-graph.
I have no objection about naming, but this is one of simple-xxx-card series. And, this is very simple from ALSA SoC point of view...
+rcar_sound {
- ...
- port {
compatible = "asoc-simple-graph-card";Do you have an example where you'd have multiple ports? If not, this should go up a level.
ALSA SoC needs 3 type of driver, CPU/Codec/Card. But HW is SoC <-> Codec. Thus, "CPU" side DT needs to call "Card" portion, and ALSA SoC needs to select Card type (graph-audio-card, graph-scu-card, etc, etc....). Above it for it.
SoC { compatible = "cpu_driver_compatible_name"; ... port { compatible = "card_driver_compatible_name"; ... }; };
Here, SoC driver "cpu_driver_compatible_name" will handle CPU and its each port settings. And it will probes "card_driver_compatible_name". "card_driver_compatible_name" will connect CPU <-> Codec via ALSA SoC.
Don't design bindings around what ASoC wants and don't explain it in terms of how ALSA works. Design bindings in a way that reflects the h/w.
This explanation seems completely wrong to me. It seems like you are abusing OF graph to just create 2 instances of a simple-card which would be working around some ASoC limitation.
I'd expect the top level node to be the card node that knows how to find all the components. The graph should reflect the data flow. For example, the data goes to audio DSP to I2S host to codec to amp.
Rob