Message-ID: <20180208200415.fargr6l33ge7ap22@rob-hp-laptop>
Date:   Thu, 8 Feb 2018 14:04:15 -0600
From:   Rob Herring <robh@...nel.org>
To:     Andrzej Hajda <a.hajda@...sung.com>
Cc:     "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        dri-devel@...ts.freedesktop.org, Inki Dae <inki.dae@...sung.com>,
        Mark Rutland <mark.rutland@....com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Archit Taneja <architt@...eaurora.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical
 connector

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@...sung.com>
> >>>> ---
> >>>> 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@...sung.com>
> >>>> ---
> >>>>  .../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

Powered by blists - more mailing lists