From: Andrzej Hajda <a.hajda@samsung.com>
To: Roger Quadros <rogerq@ti.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Cc: 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>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Date: Mon, 12 Mar 2018 08:02:54 +0100 [thread overview]
Message-ID: <b588527d-2ca2-9e88-9e27-e09e5b52f8d6@samsung.com> (raw)
In-Reply-To: <ed0ce43c-3c81-b027-2eb1-30e49156c3ac@ti.com>
On 09.03.2018 11:24, Roger Quadros wrote:
> Hi,
>
> On 27/02/18 09:11, Andrzej Hajda wrote:
>> These bindings allow 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>
>> ---
>> v4:
>> - improved 'type' description (Rob),
>> - improved description of 2nd example (Rob).
>> v3:
>> - removed MHL port (samsung connector will have separate bindings),
>> - added 2nd example for USB-C,
>> - improved formatting.
>> v2:
>> - moved connector type(A,B,C) to compatible string (Rob),
>> - renamed size property to type (Rob),
>> - changed type description to be less confusing (Laurent),
>> - removed vendor specific compatibles (implied by graph port number),
>> - added requirement of connector being a child of IC (Rob),
>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>> by USB Controller in runtime, downside is that device is not able to
>> report its real capabilities, maybe better would be to make it optional(?)),
>> - assigned port numbers to data buses (Rob).
>>
>> Regards
>> Andrzej
>> ---
>> .../bindings/connector/usb-connector.txt | 75 ++++++++++++++++++++++
>> 1 file changed, 75 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..e1463f14af38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,75 @@
>> +USB Connector
>> +=============
>> +
>> +USB connector node represents physical USB connector. It should be
>> +a child of USB interface controller.
>> +
>> +Required properties:
>> +- compatible: describes type of the connector, must be one of:
>> + "usb-a-connector",
>> + "usb-b-connector",
>> + "usb-c-connector".
> compatible should be just "usb-connector"
>
> Type should be a property
>
> type: type of usb connector "A", "B", "AB", "C"
> AB is for dual-role connectors.
I have proposed such property (and size also) in my first RFC [1]. Rod
did not like it :)
[1]: https://marc.info/?l=devicetree&m=150660411515233&w=2
>
> micro super-speed and high-speed connectors are different. How do you differentiate that?
I am aware of it, and property differentiating it was also in my earlier
iterations.
If there will be need to differentiate such connectors, adding property
max-speed or max-mode would do the thing.
>
>> +
>> +Optional properties:
>> +- label: symbolic name for the connector,
> Why do you need label? We can't maintain consistency as people will put creative names there.
> Device/bus driver could generate a valid label.
It follows convention for other connectors: HDMI, DVI, ....
>
>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>> + non-fullsize connectors: "mini", "micro".
> type is misleading. Type is usually A/B/C. It should be size here instead.
As you can see in discussion for previous iterations it follows
convention already established for other connectors.
>
> size: size of the connector if not standard size. "mini", "micro"
>
> If not specified it is treated as standard sized connector.
> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed
Few lines above it is described: should be specified in case of USB-A,
USB-B non-fullsize connectors.
>
> What about Type-C connector?
>> +
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the OF graph bindings
> s/modeled/modelled
>> + specified in bindings/graph.txt, unless the bus is between parent node and
>> + the connector. Since single connector can have multpile data buses every bus
> s/multpile/multiple
OK, I will fix both typos.
>
>> + has assigned OF graph port number as follows:
>> + 0: High Speed (HS), present in all connectors,
>> + 1: Super Speed (SS), present in SS capable connectors,
>> + 2: Sideband use (SBU), present in USB-C.
>> +
>> +Examples
>> +--------
>> +
>> +1. Micro-USB connector with HS lines routed via controller (MUIC):
>> +
>> +muic-max77843@66 {
>> + ...
>> + usb_con: connector {
>> + compatible = "usb-b-connector";
>> + label = "micro-USB";
>> + type = "micro";
>> + };
>> +};
>> +
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005@33 {
>> + ...
>> + usb_con: connector {
>> + compatible = "usb-c-connector";
>> + label = "USB-C";
> The label is not consistent with the earlier example.
Why?
Regards
Andrzej
>
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + usb_con_hs: endpoint {
>> + remote-endpoint = <&max77865_usbc_hs>;
>> + };
>> + };
>> + port@1 {
>> + reg = <1>;
>> + usb_con_ss: endpoint {
>> + remote-endpoint = <&usbdrd_phy_ss>;
>> + };
>> + };
>> + port@2 {
>> + reg = <2>;
>> + usb_con_sbu: endpoint {
>> + remote-endpoint = <&dp_aux>;
>> + };
>> + };
>> + };
>> + };
>> +};
>>
next prev parent reply other threads:[~2018-03-12 7:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180227071137eucas1p104aeeb0fd926fe985e250174d9d65b2e@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector Andrzej Hajda
[not found] ` <CGME20180227071138eucas1p17e1e16f13f6d3e3b15a57dc93eb8cf3f@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-02 13:13 ` Heikki Krogerus
2018-03-05 8:18 ` Andrzej Hajda
2018-03-05 10:27 ` Heikki Krogerus
2018-03-05 22:14 ` Rob Herring
2018-03-09 10:24 ` Roger Quadros
2018-03-12 7:02 ` Andrzej Hajda [this message]
2018-03-12 7:06 ` Andrzej Hajda
2018-03-12 10:41 ` Roger Quadros
2018-03-15 11:02 ` Andrzej Hajda
2018-03-15 11:46 ` Robin Murphy
2018-03-15 17:08 ` Roger Quadros
[not found] ` <CGME20180227071139eucas1p125ee35ada221fbed1dc85b7fc250f9ca@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector Andrzej Hajda
[not found] ` <CGME20180227071139eucas1p1d28b39a6636a7e6625aeb3a16091f81a@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms Andrzej Hajda
2018-03-06 16:49 ` Krzysztof Kozlowski
[not found] ` <CGME20180227071140eucas1p15a8b8443c6d52c5fab79cc82c37dce09@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector Andrzej Hajda
2018-03-06 16:49 ` Krzysztof Kozlowski
[not found] ` <CGME20180227071141eucas1p1170216070d70007a07de120a0dc3363a@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 5/6] extcon: add possibility to get extcon device by OF node Andrzej Hajda
2018-02-27 11:03 ` Chanwoo Choi
[not found] ` <CGME20180227122215eucas1p11a1a12c26665f032c666d10effaf15fc@eucas1p1.samsung.com>
2018-02-27 12:22 ` [PATCH v6 " Andrzej Hajda
[not found] ` <CGME20180227071142eucas1p10203dac2558db034a4a3287220213601@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL Andrzej Hajda
2018-02-27 11:08 ` Chanwoo Choi
2018-02-27 12:05 ` Andrzej Hajda
2018-02-27 22:26 ` Chanwoo Choi
2018-02-28 13:44 ` Andrzej Hajda
2018-03-02 0:29 ` Chanwoo Choi
2018-03-06 12:53 ` [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector Andrzej Hajda
2018-03-06 13:08 ` Krzysztof Kozlowski
2018-03-07 2:12 ` Chanwoo Choi
2018-03-07 4:48 ` Chanwoo Choi
2018-03-07 11:13 ` Andrzej Hajda
2018-03-07 11:22 ` Krzysztof Kozlowski
2018-03-07 11:40 ` Andrzej Hajda
2018-03-08 1:52 ` Chanwoo Choi
2018-03-09 9:20 ` Andrzej Hajda
2018-03-12 1:29 ` Chanwoo Choi
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=b588527d-2ca2-9e88-9e27-e09e5b52f8d6@samsung.com \
--to=a.hajda@samsung.com \
--cc=Laurent.pinchart@ideasonboard.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 \
--cc=rogerq@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).