All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
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>
Subject: Re: [alsa-devel] [PATCH 1/7] Documentation: of: add type property
Date: Mon, 27 Jun 2016 01:14:23 +0000	[thread overview]
Message-ID: <87mvm7xwvm.wl%kuninori.morimoto.gx@renesas.com> (raw)
In-Reply-To: <87r3bjxzw7.wl%kuninori.morimoto.gx@renesas.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
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>
Subject: Re: [PATCH 1/7] Documentation: of: add type property
Date: Mon, 27 Jun 2016 01:14:23 +0000	[thread overview]
Message-ID: <87mvm7xwvm.wl%kuninori.morimoto.gx@renesas.com> (raw)
In-Reply-To: <87r3bjxzw7.wl%kuninori.morimoto.gx@renesas.com>

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.

  reply	other threads:[~2016-06-27  1:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24  2:30 [PATCH 0/7] of_graph: prepare for ALSA graph support Kuninori Morimoto
2016-06-24  2:32 ` [PATCH 1/7] Documentation: of: add type property Kuninori Morimoto
2016-06-24  2:32   ` Kuninori Morimoto
2016-06-24 17:41   ` Rob Herring
2016-06-27  0:09     ` Kuninori Morimoto
2016-06-27  0:09       ` Kuninori Morimoto
2016-06-27  1:14       ` Kuninori Morimoto [this message]
2016-06-27  1:14         ` Kuninori Morimoto
2016-06-24  2:32 ` [PATCH 2/7] of_graph: add of_graph_get_remote_endpoint() Kuninori Morimoto
2017-05-17  9:53   ` Applied "of_graph: add of_graph_get_remote_endpoint()" to the asoc tree Mark Brown
2017-05-17  9:53     ` Mark Brown
2016-06-24  2:32 ` [PATCH 3/7] of_graph: add of_graph_port/endpoint_type_is() Kuninori Morimoto
2016-06-24  2:32   ` Kuninori Morimoto
2016-06-24  2:33 ` [PATCH 4/7] of_graph: add of_graph_get_endpoint_count() Kuninori Morimoto
2016-06-24  2:33   ` Kuninori Morimoto
2016-06-24  2:33 ` [PATCH 5/7] of_graph: add of_graph_get_port_parent() Kuninori Morimoto
2016-06-24  2:33   ` Kuninori Morimoto
2017-05-17  9:53   ` Applied "of_graph: add of_graph_get_port_parent()" to the asoc tree Mark Brown
2017-05-17  9:53     ` Mark Brown
2016-06-24  2:33 ` [PATCH 6/7] of_graph: add of_graph_get_top_port() Kuninori Morimoto
2016-06-24  2:33   ` Kuninori Morimoto
2016-06-24  4:39   ` kbuild test robot
2016-06-24  9:22     ` Kuninori Morimoto
2016-06-24  9:22       ` Kuninori Morimoto
2016-06-24  2:34 ` [PATCH 7/7] of_graph: add for_each_of_port() / for_each_of_endpoint_in_port() Kuninori Morimoto
2016-06-24  2:34   ` Kuninori Morimoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvm7xwvm.wl%kuninori.morimoto.gx@renesas.com \
    --to=kuninori.morimoto.gx@renesas.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=broonie@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=grant.likely@linaro.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.