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:   13 Dec 2018 09:24:06 +0900
Message-ID: <87imzy2sh1.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: <20181212152725.GE6707@atomide.com>
References: <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>
        <87k1kfs0u5.wl-kuninori.morimoto.gx@renesas.com>
        <20181212152725.GE6707@atomide.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

>  	/* Codec has 1 DAI */
>  	Codec {
>  		port {
> 			#address-cells = <2>;
> 			#size-cells = <1>;
> 
>  			ep: endpoint {
>  				remote-endpoint = <xxx>;
>  			};
>  		};
>  	}
(snip)
> foo = <&ep 0>;
> bar = <&ep 1>;

Ahh, it looks nice idea !
but hmm..., it seems dtc doesn't allow us to use #address-cells = <2>
for "remote-endpoint".

--- ${LINUX}/scripts/dtc/checks.c ---
static struct node *get_remote_endpoint(struct check *c, struct dt_info *dti,
					struct node *endpoint)
{
	...
	prop = get_property(endpoint, "remote-endpoint");
	if (!prop)
		return NULL;

=>	phandle = propval_cell(prop);
	/* Give up if this is an overlay with external references */
	...
}

I'm not good at dtc, but propval_cell() is assuming it is single address cell.
We will have many assert warning on

	remote-endpoint = <&xxx 0>;

Can you please double check it ?

And, I'm wonder remote-endpoint need to cross pointing, right ?
one way looks nice by address-cells <2>, but other way is ?

	port {
		cpu-ep0: endpoint@0 {
			remote-endpoint = <&codec-ep 0>;
		};
		cpu-ep1: endpoint@1 {
			remote-endpoint = <&codec-ep 1>;
		};
	};

	port {
		#address-cells = <2>;
		#size-cells = <1>;
		codec-ep: endpoint {
(*1)			remote-endpoint = <&cpu-ep0>;
		};
	};

This case, cpu-epX -> codec-ep are OK.
But, codec-ep -> cpu-epX case can point only 1 endpoint (*1).
I'm not sure, but maybe this is not a OF graph policy (?)

> > Can you agree this ? we need extra patch,
> > but it can solve your / my problem.
> 
> Yes it's starting to make sense :)

Thanks

> > 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.
> 
> Sure, maybe please first check if the #size-cells = <2>
> option would work though?

maybe #address-cells, instead of #size-cells ;P
But, yeah, please double check it too.

> > 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.
> 
> Yeah I agree, just still wondering what might be the best
> way to represent 1 DAI vs 2 DAIs.

According to OF graph maintainer, he said that
counting port / endpoint are not guaranteed,
and we need to use "reg".
(It is the reason of b6f3fc005a2c8b425d7a0973b43bef05890bf479)

If you could double checked, and we could agreed
that "reg" is the solution for us.
I will post patches.

Best regards
---
Kuninori Morimoto