linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>;
>> +				};
>> +			};
>> +		};
>> +	};
>> +};
>>


  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).