On Thu, Feb 08, 2018 at 10:27:54AM +0100, Andrzej Hajda wrote:
> On 07.02.2018 22:43, Rob Herring wrote:
> > On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> >> On 05.02.2018 07:08, Rob Herring wrote:
> >>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, 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@xxxxxxxxxxx>
> >>>> ---
> >>>> 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),
> >>> How so? More below...
> >>>
> >>>> - 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
> >>>>
> >>>> Signed-off-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx>
> >>>> ---
> >>>> .../bindings/connector/usb-connector.txt | 48 ++++++++++++++++++++++
> >>>> 1 file changed, 48 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..02020f5d760a
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>>> @@ -0,0 +1,48 @@
> >>>> +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",
> >>> Nit: one per line.
> >>>
> >>>> +
> >>>> +Optional properties:
> >>>> +- label: symbolic name for the connector
> >>>> +- type: size of the connector, should be specified in case of USB-A, USB-B
> >>>> + non-standard (large) connector sizes: "mini", "micro"
> >>>> +
> >>>> +Required nodes:
> >>>> +- any data bus to the connector should be modeled using the OF graph bindings
> >>>> + 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
> >>>> + 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,
> >>>> + 3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB
> >>> This is un-muxed unlike Type-C where the signals are muxed with USB SS.
> >>> That makes me think the Samsung connector should have its own compatible
> >>> string.
> >> Do you mean, sth like:
> >> connector {
> >> compatible = "samsung,usb-connector-11pin";
> >> label = "micro-USB";
> >> ports {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >>
> >> port@3 {
> >> reg = <3>;
> >> musb_con_mhl_in: endpoint {
> >> remote-endpoint = <&mhl_out>;
> >> };
> >> };
> >> };
> > Yes, basically.
> >
> >> Or should I add "usb-b-connector" extra compatible and "type" property?
> > type would be micro? I think type and "usb-b-connector" are fine if this
> > is a superset like a USB3 SS micro connector.
> >
> >> I slightly prefer my approach(less different bindings), but I am also OK
> >> with the above.
> > How do you know it is a Samsung connector then? Just because you have
> > port 3? I think it is better to be explicit.
>
> OK.
>
> >
> >>> Can we go ahead and define the video modes of Type-C? Normally, if 2
> >>> data streams are mutually exclusive, then they are a single port with 2
> >>> endpoints. So we'd either have 2 endpoints on port 1 or we stick with
> >>> port 3 is always video. We can still know what is mutually exclusive
> >>> based on the compatible.
> >> I am sorry, I do not understand what you mean. Port 3 is present only in
> >> 11-pin Samsung micro-USB, USB Type-C has only ports 0, 1, 2.
> > So video on Type C would be on port 1 (SS), endpoint ? ? That's not
> > defined in the binding and I want to define it.
>
> USB type C does not have dedicated video lines, it has only: HS, SS, SBU
> (and optionally CC) data lines[1] and in my RFC I have modeled data
> lines as graph ports. If USB-C interface controller supports alternate
> mode (currently there are specs for DisplayPort, HDMI, MHL alternate
> modes, but there can be more), SS lines can be used to transmit video
> data (or any other type of data defined by alternate mode), but it means
> there will be SS mux somewhere before connector, for muxing USB-SS and
> alternate lines. So yes, video will be at port 1, but this is still port
> for SS lines:
Yes, I know all this.
>
> USB3 --> MUX --> CONNECTOR
> DP -------^
>
> I do not see why we would need separate video port.
Yes, agreed. I just want to define how we are supporting it. Otherwise,
someone may just think video is on port 3 for Type C too.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
