Message ID | 20250507-batt_ops-v2-1-8d06130bffe6@google.com |
---|---|
State | New |
Headers | show |
Series | Add support for Battery Status & Battery Caps AMS in TCPM | expand |
On Wed, May 07, 2025 at 06:00:22PM -0700, Amit Sunil Dhamne wrote: > Extend ports property to model power lines going between connector to > charger or battery/batteries. As an example, connector VBUS can supply > power in & out of the battery for a DRP. > > Additionally, add ports property to maxim,max33359 controller example. > > Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> > --- > .../bindings/connector/usb-connector.yaml | 20 +++++++++++------ > .../devicetree/bindings/usb/maxim,max33359.yaml | 25 ++++++++++++++++++++++ > 2 files changed, 38 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml > index 11e40d225b9f3a0d0aeea7bf764f1c00a719d615..706094f890026d324e6ece8b0c1e831d04d51eb7 100644 > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml > @@ -181,16 +181,16 @@ properties: > > port: > $ref: /schemas/graph.yaml#/properties/port > - description: OF graph bindings modeling a data bus to the connector, e.g. > - there is a single High Speed (HS) port present in this connector. If there > - is more than one bus (several port, with 'reg' property), they can be grouped > - under 'ports'. > + description: OF graph binding to model a logical connection between a device > + and connector. This connection may represent a data bus or power line. For > + e.g. a High Speed (HS) data port present in this connector or VBUS line. > + If there is more than one connection (several port, with 'reg' property), > + they can be grouped under 'ports'. 'port' and 'port@0' are equivalent. So you can't be changing its definition. I'm not sure showing a power connection with the graph is the right approach. We have a binding for that already with the regulator binding. Perhaps the connector needs to be a supply. It's already using that binding in the supplying power to the connector case. Rob
Hi, On 5/20/25 1:10 PM, Amit Sunil Dhamne wrote: > Hi Rob, > > Thanks for your response! > > On 5/14/25 12:42 PM, Rob Herring wrote: >> On Wed, May 07, 2025 at 06:00:22PM -0700, Amit Sunil Dhamne wrote: >>> Extend ports property to model power lines going between connector to >>> charger or battery/batteries. As an example, connector VBUS can supply >>> power in & out of the battery for a DRP. >>> >>> Additionally, add ports property to maxim,max33359 controller example. >>> >>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> >>> --- >>> .../bindings/connector/usb-connector.yaml | 20 +++++++++++------ >>> .../devicetree/bindings/usb/maxim,max33359.yaml | 25 ++++++++++++++++++++++ >>> 2 files changed, 38 insertions(+), 7 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml >>> index 11e40d225b9f3a0d0aeea7bf764f1c00a719d615..706094f890026d324e6ece8b0c1e831d04d51eb7 100644 >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml >>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml >>> @@ -181,16 +181,16 @@ properties: >>> >>> port: >>> $ref: /schemas/graph.yaml#/properties/port >>> - description: OF graph bindings modeling a data bus to the connector, e.g. >>> - there is a single High Speed (HS) port present in this connector. If there >>> - is more than one bus (several port, with 'reg' property), they can be grouped >>> - under 'ports'. >>> + description: OF graph binding to model a logical connection between a device >>> + and connector. This connection may represent a data bus or power line. For >>> + e.g. a High Speed (HS) data port present in this connector or VBUS line. >>> + If there is more than one connection (several port, with 'reg' property), >>> + they can be grouped under 'ports'. >> 'port' and 'port@0' are equivalent. So you can't be changing its >> definition. > Noted! > > >> I'm not sure showing a power connection with the graph is the right >> approach. > I want to provide some more context and rationale behind using this design. > > From a hardware perspective: > > The max77759/max33359 IC has Type-C port controller, charger, fuel gauge > (FG) ICs. The Vbus from the connector goes to/from the TCPC and connects > with the charger IP via circuitry & from there on to the battery. The FG > is connected to the battery in parallel. As it can be seen that while > these IPs are interconnected, there's no direct connection of the fuel > gauge & the connector. > > For this feature, I am interested in getting the reference to the FG. As > per graph description: "...These common bindings do not contain any > information about the direction or type of the connections, they just > map their existence." This works for my case because I just want the > connector to be aware of the Fuel gauge device without imposing a > specific directionality in terms of power supplier/supplied. This is > also the reason why I didn't use > "/schemas/power/supply/power-supply.yaml#power-supplies" binding. > >> We have a binding for that already with the regulator binding. > I haven't explored the option of using regulator bindings. But in my > case I am interested in fuel gauge and unfortunately, they're modeled as > power_supply devices. > > >> >> Perhaps the connector needs to be a supply. It's already using that >> binding in the supplying power to the connector case. > Want to clarify, in this case you mean > /schemas/regulator/regulator.yaml#*-supply$ right? > > Adding to my response above, the reason I don't want to impose a > directionality in terms of supplier/supplied is that in case of USB Dual > Role Port they're dynamic i.e., when USB is source, the power is > supplied out of the battery (battery/FG will be supplier) and in case > USB is sink, battery is supplied power. Whether the connector port is in > source or sink role is determined on a connection to connection basis. > Also, the knowledge of the supply direction is of no consequence for > this feature. > > > Please let me know what you think. > > Thanks, > > Amit I wanted to follow up on my previous responses. Please let me know if you have any further questions or concerns. Thanks, Amit > >> Rob
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 11e40d225b9f3a0d0aeea7bf764f1c00a719d615..706094f890026d324e6ece8b0c1e831d04d51eb7 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -181,16 +181,16 @@ properties: port: $ref: /schemas/graph.yaml#/properties/port - description: OF graph bindings modeling a data bus to the connector, e.g. - there is a single High Speed (HS) port present in this connector. If there - is more than one bus (several port, with 'reg' property), they can be grouped - under 'ports'. + description: OF graph binding to model a logical connection between a device + and connector. This connection may represent a data bus or power line. For + e.g. a High Speed (HS) data port present in this connector or VBUS line. + If there is more than one connection (several port, with 'reg' property), + they can be grouped under 'ports'. ports: $ref: /schemas/graph.yaml#/properties/ports - description: OF graph bindings modeling any data bus to the connector - unless the bus is between parent node and the connector. Since a single - connector can have multiple data buses every bus has an assigned OF graph + description: OF graph bindings to model multiple "port". Since a connector + may have multiple logical connections each one has an assigned OF graph port number as described below. properties: @@ -207,6 +207,12 @@ properties: description: Sideband Use (SBU), present in USB-C. This describes the alternate mode connection of which SBU is a part. + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: VBUS/VCHGIN present in USB-C connector to model power line + going in and/or out of the charger/battery. If there are multiple + batteries then this port should contain those many endpoints. + required: - port@0 diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml index 3de4dc40b79192b60443421b557bd2fb18683bf7..730d5c1cc9ddf1ddeff055c00ee172745297633d 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml @@ -75,6 +75,31 @@ examples: PDO_FIXED(9000, 2000, 0)>; sink-bc12-completion-time-ms = <500>; pd-revision = /bits/ 8 <0x03 0x01 0x01 0x08>; + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + usbc0_orien_sw: endpoint { + remote-endpoint = <&usbdrd31_phy_orien_switch>; + }; + }; + + port@1 { + reg = <1>; + usbc0_role_sw: endpoint { + remote-endpoint = <&usbdrd31_dwc3_role_switch>; + }; + }; + + port@3 { + reg = <3>; + vbus_batt: endpoint { + remote-endpoint = <&max17201_fg>; + }; + }; + }; }; }; };