Allow specifying data-lanes to reverse the SBU muxing orientation where
necessary by the hardware design.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
.../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 +++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
index f6e7a5c1ff0b..86f6d633c2fb 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
+++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
@@ -32,10 +32,37 @@ properties:
type: boolean
port:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
description:
A port node to link the FSA4480 to a TypeC controller for the purpose of
handling altmode muxing and orientation switching.
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Specifies how the AUX+/- lines are connected to SBU1/2.
+ oneOf:
+ - items:
+ - const: 0
+ - const: 1
+ description: |
+ Default AUX/SBU layout
+ - AUX+ connected to SBU2
+ - AUX- connected to SBU1
+ - items:
+ - const: 1
+ - const: 0
+ description: |
+ Swapped AUX/SBU layout
+ - AUX+ connected to SBU1
+ - AUX- connected to SBU2
required:
- compatible
--
2.42.0
On Fri, Oct 13, 2023 at 01:38:05PM +0200, Luca Weiss wrote: > Allow specifying data-lanes to reverse the SBU muxing orientation where > necessary by the hardware design. What situation in the hardware design makes this necessary. Please describe the problem. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 +++++++++++++++++++++- > 1 file changed, 28 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > index f6e7a5c1ff0b..86f6d633c2fb 100644 > --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > @@ -32,10 +32,37 @@ properties: > type: boolean > > port: > - $ref: /schemas/graph.yaml#/properties/port > + $ref: /schemas/graph.yaml#/$defs/port-base > description: > A port node to link the FSA4480 to a TypeC controller for the purpose of > handling altmode muxing and orientation switching. > + unevaluatedProperties: false > + > + properties: > + endpoint: > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > + unevaluatedProperties: false > + > + properties: > + data-lanes: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > + Specifies how the AUX+/- lines are connected to SBU1/2. Doesn't this depend on the connector orientation? Or it is both that and the lines can be swapped on the PCB? Seems like an abuse of data-lanes which already has a definition which is not about swapping + and - differential lanes. Rob
On 16/10/2023 16:22, Rob Herring wrote:
> On Fri, Oct 13, 2023 at 01:38:05PM +0200, Luca Weiss wrote:
>> Allow specifying data-lanes to reverse the SBU muxing orientation where
>> necessary by the hardware design.
>
> What situation in the hardware design makes this necessary. Please
> describe the problem.
>
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 +++++++++++++++++++++-
>> 1 file changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
>> index f6e7a5c1ff0b..86f6d633c2fb 100644
>> --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
>> +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
>> @@ -32,10 +32,37 @@ properties:
>> type: boolean
>>
>> port:
>> - $ref: /schemas/graph.yaml#/properties/port
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> description:
>> A port node to link the FSA4480 to a TypeC controller for the purpose of
>> handling altmode muxing and orientation switching.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + data-lanes:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + description:
>> + Specifies how the AUX+/- lines are connected to SBU1/2.
>
> Doesn't this depend on the connector orientation? Or it is both that and
> the lines can be swapped on the PCB?
>
> Seems like an abuse of data-lanes which already has a definition which
> is not about swapping + and - differential lanes.
The FSA acts as a mux between DP AUX, Audio lanes on one side and
the USB-C SBU lanes on the other side.
_______ ______
| | |
|-- HP --| |
|-- MIC --| |or
SoC | | MUX |-- SBU1 ---> To the USB-C
Codec |-- AUX+ --| |-- SBU2 ---> connected
|-- AUX- --| |
______| |____ |
The SBU1 & SBU2 are connected to the USB-C connector, and the actual orientation
to the connected devices/cable/whatever is determined by the TPCM and the MUX in
the FSA4480 with be dynamically changed according to the CC1/CC2 detection and PD alt mode.
But on the other side the orientation of the AUX+/AUX- connected to the SoC
is not tied to the USB-C orientation but how it's routed on the PCB.
This describes how the AUX+/AUX- are physically routed to the FSA4480 chip.
Neil
>
> Rob
On Mon, Oct 16, 2023 at 04:32:55PM +0200, Neil Armstrong wrote: > On 16/10/2023 16:22, Rob Herring wrote: > > On Fri, Oct 13, 2023 at 01:38:05PM +0200, Luca Weiss wrote: > > > Allow specifying data-lanes to reverse the SBU muxing orientation where > > > necessary by the hardware design. > > > > What situation in the hardware design makes this necessary. Please > > describe the problem. > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > --- > > > .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 +++++++++++++++++++++- > > > 1 file changed, 28 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > index f6e7a5c1ff0b..86f6d633c2fb 100644 > > > --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > @@ -32,10 +32,37 @@ properties: > > > type: boolean > > > port: > > > - $ref: /schemas/graph.yaml#/properties/port > > > + $ref: /schemas/graph.yaml#/$defs/port-base > > > description: > > > A port node to link the FSA4480 to a TypeC controller for the purpose of > > > handling altmode muxing and orientation switching. > > > + unevaluatedProperties: false > > > + > > > + properties: > > > + endpoint: > > > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > > > + unevaluatedProperties: false > > > + > > > + properties: > > > + data-lanes: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: > > > + Specifies how the AUX+/- lines are connected to SBU1/2. > > > > Doesn't this depend on the connector orientation? Or it is both that and > > the lines can be swapped on the PCB? > > > > Seems like an abuse of data-lanes which already has a definition which > > is not about swapping + and - differential lanes. > > The FSA acts as a mux between DP AUX, Audio lanes on one side and > the USB-C SBU lanes on the other side. > _______ ______ > | | | > |-- HP --| | > |-- MIC --| |or > SoC | | MUX |-- SBU1 ---> To the USB-C > Codec |-- AUX+ --| |-- SBU2 ---> connected > |-- AUX- --| | > ______| |____ | > > The SBU1 & SBU2 are connected to the USB-C connector, and the actual orientation > to the connected devices/cable/whatever is determined by the TPCM and the MUX in > the FSA4480 with be dynamically changed according to the CC1/CC2 detection and PD alt mode. > > But on the other side the orientation of the AUX+/AUX- connected to the SoC > is not tied to the USB-C orientation but how it's routed on the PCB. > > This describes how the AUX+/AUX- are physically routed to the FSA4480 chip. I'd hate for this ASCII art to go to waste. Please add this detail to the commit message. Rob
© 2016 - 2025 Red Hat, Inc.