Hi Rob,
On 08/06/2023 17:47, Rob Herring wrote:
On Wed, Jun 07, 2023 at 10:05:00AM +0200, Neil Armstrong wrote:
On some platforms, the Type-C plug orientation is given on a GPIO line.
Document this optional Type-C connector property, and take the
assumption an active level represents an inverted/flipped orientation.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
Signed-off-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
---
Documentation/devicetree/bindings/connector/usb-connector.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index ae515651fc6b..c3884eed6ba4 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -114,6 +114,11 @@ properties:
description: Set this property if the Type-C connector has no power delivery support.
type: boolean
+ orientation-gpios:
+ description: An input gpio for Type-C connector orientation, used to detect orientation
+ of the Type-C connector. GPIO active level means "CC2" or Reversed/Flipped orientation.
+ maxItems: 1
There's no such GPIO on a USB-C connector. Please explain this h/w
better (in the commit message and/or description). Perhaps it is simple
enough logic to leave the GPIO here. Perhaps there's more to the h/w you
are not (yet) describing.
The h/w has an I/O line representing the usb-c orientation at any time
which is driven by the PMIC in charge of the USB-C connector(s).
On this platform, the usb-c connector orientation is only unconditionally
given by this I/O connected to a GPIO line, howerver we get an altmode
event with the orientation, but only when an altmode state has been
negociated. AFAIK there's no other way or events returning this
orientation change unconditionally unlike previous HW generations.
This is why representing it as a gpio is simple but useful since there's
a lot of passive usb-c controllers also reflecting this orientation info
in a same way to be consumed by superspeed switches for example.
As an alternative I didn't find a way that fits the current bindings
to get this simple binary information.
Neil
Rob
