* [RFC PATCH v2 0/5] dt-bindings: add bindings for USB physical connector [not found] <CGME20180131134456eucas1p2543fb6c96a29c57e991f5de1a4ef89fe@eucas1p2.samsung.com> @ 2018-01-31 13:44 ` Andrzej Hajda [not found] ` <CGME20180131134457eucas1p128394aef86e0d76cfc6ccb72ee22d4b1@eucas1p1.samsung.com> ` (4 more replies) 0 siblings, 5 replies; 11+ messages in thread From: Andrzej Hajda @ 2018-01-31 13:44 UTC (permalink / raw) To: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae, Rob Herring, Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Archit Taneja, Laurent Pinchart, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA Hi, This patchset introduces USB physical connector bindings, together with working example. I have added comments in relevant patches to describe possible issues. In v2 I have addressed comments by Rob and Laurent, thanks Changes are described in patches. Regards Andrzej Andrzej Hajda (4): dt-bindings: add bindings for USB physical connector arm64: dts: exynos: add micro-USB connector node to TM2 platforms arm64: dts: exynos: add OF graph between MHL and USB connector extcon: add possibility to get extcon device by OF node Maciej Purski (1): drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL .../bindings/connector/usb-connector.txt | 48 +++++++++++ .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 37 ++++++++- drivers/extcon/extcon.c | 44 +++++++--- drivers/gpu/drm/bridge/sil-sii8620.c | 97 +++++++++++++++++++++- include/linux/extcon.h | 6 ++ 5 files changed, 216 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/connector/usb-connector.txt -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CGME20180131134457eucas1p128394aef86e0d76cfc6ccb72ee22d4b1@eucas1p1.samsung.com>]
* [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector [not found] ` <CGME20180131134457eucas1p128394aef86e0d76cfc6ccb72ee22d4b1@eucas1p1.samsung.com> @ 2018-01-31 13:44 ` Andrzej Hajda 2018-02-05 6:08 ` Rob Herring 0 siblings, 1 reply; 11+ messages in thread From: Andrzej Hajda @ 2018-01-31 13:44 UTC (permalink / raw) To: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS Cc: Mark Rutland, linux-samsung-soc, Laurent Pinchart, Chanwoo Choi, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski 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> --- 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 Signed-off-by: Andrzej Hajda <a.hajda@samsung.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", + +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 + +Example +------- + +muic_max77843@66 { + ... + musb_con: connector { + compatible = "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@3 { + reg = <3>; + musb_con_mhl_in: endpoint { + remote-endpoint = <&mhl_out>; + }; + }; + }; + }; +}; -- 2.15.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector 2018-01-31 13:44 ` [RFC PATCH v2 1/5] " Andrzej Hajda @ 2018-02-05 6:08 ` Rob Herring 2018-02-05 9:06 ` Andrzej Hajda 0 siblings, 1 reply; 11+ messages in thread From: Rob Herring @ 2018-02-05 6:08 UTC (permalink / raw) To: Andrzej Hajda Cc: Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Archit Taneja, linux-samsung-soc, Laurent Pinchart, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Inki Dae, Chanwoo Choi, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski 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@samsung.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@samsung.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. 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. > + > +Example > +------- > + > +muic_max77843@66 { > + ... > + musb_con: connector { > + compatible = "usb-b-connector"; > + label = "micro-USB"; > + type = "micro"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@3 { > + reg = <3>; > + musb_con_mhl_in: endpoint { > + remote-endpoint = <&mhl_out>; > + }; > + }; > + }; > + }; > +}; > -- > 2.15.1 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector 2018-02-05 6:08 ` Rob Herring @ 2018-02-05 9:06 ` Andrzej Hajda [not found] ` <a9745020-602b-8274-e2d6-63295f5b3caa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Andrzej Hajda @ 2018-02-05 9:06 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-samsung-soc, Laurent Pinchart, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Chanwoo Choi, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski 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@samsung.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@samsung.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>; }; }; }; Or should I add "usb-b-connector" extra compatible and "type" property? I slightly prefer my approach(less different bindings), but I am also OK with the above. > > 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. Here is list of possible ports depending on connector type: - USB 2.0: HS - 11-pin Samsung micro-USB: HS,MHL - USB 3.x type A,B: HS,SS - USB-C: HS,SS,SBU All ports have separate lines, so they can work simultaneously. And regarding MHL on standard micro-USB connector. MHL and MUIC will share HS port, but there will be mux somewhere before connector: - in MUIC, in this case MUIC will be the parent of the connector, and there will be graph from MHL to MUIC to describe MHL link, - in MHL, in this case MHL will be the parent of the connector, and graph between MUIC and MHL to describe HS link, - dedicated mux to MUIC and MHL, controlled by gpio pin, it could be handled by MUIC's external-mux gpio property for example, or (probably) less hacky by separate node for mux, or as additional property in the connector (who should be the parent of the connector then? Probably MUIC?). Regards Andrzej > >> + >> +Example >> +------- >> + >> +muic_max77843@66 { >> + ... >> + musb_con: connector { >> + compatible = "usb-b-connector"; >> + label = "micro-USB"; >> + type = "micro"; >> + >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@3 { >> + reg = <3>; >> + musb_con_mhl_in: endpoint { >> + remote-endpoint = <&mhl_out>; >> + }; >> + }; >> + }; >> + }; >> +}; >> -- >> 2.15.1 >> > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <a9745020-602b-8274-e2d6-63295f5b3caa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]
* Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector [not found] ` <a9745020-602b-8274-e2d6-63295f5b3caa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> @ 2018-02-07 21:43 ` Rob Herring 2018-02-08 9:27 ` Andrzej Hajda 0 siblings, 1 reply; 11+ messages in thread From: Rob Herring @ 2018-02-07 21:43 UTC (permalink / raw) To: Andrzej Hajda Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Bartlomiej Zolnierkiewicz, Marek Szyprowski, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae, Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Archit Taneja, Laurent Pinchart, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA 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-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> > >> --- > >> 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-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> > >> --- > >> .../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. > > > > > 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. > Here is list of possible ports depending on connector type: > - USB 2.0: HS > - 11-pin Samsung micro-USB: HS,MHL > - USB 3.x type A,B: HS,SS > - USB-C: HS,SS,SBU > > All ports have separate lines, so they can work simultaneously. > > And regarding MHL on standard micro-USB connector. MHL and MUIC will > share HS port, but there will be mux somewhere before connector: That's another case I hadn't considered. I was mainly thinking just how to handle Type C. > - in MUIC, in this case MUIC will be the parent of the connector, and > there will be graph from MHL to MUIC to describe MHL link, > - in MHL, in this case MHL will be the parent of the connector, and > graph between MUIC and MHL to describe HS link, > - dedicated mux to MUIC and MHL, controlled by gpio pin, it could be > handled by MUIC's external-mux gpio property for example, or (probably) > less hacky by separate node for mux, > or as additional property in the connector (who should be the parent of > the connector then? Probably MUIC?). > > Regards > Andrzej -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector 2018-02-07 21:43 ` Rob Herring @ 2018-02-08 9:27 ` Andrzej Hajda 2018-02-08 20:04 ` Rob Herring 0 siblings, 1 reply; 11+ messages in thread From: Andrzej Hajda @ 2018-02-08 9:27 UTC (permalink / raw) To: Rob Herring Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Bartlomiej Zolnierkiewicz, Marek Szyprowski, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae, Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Archit Taneja, Laurent Pinchart, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA 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-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> >>>> --- >>>> 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-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> >>>> --- >>>> .../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: USB3 --> MUX --> CONNECTOR DP -------^ I do not see why we would need separate video port. [1]: https://en.wikipedia.org/wiki/USB-C#Cable_wiring Regards Andrzej >> Here is list of possible ports depending on connector type: >> - USB 2.0: HS >> - 11-pin Samsung micro-USB: HS,MHL >> - USB 3.x type A,B: HS,SS >> - USB-C: HS,SS,SBU >> >> All ports have separate lines, so they can work simultaneously. >> >> And regarding MHL on standard micro-USB connector. MHL and MUIC will >> share HS port, but there will be mux somewhere before connector: > That's another case I hadn't considered. I was mainly thinking just how > to handle Type C. > >> - in MUIC, in this case MUIC will be the parent of the connector, and >> there will be graph from MHL to MUIC to describe MHL link, >> - in MHL, in this case MHL will be the parent of the connector, and >> graph between MUIC and MHL to describe HS link, >> - dedicated mux to MUIC and MHL, controlled by gpio pin, it could be >> handled by MUIC's external-mux gpio property for example, or (probably) >> less hacky by separate node for mux, >> or as additional property in the connector (who should be the parent of >> the connector then? Probably MUIC?). >> >> Regards >> Andrzej > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector 2018-02-08 9:27 ` Andrzej Hajda @ 2018-02-08 20:04 ` Rob Herring 0 siblings, 0 replies; 11+ messages in thread From: Rob Herring @ 2018-02-08 20:04 UTC (permalink / raw) To: Andrzej Hajda Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Bartlomiej Zolnierkiewicz, Marek Szyprowski, dri-devel, Inki Dae, Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Archit Taneja, Laurent Pinchart, linux-kernel, linux-arm-kernel, linux-samsung-soc, linux-usb 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@samsung.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@samsung.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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CGME20180131134458eucas1p1f611f9e3345b9e3bd5b18b6d57ff21f1@eucas1p1.samsung.com>]
* [RFC PATCH v2 2/5] arm64: dts: exynos: add micro-USB connector node to TM2 platforms [not found] ` <CGME20180131134458eucas1p1f611f9e3345b9e3bd5b18b6d57ff21f1@eucas1p1.samsung.com> @ 2018-01-31 13:44 ` Andrzej Hajda 0 siblings, 0 replies; 11+ messages in thread From: Andrzej Hajda @ 2018-01-31 13:44 UTC (permalink / raw) To: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS Cc: Mark Rutland, linux-samsung-soc, Laurent Pinchart, Chanwoo Choi, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski Since USB connector bindings are available we can describe it on TM2(e). Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi index a1e93d91a3ed..e5a6a2303060 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi @@ -798,6 +798,12 @@ muic: max77843-muic { compatible = "maxim,max77843-muic"; + + musb_con: musb_connector { + compatible = "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + }; }; regulators { -- 2.15.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 11+ messages in thread
[parent not found: <CGME20180131134458eucas1p15d3eaae8dce09aa348e9458840c2ea20@eucas1p1.samsung.com>]
* [RFC PATCH v2 3/5] arm64: dts: exynos: add OF graph between MHL and USB connector [not found] ` <CGME20180131134458eucas1p15d3eaae8dce09aa348e9458840c2ea20@eucas1p1.samsung.com> @ 2018-01-31 13:44 ` Andrzej Hajda 0 siblings, 0 replies; 11+ messages in thread From: Andrzej Hajda @ 2018-01-31 13:44 UTC (permalink / raw) To: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS Cc: Mark Rutland, linux-samsung-soc, Laurent Pinchart, Chanwoo Choi, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski OF graph describes MHL data lanes between MHL and respective USB connector. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> --- .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi index e5a6a2303060..427ff861b441 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi @@ -779,9 +779,22 @@ clocks = <&pmu_system_controller 0>; clock-names = "xtal"; - port { - mhl_to_hdmi: endpoint { - remote-endpoint = <&hdmi_to_mhl>; + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mhl_to_hdmi: endpoint { + remote-endpoint = <&hdmi_to_mhl>; + }; + }; + + port@1 { + reg = <1>; + mhl_to_musb_con: endpoint { + remote-endpoint = <&musb_con_to_mhl>; + }; }; }; }; @@ -803,6 +816,18 @@ compatible = "usb-b-connector"; label = "micro-USB"; type = "micro"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@3 { + musb_con_to_mhl: endpoint { + remote-endpoint = <&mhl_to_musb_con>; + }; + }; + }; + }; }; }; -- 2.15.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 11+ messages in thread
[parent not found: <CGME20180131134459eucas1p15c0dd76f5173816b949e72cde93c0a6c@eucas1p1.samsung.com>]
* [RFC PATCH v2 4/5] extcon: add possibility to get extcon device by OF node [not found] ` <CGME20180131134459eucas1p15c0dd76f5173816b949e72cde93c0a6c@eucas1p1.samsung.com> @ 2018-01-31 13:44 ` Andrzej Hajda 0 siblings, 0 replies; 11+ messages in thread From: Andrzej Hajda @ 2018-01-31 13:44 UTC (permalink / raw) To: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS Cc: Mark Rutland, linux-samsung-soc, Laurent Pinchart, Chanwoo Choi, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski Since extcon property is not allowed in DT, extcon subsystem requires another way to get extcon device. Lets try the simplest approach - get edev by of_node. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> --- v2: changed label to follow local convention (Chanwoo) --- drivers/extcon/extcon.c | 44 ++++++++++++++++++++++++++++++++++---------- include/linux/extcon.h | 6 ++++++ 2 files changed, 40 insertions(+), 10 deletions(-) diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index cb38c2747684..c4972c4cb3bd 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev) EXPORT_SYMBOL_GPL(extcon_dev_unregister); #ifdef CONFIG_OF + +/* + * extcon_get_edev_by_of_node - Get the extcon device from devicetree. + * @node : OF node identyfying edev + * + * Return the pointer of extcon device if success or ERR_PTR(err) if fail. + */ +struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node) +{ + struct extcon_dev *edev; + + mutex_lock(&extcon_dev_list_lock); + list_for_each_entry(edev, &extcon_dev_list, entry) + if (edev->dev.parent && edev->dev.parent->of_node == node) + goto out; + edev = ERR_PTR(-EPROBE_DEFER); +out: + mutex_unlock(&extcon_dev_list_lock); + + return edev; +} + /* * extcon_get_edev_by_phandle - Get the extcon device from devicetree. * @dev : the instance to the given device @@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index) return ERR_PTR(-ENODEV); } - mutex_lock(&extcon_dev_list_lock); - list_for_each_entry(edev, &extcon_dev_list, entry) { - if (edev->dev.parent && edev->dev.parent->of_node == node) { - mutex_unlock(&extcon_dev_list_lock); - of_node_put(node); - return edev; - } - } - mutex_unlock(&extcon_dev_list_lock); + edev = extcon_get_edev_by_of_node(node); of_node_put(node); - return ERR_PTR(-EPROBE_DEFER); + return edev; } + #else + +struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node) +{ + return ERR_PTR(-ENOSYS); +} + struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index) { return ERR_PTR(-ENOSYS); } + #endif /* CONFIG_OF */ + +EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node); EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle); /** diff --git a/include/linux/extcon.h b/include/linux/extcon.h index 6d94e82c8ad9..b47e0c7f01fe 100644 --- a/include/linux/extcon.h +++ b/include/linux/extcon.h @@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct device *dev, * Following APIs get the extcon_dev from devicetree or by through extcon name. */ extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name); +extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node); extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index); @@ -283,6 +284,11 @@ static inline struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name) return ERR_PTR(-ENODEV); } +static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node) +{ + return ERR_PTR(-ENODEV); +} + static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index) { -- 2.15.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 11+ messages in thread
[parent not found: <CGME20180131134500eucas1p1bb313876bc8ea81a46113f29c1d4ce54@eucas1p1.samsung.com>]
* [RFC PATCH v2 5/5] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL [not found] ` <CGME20180131134500eucas1p1bb313876bc8ea81a46113f29c1d4ce54@eucas1p1.samsung.com> @ 2018-01-31 13:44 ` Andrzej Hajda 0 siblings, 0 replies; 11+ messages in thread From: Andrzej Hajda @ 2018-01-31 13:44 UTC (permalink / raw) To: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS Cc: Mark Rutland, linux-samsung-soc, Laurent Pinchart, Chanwoo Choi, Bartlomiej Zolnierkiewicz, linux-usb, linux-kernel, dri-devel, Maciej Purski, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, Marek Szyprowski From: Maciej Purski <m.purski@samsung.com> Currently MHL chip must be turned on permanently to detect MHL cable. It duplicates micro-USB controller's (MUIC) functionality and consumes unnecessary power. Lets use extcon attached to MUIC to enable MHL chip only if it detects MHL cable. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> --- This is rework of the patch by Maciej with following changes: - use micro-USB port bindings to get extcon, instead of extcon property, - fixed remove sequence, - fixed extcon get state logic. Code finding extcon node is hacky IMO, I guess ultimately it should be done via some framework (maybe even extcon), or at least via helper, I hope it can stay as is until the proper solution will be merged. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> --- drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++++++++++++++++++++++++++++++++++-- 1 file changed, 94 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c index 9e785b8e0ea2..565cc352ca81 100644 --- a/drivers/gpu/drm/bridge/sil-sii8620.c +++ b/drivers/gpu/drm/bridge/sil-sii8620.c @@ -17,6 +17,7 @@ #include <linux/clk.h> #include <linux/delay.h> +#include <linux/extcon.h> #include <linux/gpio/consumer.h> #include <linux/i2c.h> #include <linux/interrupt.h> @@ -25,6 +26,7 @@ #include <linux/list.h> #include <linux/module.h> #include <linux/mutex.h> +#include <linux/of_graph.h> #include <linux/regulator/consumer.h> #include <linux/slab.h> @@ -81,6 +83,10 @@ struct sii8620 { struct edid *edid; unsigned int gen2_write_burst:1; enum sii8620_mt_state mt_state; + struct extcon_dev *extcon; + struct notifier_block extcon_nb; + struct work_struct extcon_wq; + int cable_state; struct list_head mt_queue; struct { int r_size; @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 *ctx) ctx->rc_dev = rc_dev; } +static void sii8620_cable_out(struct sii8620 *ctx) +{ + disable_irq(to_i2c_client(ctx->dev)->irq); + sii8620_hw_off(ctx); +} + +static void sii8620_extcon_work(struct work_struct *work) +{ + struct sii8620 *ctx = + container_of(work, struct sii8620, extcon_wq); + int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL); + + if (state == ctx->cable_state) + return; + + ctx->cable_state = state; + + if (state > 0) + sii8620_cable_in(ctx); + else + sii8620_cable_out(ctx); +} + +static int sii8620_extcon_notifier(struct notifier_block *self, + unsigned long event, void *ptr) +{ + struct sii8620 *ctx = + container_of(self, struct sii8620, extcon_nb); + + schedule_work(&ctx->extcon_wq); + + return NOTIFY_DONE; +} + +static int sii8620_extcon_init(struct sii8620 *ctx) +{ + struct extcon_dev *edev; + struct device_node *musb, *muic; + int ret; + + /* get micro-USB connector node */ + musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1); + /* next get micro-USB Interface Controller node */ + muic = of_get_next_parent(musb); + + if (!muic) { + dev_info(ctx->dev, "no extcon found, switching to 'always on' mode\n"); + return 0; + } + + edev = extcon_get_edev_by_of_node(muic); + of_node_put(muic); + if (IS_ERR(edev)) { + if (PTR_ERR(edev) == -EPROBE_DEFER) + return -EPROBE_DEFER; + dev_err(ctx->dev, "Invalid or missing extcon\n"); + return PTR_ERR(edev); + } + + ctx->extcon = edev; + ctx->extcon_nb.notifier_call = sii8620_extcon_notifier; + INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work); + ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb); + if (ret) { + dev_err(ctx->dev, "failed to register notifier for MHL\n"); + return ret; + } + + return 0; +} + static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge) { return container_of(bridge, struct sii8620, bridge); @@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client, if (ret) return ret; + ret = sii8620_extcon_init(ctx); + if (ret < 0) { + dev_err(ctx->dev, "failed to initialize EXTCON\n"); + return ret; + } + i2c_set_clientdata(client, ctx); ctx->bridge.funcs = &sii8620_bridge_funcs; ctx->bridge.of_node = dev->of_node; drm_bridge_add(&ctx->bridge); - sii8620_cable_in(ctx); + if (!ctx->extcon) + sii8620_cable_in(ctx); return 0; } @@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client) { struct sii8620 *ctx = i2c_get_clientdata(client); - disable_irq(to_i2c_client(ctx->dev)->irq); - sii8620_hw_off(ctx); + if (ctx->extcon) { + extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL, + &ctx->extcon_nb); + flush_work(&ctx->extcon_wq); + if (ctx->cable_state > 0) + sii8620_cable_out(ctx); + } else { + sii8620_cable_out(ctx); + } drm_bridge_remove(&ctx->bridge); return 0; -- 2.15.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-02-08 20:04 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20180131134456eucas1p2543fb6c96a29c57e991f5de1a4ef89fe@eucas1p2.samsung.com> 2018-01-31 13:44 ` [RFC PATCH v2 0/5] dt-bindings: add bindings for USB physical connector Andrzej Hajda [not found] ` <CGME20180131134457eucas1p128394aef86e0d76cfc6ccb72ee22d4b1@eucas1p1.samsung.com> 2018-01-31 13:44 ` [RFC PATCH v2 1/5] " Andrzej Hajda 2018-02-05 6:08 ` Rob Herring 2018-02-05 9:06 ` Andrzej Hajda [not found] ` <a9745020-602b-8274-e2d6-63295f5b3caa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2018-02-07 21:43 ` Rob Herring 2018-02-08 9:27 ` Andrzej Hajda 2018-02-08 20:04 ` Rob Herring [not found] ` <CGME20180131134458eucas1p1f611f9e3345b9e3bd5b18b6d57ff21f1@eucas1p1.samsung.com> 2018-01-31 13:44 ` [RFC PATCH v2 2/5] arm64: dts: exynos: add micro-USB connector node to TM2 platforms Andrzej Hajda [not found] ` <CGME20180131134458eucas1p15d3eaae8dce09aa348e9458840c2ea20@eucas1p1.samsung.com> 2018-01-31 13:44 ` [RFC PATCH v2 3/5] arm64: dts: exynos: add OF graph between MHL and USB connector Andrzej Hajda [not found] ` <CGME20180131134459eucas1p15c0dd76f5173816b949e72cde93c0a6c@eucas1p1.samsung.com> 2018-01-31 13:44 ` [RFC PATCH v2 4/5] extcon: add possibility to get extcon device by OF node Andrzej Hajda [not found] ` <CGME20180131134500eucas1p1bb313876bc8ea81a46113f29c1d4ce54@eucas1p1.samsung.com> 2018-01-31 13:44 ` [RFC PATCH v2 5/5] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL Andrzej Hajda
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).