Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 15 Apr 2016 09:26:03 +0000
Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx> 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.html
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.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux