From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: [PATCH 1/7] Documentation: of: add type property
Date: Mon, 27 Jun 2016 01:14:23 +0000
Message-ID: <87mvm7xwvm.wl%kuninori.morimoto.gx@renesas.com>
References: <87fus3xr2q.wl%kuninori.morimoto.gx@renesas.com>
 <87eg7nxr00.wl%kuninori.morimoto.gx@renesas.com>
 <CAL_JsqKxYUXJoAmYQOiSVdodKmrEPqVgm84ZVhhEw=FuJQhZTw@mail.gmail.com>
 <87r3bjxzw7.wl%kuninori.morimoto.gx@renesas.com>
Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
In-Reply-To: <87r3bjxzw7.wl%kuninori.morimoto.gx@renesas.com>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/options/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel/>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Errors-To: alsa-devel-bounces@alsa-project.org
Sender: alsa-devel-bounces@alsa-project.org
To: Rob Herring <robh+dt@kernel.org>, Laurent <laurent.pinchart@ideasonboard.com>
Cc: Linux-DT <devicetree@vger.kernel.org>, Linux-ALSA <alsa-devel@alsa-project.org>, Mark Brown <broonie@linaro.org>, Linux-Kernel <linux-kernel@vger.kernel.org>, Mark Brown <broonie@kernel.org>, Grant Likely <grant.likely@linaro.org>, Frank Rowand <frowand.list@gmail.com>, Guennadi <g.liakhovetski@gmx.de>
List-Id: devicetree@vger.kernel.org

Hi Rob, Laurent

> > > +Each ports / port / endpoint can have its type if needed.
> > 
> > I think type should only apply to a port. ports is only a grouping for
> > multiple ports. endpoints are just the connection. A port is a single
> > data flow, so 2 endpoints on a port reflect 2 possible connections for
> > that data flow.
> > 
> > > +child node can take over parent node type. below example indicates
> > > +device0 type is "typeA" && "typeB",
> > > +device1 type is "typeA" && "typeB" && "typeC".
> > 
> > This does not make sense to me. A concrete example perhaps using HDMI
> > audio would be helpful.
> 
> "type" on "port" only is OK. I will fix that.
> 
> Multi type feature (= take over from parent) and type on "endpoint"
> is not urgent at this point, so I will drop these in v2.
> I just thought that it will be necessary in the future.

In HDMI case, which one is better DT ?

	port@0 {
		type = "video";
                endpoint {
                        remote-endpoint = <&xxx>;
                };
	};
	port@1 {
		type = "sound";
                endpoint {
                        remote-endpoint = <&xxx>;
                };
	};

or

	port {
                endpoint {
			type = "video";
                        remote-endpoint = <&xxx>;
                };
                endpoint {
			type = "sound";
                        remote-endpoint = <&xxx>;
                };
	};

If 2nd one is better, type on endpoint is needed.