Thread (18 messages) 18 messages, 4 authors, 2020-11-06

Re: [RESEND PATCH v3 1/4] dt-bindings: connector: add power-opmode optional property to usb-connector

From: Amelie DELAUNAY <hidden>
Date: 2020-11-06 08:04:09
Also in: linux-arm-kernel, linux-usb, lkml

Hi Badhri,

On 11/6/20 4:10 AM, Badhri Jagan Sridharan wrote:
Hi Rob and Amelie,

With regards to discussions in this thread,
For https://lore.kernel.org/r/20201020093627.256885-2-badhri@google.com (local),
I can send in a patch to update the new-source-frs-typec-current property.
Amelie, If you are already planning to send that I am fine with that as well.
Let me know !

To summarize the changes for new-source-frs-typec-current would be,
1. Rename to frs-new-source-opmode
2. Use string values instead of u32 similar to typec-power-opmode.
Are these correct ?

You can send patches to rename the new-source-frq-typec-current property 
into frs-new-source-opmode, and update the tcpm as well. You can use the 
typec_find_pwr_opmode(), it will return
enum typec_pwr_opmode {
	TYPEC_PWR_MODE_USB,
	TYPEC_PWR_MODE_1_5A,
	TYPEC_PWR_MODE_3_0A,
	TYPEC_PWR_MODE_PD,
};
Then you have to translate it for FRS.

I'll send a new version of my series to document typec-power-opmode and 
update stusb160x driver and stm32mp15xx-dkx device tree accordingly.

Thanks,
Amelie
Thanks,
Badhri

On Thu, Nov 5, 2020 at 7:55 AM Rob Herring [off-list ref] wrote:
quoted
On Thu, Nov 5, 2020 at 6:24 AM Jun Li [off-list ref] wrote:
quoted
Amelie DELAUNAY [off-list ref] 于2020年11月5日周四 下午7:36写道:
quoted
On 11/4/20 10:08 PM, Rob Herring wrote:
quoted
On Fri, Oct 30, 2020 at 04:27:14PM +0100, Amelie DELAUNAY wrote:
quoted

On 10/30/20 3:29 PM, Rob Herring wrote:
quoted
On Thu, Oct 29, 2020 at 11:49 AM Amelie DELAUNAY [off-list ref] wrote:
quoted


On 10/29/20 4:40 PM, Rob Herring wrote:
quoted
On Thu, Oct 29, 2020 at 10:58:03AM +0100, Amelie Delaunay wrote:
quoted
Power operation mode may depends on hardware design, so, add the optional
property power-opmode for usb-c connector to select the power operation
mode capability.

Signed-off-by: Amelie Delaunay <redacted>
---
     .../bindings/connector/usb-connector.yaml      | 18 ++++++++++++++++++
     1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 728f82db073d..200d19c60fd5 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -93,6 +93,24 @@ properties:
           - device
           - dual

+  power-opmode:
I've acked this version:

https://lore.kernel.org/r/20201020093627.256885-2-badhri@google.com (local)
frs is used for Fast Role Swap defined in USB PD spec.
I understand it allows to get the same information but I'm wondering why
the property name is limited to -frs- in this case. What about a
non-power delivery USB-C connector ?
I've got no idea. The folks that know USB-C and PD details need to get
together and work all this out. To me, it looks like the same thing...
It looks but...

The purpose of power-opmode property is to configure the USB-C controllers,
especially the non-PD USB-C controllers to determine the power operation
mode that the Type C connector will support and will advertise through CC
pins when it has no power delivery support, whatever the power role: Sink,
Source or Dual
The management of the property is the same that data-role and power-role
properties, and done by USB Type-C Connector Class.

new-source-frs-typec-current specifies initial current capability of the new
source when vSafe5V is applied during PD3.0 Fast Role Swap. So here, this
property is not applied at usb-c controller configuration level, but during
PD Fast Role Swap, so when the Sink become the Source.
Moreover, the related driver code says FRS can only be supported by DRP
ports. So new-source-frs-typec-current property, in addition to being
specific to PD, is also dedicated to DRP usb-c controller.
The property is managed by Type-C Port Controller Manager for PD.
But it's the same set of possible values, right? So we can align the
values at least.
USB Power Delivery FRS values are defined in
include/dt-bindings/usb/pd.h
I think this can be changed if both can be aligned.
quoted
to fit with drivers/usb/typec/tcpm/tcpm.c
frs_typec_current enum.

USB-C power operation mode values are defined in
include/linux/usb/typec.h with typec_pwr_opmode enum and matching with
string values of typec_pwr_opmodes tab.

USB PD requires USB-C.
USB-C doesn't requires USB PD.

drivers/usb/typec/tcpm/tcpm.c already used typec_pwr_opmode values.

USB PD specification Table 6-14 Fixed Supply PDO says:
Fast Role Swap required USB Type-C Current (see also [USB Type-C 2.0]):
Value | Description
   00b  | Fast Swap not supported (default)
   01b  | Default USB Power
   10b  | 1.5A @ 5V
   11b  | 3.0A @ 5V
This is the value in PDO of sink, the FRS property value(or after translated)
actually is used to compare with above value.

So I think both properties can share the same "value", maybe string
like below

   10 static const char * const typec_pwr_opmodes[] = {
   11         [TYPEC_PWR_MODE_USB]    = "default",
   12         [TYPEC_PWR_MODE_1_5A]   = "1.5A",
   13         [TYPEC_PWR_MODE_3_0A]   = "3.0A",
quoted
Note the *see also USB Type-C 2.0*.

USB Type-C specification 4.6.2.1 USB Type-C Current says:
The USB Type-C connector uses CC pins for configuration including an
ability for a Source to advertise to its port partner (Sink) the amount
of current it shall supply:
• Default is the as-configured for high-power operation current value as
defined by the USB Specification (500 mA for USB 2.0 ports; 900 mA or
1,500 mA for USB 3.2 ports in single-lane or dual-lane operation,
respectively)
• 1.5 A
• 3.0 A
quoted
Can we align the names in some way? power-opmode and frs-source-opmode
or ??
how about typec-power-opmode and frs-new-source-opmode
Sure.
quoted
quoted
quoted
I let USB PD specialists answer.

*frs* property fits with USB PD specification, so with USB PD protocol.
*power-opmode fits with USB Type-C specification, so with USB-C hardware
support.
quoted
Are these 2 properties mutually exclusive?
I think yes.
This should work to express that:

allOf:
   - not:
       required:
         - typec-power-opmode
         - frs-new-source-opmode

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help