| 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 |
Hi Rob, On 5/7/25 7:08 PM, Rob Herring (Arm) wrote: > On Wed, 07 May 2025 18:00:22 -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(-) >> > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: I ran this and didn't see any errors on my side. > dtschema/dtc warnings/errors: > > > doc reference errors (make refcheckdocs): > > See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250507-batt_ops-v2-1-8d06130bffe6@google.com Even the build logs don't show any error log. > > The base for the series is generally the latest rc1. A different dependency > should be noted in *this* patch. My patchset is based on v6.14-rc6 and I tested it on that. > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit after running the above command yourself. Note > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > your schema. However, it must be unset to test all examples with your schema. > I did all of the above but make dt_binding_check still passes. (.venv) amitsd@amitsd-gti:~/linaro-p6-image/src/linux$ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/connector/usb-connector.yaml SCHEMA Documentation/devicetree/bindings/processed-schema.json /usr/local/google/home/amitsd/linaro-p6-image/src/linux/Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition ^ This is not newly introduced jfyi. CHKDT ./Documentation/devicetree/bindings LINT ./Documentation/devicetree/bindings DTEX Documentation/devicetree/bindings/connector/usb-connector.example.dts DTC [C] Documentation/devicetree/bindings/connector/usb-connector.example.dtb (.venv) amitsd@amitsd-gti:~/linaro-p6-image/src/linux$ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/usb/maxim,max33359.yaml CHKDT ./Documentation/devicetree/bindings LINT ./Documentation/devicetree/bindings DTEX Documentation/devicetree/bindings/usb/maxim,max33359.example.dts DTC [C] Documentation/devicetree/bindings/usb/maxim,max33359.example.dtb Please can you advise on what I may be missing? Thanks, Amit
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 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.
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>; + }; + }; + }; }; }; };