From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
dri-devel@lists.freedesktop.org, Inki Dae <inki.dae@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Chanwoo Choi <cw00.choi@samsung.com>,
Archit Taneja <architt@codeaurora.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector
Date: Wed, 18 Oct 2017 18:47:01 +0300 [thread overview]
Message-ID: <2206421.ioyYkBuUpd@avalon> (raw)
In-Reply-To: <3079487.ip075DyLUk@avalon>
Hi Andrzej,
On Wednesday, 18 October 2017 18:11:25 EEST Laurent Pinchart wrote:
> On Thursday, 28 September 2017 16:07:27 EEST Andrzej Hajda wrote:
> > These bindings allows to describe most known standard USB connectors
> > and it should be possible to extend it if necessary.
> > USB connectors, beside USB can be used to route other protocols,
> > for example UART, Audio, MHL. In such case every device passing data
> > through the connector should have appropriate graph bindings.
> >
> > Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> > ---
> > There are few things for discussion (IMO):
> > 1. vendor specific connectors, I have added them here, but maybe better is
> >
> > to place them in separate files.
>
> It's useful to have one vendor-specific compatible string to be used in the
> example. We could split vendor-specific connectors to separate files later
> if needed, but for now I'm fine keeping them here.
>
> > 2. physical connector description - I have split it to three properties:
> > type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
> > This tripled is able to describe all USB-standard connectors, but there
> > are also impossible combinations, for example(c, *, micro). Maybe
> > better
> > would be to just enumerate all possible connectors in include file.
>
> I don't have a strong opinion on this. The three properties are nicely
> descriptive. You might want to list the valid combinations in the bindings
> though.
>
> > 3. Numbering of port/remote nodes, currently only 0 is assigned for
> >
> > Interface Controller. Maybe other functions should be also assigned:
> > HS, SS, CC, SBU, ... whatever. Maybe functions should be described
> > as an additional property of remote node?
>
> Given that one of the main reasons this binding is needed is to describe MHL
> connection to a USB connector, I think we'll need to define additional
> functions, yes. I'm not sure yet how that should look like though.
> > ---
> >
> > .../bindings/connector/usb-connector.txt | 49 +++++++++++++++++
> > 1 file changed, 49 insertions(+)
> > create mode 100644
> >
> > Documentation/devicetree/bindings/connector/usb-connector.txt
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt new file
> > mode 100644
> > index 000000000000..f3a4e85122d5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -0,0 +1,49 @@
> > +USB Connector
> > +=============
> > +
> > +Required properties:
> > +- compatible: "usb-connector"
> > + connectors with vendor specific extensions can add one of additional
> > + compatibles:
> > + "samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
> > +- type: the USB connector type: "a", "b", "ab", "c"
> > +- max-mode: max USB speed mode supported by the connector:
> > + "ls", "fs", "hs", "ss", "ss+"
> > +
> > +Optional properties:
> > +- label: a symbolic name for the connector
> > +- size: size of the connector, should be specified in case of
> > + non-standard USB connectors: "mini", "micro", "powered"
>
> "non-standard" sounds like "vendor-specific", while I assume you're talking
> about the size. The USB specification uses the term "standard" for this
> purpose, so it's hard to use another one that would convey the right meaning
> precisely. Maybe "non-standard ('large') USB connector sizes" ?
>
> > +Required nodes:
> > +- any data bus to the connector should be modeled using the
> > + OF graph bindings specified in bindings/graph.txt.
> > + There should be exactly one port with at least one endpoint to
> > + different device nodes. The first endpoint (reg = <0>) should
> > + point to USB Interface Controller.
> > +
> > +Example
> > +-------
> > +
> > +musb_con: connector {
> > + compatible = "samsung,usb-connector-11pin", "usb-connector";
> > + label = "usb";
> > + type = "b";
> > + size = "micro";
> > + max-mode = "hs";
> > +
> > + port {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + musb_con_usb_in: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <&muic_usb_out>;
> > + };
> > +
> > + musb_con_mhl_in: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <&mhl_out>;
> > + };
> > + };
> > +};
One more comment, do I assume correctly that the Samsung 11-pin connector
carries USB and MHL on different pins ?
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector
Date: Wed, 18 Oct 2017 18:47:01 +0300 [thread overview]
Message-ID: <2206421.ioyYkBuUpd@avalon> (raw)
In-Reply-To: <3079487.ip075DyLUk@avalon>
Hi Andrzej,
On Wednesday, 18 October 2017 18:11:25 EEST Laurent Pinchart wrote:
> On Thursday, 28 September 2017 16:07:27 EEST Andrzej Hajda wrote:
> > These bindings allows to describe most known standard USB connectors
> > and it should be possible to extend it if necessary.
> > USB connectors, beside USB can be used to route other protocols,
> > for example UART, Audio, MHL. In such case every device passing data
> > through the connector should have appropriate graph bindings.
> >
> > Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> > ---
> > There are few things for discussion (IMO):
> > 1. vendor specific connectors, I have added them here, but maybe better is
> >
> > to place them in separate files.
>
> It's useful to have one vendor-specific compatible string to be used in the
> example. We could split vendor-specific connectors to separate files later
> if needed, but for now I'm fine keeping them here.
>
> > 2. physical connector description - I have split it to three properties:
> > type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
> > This tripled is able to describe all USB-standard connectors, but there
> > are also impossible combinations, for example(c, *, micro). Maybe
> > better
> > would be to just enumerate all possible connectors in include file.
>
> I don't have a strong opinion on this. The three properties are nicely
> descriptive. You might want to list the valid combinations in the bindings
> though.
>
> > 3. Numbering of port/remote nodes, currently only 0 is assigned for
> >
> > Interface Controller. Maybe other functions should be also assigned:
> > HS, SS, CC, SBU, ... whatever. Maybe functions should be described
> > as an additional property of remote node?
>
> Given that one of the main reasons this binding is needed is to describe MHL
> connection to a USB connector, I think we'll need to define additional
> functions, yes. I'm not sure yet how that should look like though.
> > ---
> >
> > .../bindings/connector/usb-connector.txt | 49 +++++++++++++++++
> > 1 file changed, 49 insertions(+)
> > create mode 100644
> >
> > Documentation/devicetree/bindings/connector/usb-connector.txt
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt new file
> > mode 100644
> > index 000000000000..f3a4e85122d5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -0,0 +1,49 @@
> > +USB Connector
> > +=============
> > +
> > +Required properties:
> > +- compatible: "usb-connector"
> > + connectors with vendor specific extensions can add one of additional
> > + compatibles:
> > + "samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
> > +- type: the USB connector type: "a", "b", "ab", "c"
> > +- max-mode: max USB speed mode supported by the connector:
> > + "ls", "fs", "hs", "ss", "ss+"
> > +
> > +Optional properties:
> > +- label: a symbolic name for the connector
> > +- size: size of the connector, should be specified in case of
> > + non-standard USB connectors: "mini", "micro", "powered"
>
> "non-standard" sounds like "vendor-specific", while I assume you're talking
> about the size. The USB specification uses the term "standard" for this
> purpose, so it's hard to use another one that would convey the right meaning
> precisely. Maybe "non-standard ('large') USB connector sizes" ?
>
> > +Required nodes:
> > +- any data bus to the connector should be modeled using the
> > + OF graph bindings specified in bindings/graph.txt.
> > + There should be exactly one port with at least one endpoint to
> > + different device nodes. The first endpoint (reg = <0>) should
> > + point to USB Interface Controller.
> > +
> > +Example
> > +-------
> > +
> > +musb_con: connector {
> > + compatible = "samsung,usb-connector-11pin", "usb-connector";
> > + label = "usb";
> > + type = "b";
> > + size = "micro";
> > + max-mode = "hs";
> > +
> > + port {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + musb_con_usb_in: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&muic_usb_out>;
> > + };
> > +
> > + musb_con_mhl_in: endpoint at 1 {
> > + reg = <1>;
> > + remote-endpoint = <&mhl_out>;
> > + };
> > + };
> > +};
One more comment, do I assume correctly that the Samsung 11-pin connector
carries USB and MHL on different pins ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-10-18 15:46 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170928130734eucas1p299c0e8135df3fb0484d72452cbd2ee47@eucas1p2.samsung.com>
2017-09-28 13:07 ` [RFC PATCH 0/4] dt-bindings: add bindings for USB physical connector Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` [RFC PATCH 1/4] " Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
[not found] ` <20170928130730.8747-2-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-10-05 23:12 ` Rob Herring
2017-10-05 23:12 ` Rob Herring
2017-10-05 23:12 ` Rob Herring
2017-10-06 11:10 ` Andrzej Hajda
2017-10-06 11:10 ` Andrzej Hajda
2017-10-06 11:10 ` Andrzej Hajda
2017-10-06 17:23 ` Rob Herring
2017-10-06 17:23 ` Rob Herring
2017-10-06 17:23 ` Rob Herring
2017-10-09 8:49 ` Andrzej Hajda
2017-10-09 8:49 ` Andrzej Hajda
2017-10-09 8:49 ` Andrzej Hajda
2017-10-18 15:11 ` Laurent Pinchart
2017-10-18 15:11 ` Laurent Pinchart
2017-10-18 15:11 ` Laurent Pinchart
2017-10-18 15:47 ` Laurent Pinchart [this message]
2017-10-18 15:47 ` Laurent Pinchart
2017-10-19 6:48 ` Andrzej Hajda
2017-10-19 6:48 ` Andrzej Hajda
2017-10-19 6:48 ` Andrzej Hajda
2017-09-28 13:07 ` [RFC PATCH 2/4] arm64: dts: exynos: add micro-USB connector node to TM2 platforms Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` [RFC PATCH 3/4] extcon: add possibility to get extcon device by of node Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
[not found] ` <20170928130730.8747-4-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-10-18 6:59 ` Chanwoo Choi
2017-10-18 6:59 ` Chanwoo Choi
2017-10-18 6:59 ` Chanwoo Choi
2017-09-28 13:07 ` [RFC PATCH 4/4] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
2017-09-28 13:07 ` Andrzej Hajda
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=2206421.ioyYkBuUpd@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=architt@codeaurora.org \
--cc=b.zolnierkie@samsung.com \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--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.