Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   12 Dec 2018 15:51:56 +0900
Message-ID: <87k1kfs0u5.wl-kuninori.morimoto.gx@renesas.com>
From:   Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
To:     Tony Lindgren <tony@atomide.com>
Cc:     "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Takashi Iwai <tiwai@suse.com>,
        Peter Ujfalusi <peter.ujfalusi@ti.com>,
        Mark Brown <broonie@kernel.org>,
        Sebastian Reichel <sre@kernel.org>,
        Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple    endpoints per port
In-Reply-To: <877egf33m9.wl-kuninori.morimoto.gx@renesas.com>
References: <20181211020557.61783-1-tony@atomide.com>   <8736r4bvf3.wl-kuninori.morimoto.gx@renesas.com>        <20181211045220.GI6707@atomide.com>     <871s6obqkb.wl-kuninori.morimoto.gx@renesas.com>        <20181211053536.GJ6707@atomide.com>     <87wooga9an.wl-kuninori.morimoto.gx@renesas.com>        <20181211141649.GL6707@atomide.com>     <87ftv33bpg.wl-kuninori.morimoto.gx@renesas.com>        <20181212001950.GX6707@atomide.com>     <877egf33m9.wl-kuninori.morimoto.gx@renesas.com>
User-Agent: Wanderlust/2.15.9 Emacs/24.5 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Hi Tony, again

> > > 	https://patchwork.kernel.org/patch/10712877/
> > 
> > Hmm, so do you have multiple separate ports at the "&sound" node
> > hardware? If so then yeah multiple ports make sense.
> >
> > But if you only a single physical (I2S?) port at the
> > "&sound" node hardware, then IMO you should only have one
> > port and multiple endpoints there according to the graph.txt
> > binding doc.
> > 
> > In my McBSP case there is only a single physical I2S port
> > that can be TDM split into timeslots.
> 
> Mine has 4 DAIs. Each DAI can output 2ch.
> These will be merged and wil be 8ch TDM and goes to Codec.
> But hmm.. it is 4 DAIs, but 1 "physical" interface...
> 
> So, your patch seems correct, but will breaks DPCM...
> I will confirm it.

I thought "port" = "DAI", but yeah, "port" = "physical interface".
Then, my issue is that we can't judge DAI size from DT.
For example, MIXer case, 2 CPU DAIs are connected to 1 Codec.

	DAI0 --- CPU --- Codec
	DAI1 /

In this case, CPU side needs 2 DAIs,
Codec side needs 1 DAI only.
For both CPU/Codec case, OF graph will be like below,
and we can't judge DAIs size from this.

	port {
		ep0: endpint@0 {
			remote-endpoint = <xxx>;
		};
		ep1: endpint@1 {
			remote-endpoint = <xxx>;
		};
	}

To solve this issue, we need to use "reg" for it.
Then, we can get correct DAI ID.

	/* CPU has 2 DAIs */
	CPU {
		port {
			ep0: endpint@0 {
				reg = <0>;
				remote-endpoint = <xxx>;
			};
			ep1: endpint@1 {
				reg = <1>;
				remote-endpoint = <xxx>;
			};
		};
	}

	/* Codec has 1 DAI */
	Codec {
		port {
			reg = <0>;
			ep0: endpint@0 {
				remote-endpoint = <xxx>;
			};
			ep1: endpint@1 {
				remote-endpoint = <xxx>;
			};
		};
	}


Can you agree this ? we need extra patch,
but it can solve your / my problem.

Now I'm posting patches to merging
"audio-graph-card" and "DPCM ver audio-graph-card".
If you are OK, I will include above solution patch
to this patch-set.

Current audio-graph doesn't expect your use-case,
and I want to avoid conflict.

So, "merged" audio-graph should solve your use-case.
If you can agree about this, I will post patch-set.

Best regards
---
Kuninori Morimoto