dt-bindings: hwmon: Add Infineon TDA38640

PATCH Superseded Naresh Solanki 4 participants 18 messages Aug 2, 2023 – Aug 29, 2023

Subsystems (2)

Device tree bindings Hardware monitoring

lore

Share & tools

lore

Naresh Solanki

author

2023-08-02 19:32 UTC #0 lore raw

PATCH v3 1/3 dt-bindings: hwmon: Add Infineon TDA38640

From: Patrick Rudolph <[email protected]>

The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.

To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.

Signed-off-by Patrick Rudolph <[email protected]>

Signed-off-by Naresh Solanki <[email protected]>

---
 .../hwmon/pmbus/infineon,tda38640.yaml        | 51 +++++++++++++++++++
 .../devicetree/bindings/trivial-devices.yaml  |  2 -
 2 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml

Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml new file +51 -0

new file mode 100644
index 000000000000..c5924ddf1b47
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon TDA38640 Synchronous Buck Regulator with SVID and I2C
+
+maintainers:
+  - Naresh Solanki <[email protected]>
+
+description: |
+  The Infineon TDA38640 is a 40A Single-voltage Synchronous Buck
+  Regulator with SVID and I2C designed for Industrial use.
+
+  Datasheet: https://www.infineon.com/dgdl/Infineon-TDA38640-0000-DataSheet-v02_04-EN.pdf?fileId=8ac78c8c80027ecd018042f2337f00c9
+
+properties:
+  compatible:
+    enum:
+      - infineon,tda38640
+
+  reg:
+    maxItems: 1
+
+  infineon,en-svid-control:
+    description: |
+      When enabled, it allows the chip to utilize workaround for
+      software control of output when operating in SVID mode where
+      hardware-based output control is the default behavior.
+    type: boolean
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        tda38640@40 {
+            compatible = "infineon,tda38640";
+            reg = <0x40>;
+        };
+    };
+

Documentation/devicetree/bindings/trivial-devices.yaml +0 -2

index 40bc475ee7e1..86c7d34f63bf 100644
@@ -151,8 +151,6 @@ properties:
           - infineon,slb9645tt
             # Infineon SLB9673 I2C TPM 2.0
           - infineon,slb9673
-            # Infineon TDA38640 Voltage Regulator
-          - infineon,tda38640
             # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
           - infineon,tlv493d-a1b6
             # Infineon Multi-phase Digital VR Controller xdpe11280

base-commit: cb7022b8976e3c4d12cea2e7bb820a2944e2fd7b

Signature · 1 line

2.41.0

Naresh Solanki

author

2023-08-02 19:32 UTC #1 lore raw

PATCH v3 2/3 hwmon: (pmbus) Add ON_OFF_CONFIG register bits

From: Patrick Rudolph <[email protected]>

Add bits found in the ON_OFF_CONFIG register.

Signed-off-by Patrick Rudolph <[email protected]>

Signed-off-by Naresh Solanki <[email protected]>

---
 drivers/hwmon/pmbus/pmbus.h | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/hwmon/pmbus/pmbus.h +9 -0

index b0832a4c690d..7a28bac7f171 100644
@@ -243,6 +243,15 @@ enum pmbus_regs {
  */
 #define PB_OPERATION_CONTROL_ON		BIT(7)
 
+/*
+ * ON_OFF_CONFIG
+ */
+#define PB_ON_OFF_CONFIG_POWERUP_CONTROL	BIT(4)
+#define PB_ON_OFF_CONFIG_OPERATION_REQ		BIT(3)
+#define PB_ON_OFF_CONFIG_EN_PIN_REQ		BIT(2)
+#define PB_ON_OFF_CONFIG_POLARITY_HIGH		BIT(1)
+#define PB_ON_OFF_CONFIG_TURN_OFF_FAST		BIT(0)
+
 /*
  * WRITE_PROTECT
  */

Signature · 1 line

2.41.0

Guenter Roeck

maintainer Reviewed-by on v3 2/3

2023-08-12 12:31 UTC #2 lore raw

Re: [PATCH v3 2/3] hwmon: (pmbus) Add ON_OFF_CONFIG register bits

Quoted 6 lines · Naresh Solanki

From: Patrick Rudolph <[email protected]>
Add bits found in the ON_OFF_CONFIG register.
Signed-off-by Patrick Rudolph <[email protected]>
Signed-off-by Naresh Solanki <[email protected]>

For my reference:

Reviewed-by Guenter Roeck <[email protected]>

Naresh Solanki

author

2023-08-02 19:32 UTC #3 lore raw

PATCH v3 3/3 hwmon: (pmbus/tda38640) Add workaround for bug in SVID mode

In reply to Naresh Solanki

From: Patrick Rudolph <[email protected]>

TDA38640 can operate in either PMBus mode or SVID mode.
In SVID mode, by design ENABLE pin is the only option for controlling the output rail.

In scenarios that utilizes the chip in SVID mode with ENABLE pin either grounded or tied to logic high & software control is desired then use dt property 'infineon,en-svid-control' to enable the below workaround.

The workaround utilizes ENABLE pin polarity flipping to control output rail.

If property 'infineon,en-svid-control' is specified then determine if chip is in SVID mode by checking BIT15 of MTP memory offset 0x44 as described in the datasheet.

If chip is in SVID mode then apply the workaround by
1. Determine EN pin level
2. Maps BIT7 of OPERATION(01h) to EN_PIN_POLARITY(BIT1) of PB_ON_OFF_CONFIG.

Signed-off-by Patrick Rudolph <[email protected]>

Signed-off-by Naresh Solanki <[email protected]>

----
Changes in V3:
- Use dt property to determine if workaround is needed. Changes in V2:
- Remove dependency on DT propery,
- Runtime determine SVID mode & ENABLE pin level,
- Update commit message.

---
 drivers/hwmon/pmbus/tda38640.c | 154 ++++++++++++++++++++++++++++++++-
 1 file changed, 152 insertions(+), 2 deletions(-)

drivers/hwmon/pmbus/tda38640.c +152 -2

index 450b0273fb59..d3d987d0d7b6 100644
@@ -18,6 +18,127 @@ static const struct regulator_desc __maybe_unused tda38640_reg_desc[] = {
 	PMBUS_REGULATOR("vout", 0),
 };
 
+struct tda38640_data {
+	struct pmbus_driver_info info;
+	u32 en_pin_lvl;
+};
+
+#define to_tda38640_data(x)  container_of(x, struct tda38640_data, info)
+
+/*
+ * Map PB_ON_OFF_CONFIG_POLARITY_HIGH to PB_OPERATION_CONTROL_ON.
+ */
+static int tda38640_read_byte_data(struct i2c_client *client, int page, int reg)
+{
+	const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
+	struct tda38640_data *data = to_tda38640_data(info);
+	int ret, on_off_config, enabled;
+
+	if (reg != PMBUS_OPERATION)
+		return -ENODATA;
+
+	ret = pmbus_read_byte_data(client, page, reg);
+	if (ret < 0)
+		return ret;
+
+	on_off_config = pmbus_read_byte_data(client, page,
+					     PMBUS_ON_OFF_CONFIG);
+	if (on_off_config < 0)
+		return on_off_config;
+
+	enabled = !!(on_off_config & PB_ON_OFF_CONFIG_POLARITY_HIGH);
+
+	enabled ^= data->en_pin_lvl;
+	if (enabled)
+		ret &= ~PB_OPERATION_CONTROL_ON;
+	else
+		ret |= PB_OPERATION_CONTROL_ON;
+
+	return ret;
+}
+
+/*
+ * Map PB_OPERATION_CONTROL_ON to PB_ON_OFF_CONFIG_POLARITY_HIGH.
+ */
+static int tda38640_write_byte_data(struct i2c_client *client, int page,
+				    int reg, u8 byte)
+{
+	const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
+	struct tda38640_data *data = to_tda38640_data(info);
+	int enable, ret;
+
+	if (reg != PMBUS_OPERATION)
+		return -ENODATA;
+
+	enable = !!(byte & PB_OPERATION_CONTROL_ON);
+
+	byte &= ~PB_OPERATION_CONTROL_ON;
+	ret = pmbus_write_byte_data(client, page, reg, byte);
+	if (ret < 0)
+		return ret;
+
+	enable ^= data->en_pin_lvl;
+
+	return pmbus_update_byte_data(client, page, PMBUS_ON_OFF_CONFIG,
+				      PB_ON_OFF_CONFIG_POLARITY_HIGH,
+				      enable ? 0 : PB_ON_OFF_CONFIG_POLARITY_HIGH);
+}
+
+static int svid_mode(struct i2c_client *client, struct tda38640_data *data)
+{
+	/* PMBUS_MFR_READ(0xD0) + MTP Address offset */
+	u8 write_buf[] = {0xd0, 0x44, 0x00};
+	u8 read_buf[2];
+	int ret, svid;
+	bool off, reg_en_pin_pol;
+
+	struct i2c_msg msgs[2] = {
+		{
+			.addr = client->addr,
+			.flags = 0,
+			.buf = write_buf,
+			.len = sizeof(write_buf),
+		},
+		{
+			.addr = client->addr,
+			.flags = I2C_M_RD,
+			.buf = read_buf,
+			.len = sizeof(read_buf),
+		}
+	};
+
+	ret = i2c_transfer(client->adapter, msgs, 2);
+	if (ret < 0) {
+		dev_err(&client->dev, "i2c_transfer failed. %d", ret);
+		return ret;
+	}
+
+	/*
+	 * 0x44[15] determines PMBus Operating Mode
+	 * If bit is set then it is SVID mode.
+	 */
+	svid = !!(read_buf[1] & BIT(7));
+
+	/*
+	 * Determine EN pin level for use in SVID mode.
+	 * This is done with help of STATUS_BYTE bit 6(OFF) & ON_OFF_CONFIG bit 2(EN pin polarity).
+	 */
+	if (svid) {
+		ret = i2c_smbus_read_byte_data(client, PMBUS_STATUS_BYTE);
+		if (ret < 0)
+			return ret;
+		off = !!(ret & PB_STATUS_OFF);
+
+		ret = i2c_smbus_read_byte_data(client, PMBUS_ON_OFF_CONFIG);
+		if (ret < 0)
+			return ret;
+		reg_en_pin_pol = !!(ret & PB_ON_OFF_CONFIG_POLARITY_HIGH);
+		data->en_pin_lvl = off ^ reg_en_pin_pol;
+	}
+
+	return svid;
+}
+
 static struct pmbus_driver_info tda38640_info = {
 	.pages = 1,
 	.format[PSC_VOLTAGE_IN] = linear,

@@ -26,7 +147,6 @@ static struct pmbus_driver_info tda38640_info = {
 	.format[PSC_CURRENT_IN] = linear,
 	.format[PSC_POWER] = linear,
 	.format[PSC_TEMPERATURE] = linear,
-
 	.func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT
 	    | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
 	    | PMBUS_HAVE_IIN

@@ -41,7 +161,37 @@ static struct pmbus_driver_info tda38640_info = {
 
 static int tda38640_probe(struct i2c_client *client)
 {
-	return pmbus_do_probe(client, &tda38640_info);
+	struct tda38640_data *data;
+	int svid;
+
+	data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	memcpy(&data->info, &tda38640_info, sizeof(tda38640_info));
+
+	if (IS_ENABLED(CONFIG_SENSORS_TDA38640_REGULATOR) && \
+	    of_property_read_bool(client->dev.of_node, "infineon,en-svid-control")) {
+		svid = svid_mode(client, data);
+		if (svid < 0) {
+			dev_err_probe(&client->dev, svid, "Could not determine operating mode.");
+			return svid;
+		}
+
+		/*
+		 * Apply ON_OFF_CONFIG workaround as enabling the regulator using the
+		 * OPERATION register doesn't work in SVID mode.
+		 *
+		 * One should configure PMBUS_ON_OFF_CONFIG here, but
+		 * PB_ON_OFF_CONFIG_POWERUP_CONTROL and PB_ON_OFF_CONFIG_EN_PIN_REQ
+		 * are ignored by the device.
+		 * Only PB_ON_OFF_CONFIG_POLARITY_HIGH has an effect.
+		 */
+		if (svid) {
+			data->info.read_byte_data = tda38640_read_byte_data;
+			data->info.write_byte_data = tda38640_write_byte_data;
+		}
+	}
+	return pmbus_do_probe(client, &data->info);
 }
 
 static const struct i2c_device_id tda38640_id[] = {

Signature · 1 line

2.41.0

Guenter Roeck

maintainer Reviewed-by on v3 3/3

2023-08-12 12:33 UTC #4 lore raw

Re: [PATCH v3 3/3] hwmon: (pmbus/tda38640) Add workaround for bug in SVID mode

Quoted 17 lines · Naresh Solanki

From: Patrick Rudolph <[email protected]>
TDA38640 can operate in either PMBus mode or SVID mode.
In SVID mode, by design ENABLE pin is the only option for controlling the output rail.
In scenarios that utilizes the chip in SVID mode with ENABLE pin either grounded or tied to logic high & software control is desired then use dt property 'infineon,en-svid-control' to enable the below workaround.
The workaround utilizes ENABLE pin polarity flipping to control output rail.
If property 'infineon,en-svid-control' is specified then determine if chip is in SVID mode by checking BIT15 of MTP memory offset 0x44 as described in the datasheet.

Quoted 7 lines

If chip is in SVID mode then apply the workaround by
1. Determine EN pin level
2. Maps BIT7 of OPERATION(01h) to EN_PIN_POLARITY(BIT1) of PB_ON_OFF_CONFIG.
Signed-off-by Patrick Rudolph <[email protected]>
Signed-off-by Naresh Solanki <[email protected]>

For my reference:

Reviewed-by Guenter Roeck <[email protected]>

We still have to wait for dt patch approval.

Guenter

Conor Dooley

2023-08-08 19:14 UTC #5 lore raw

In reply to Naresh Solanki

Quoted 11 lines · Naresh Solanki

From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.

Why do you need a custom property for this? How come it is not possible to determine what bus you are on?

Thanks,
Conor.

Quoted 84 lines

Signed-off-by Patrick Rudolph <[email protected]>

Signed-off-by Naresh Solanki <[email protected]>

---
 .../hwmon/pmbus/infineon,tda38640.yaml        | 51 +++++++++++++++++++
 .../devicetree/bindings/trivial-devices.yaml  |  2 -
 2 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml

Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml new file +51 -0

new file mode 100644
index 000000000000..c5924ddf1b47
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon TDA38640 Synchronous Buck Regulator with SVID and I2C
+
+maintainers:
+  - Naresh Solanki <[email protected]>
+
+description: |
+  The Infineon TDA38640 is a 40A Single-voltage Synchronous Buck
+  Regulator with SVID and I2C designed for Industrial use.
+
+  Datasheet: https://www.infineon.com/dgdl/Infineon-TDA38640-0000-DataSheet-v02_04-EN.pdf?fileId=8ac78c8c80027ecd018042f2337f00c9
+
+properties:
+  compatible:
+    enum:
+      - infineon,tda38640
+
+  reg:
+    maxItems: 1
+
+  infineon,en-svid-control:
+    description: |
+      When enabled, it allows the chip to utilize workaround for
+      software control of output when operating in SVID mode where
+      hardware-based output control is the default behavior.
+    type: boolean
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        tda38640@40 {
+            compatible = "infineon,tda38640";
+            reg = <0x40>;
+        };
+    };
+

Documentation/devicetree/bindings/trivial-devices.yaml +0 -2

index 40bc475ee7e1..86c7d34f63bf 100644
@@ -151,8 +151,6 @@ properties:
           - infineon,slb9645tt
             # Infineon SLB9673 I2C TPM 2.0
           - infineon,slb9673
-            # Infineon TDA38640 Voltage Regulator
-          - infineon,tda38640
             # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
           - infineon,tlv493d-a1b6
             # Infineon Multi-phase Digital VR Controller xdpe11280

base-commit: cb7022b8976e3c4d12cea2e7bb820a2944e2fd7b

Signature · 1 line

2.41.0

Guenter Roeck

maintainer

2023-08-08 17:22 UTC #6 lore raw

Quoted 8 lines · Conor Dooley

Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.

Quoted 8 lines

Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?

That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.

Guenter

Quoted 87 lines

Thanks,
Conor.

Quoted 84 lines

Signed-off-by Patrick Rudolph <[email protected]>

Signed-off-by Naresh Solanki <[email protected]>

---
  .../hwmon/pmbus/infineon,tda38640.yaml        | 51 +++++++++++++++++++
  .../devicetree/bindings/trivial-devices.yaml  |  2 -
  2 files changed, 51 insertions(+), 2 deletions(-)

create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml

Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml new file +51 -0

new file mode 100644
index 000000000000..c5924ddf1b47
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon TDA38640 Synchronous Buck Regulator with SVID and I2C
+
+maintainers:
+  - Naresh Solanki <[email protected]>
+
+description: |
+  The Infineon TDA38640 is a 40A Single-voltage Synchronous Buck
+  Regulator with SVID and I2C designed for Industrial use.
+
+  Datasheet: https://www.infineon.com/dgdl/Infineon-TDA38640-0000-DataSheet-v02_04-EN.pdf?fileId=8ac78c8c80027ecd018042f2337f00c9
+
+properties:
+  compatible:
+    enum:
+      - infineon,tda38640
+
+  reg:
+    maxItems: 1
+
+  infineon,en-svid-control:
+    description: |
+      When enabled, it allows the chip to utilize workaround for
+      software control of output when operating in SVID mode where
+      hardware-based output control is the default behavior.
+    type: boolean
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        tda38640@40 {
+            compatible = "infineon,tda38640";
+            reg = <0x40>;
+        };
+    };
+

Documentation/devicetree/bindings/trivial-devices.yaml +0 -2

index 40bc475ee7e1..86c7d34f63bf 100644
@@ -151,8 +151,6 @@ properties:
            - infineon,slb9645tt
              # Infineon SLB9673 I2C TPM 2.0
            - infineon,slb9673
-            # Infineon TDA38640 Voltage Regulator
-          - infineon,tda38640
              # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
            - infineon,tlv493d-a1b6
              # Infineon Multi-phase Digital VR Controller xdpe11280

base-commit: cb7022b8976e3c4d12cea2e7bb820a2944e2fd7b

Signature · 1 line

2.41.0

Conor Dooley

2023-08-08 16:06 UTC #7 lore raw

Quoted 18 lines · Guenter Roeck

Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?

Quoted 8 lines

That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.

Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.

Naresh Solanki

author

2023-08-11 16:01 UTC #8 lore raw

Hi,

Quoted 29 lines · Conor Dooley

Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.

Quoted 6 lines

Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.

To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.

Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.

For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd

I trust this clarifies any questions or uncertainties you may have had.

Best Regards,
Naresh

Krzysztof Kozlowski

2023-08-14 19:33 UTC #9 lore raw

Quoted 49 lines · Naresh Solanki

Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.

Quoted 6 lines

Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd

This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.

Best regards,
Krzysztof

Naresh Solanki

author

2023-08-16 08:52 UTC #10 lore raw

Hi Krzysztof,

Quoted 54 lines · Krzysztof Kozlowski

Quoted 52 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.

Quoted 7 lines

Quoted 3 lines
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.

I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?

Regards,
Naresh

Quoted 4 lines

Best regards,
Krzysztof

Krzysztof Kozlowski

2023-08-18 09:24 UTC #11 lore raw

Quoted 62 lines · Naresh Solanki

Hi Krzysztof,
Quoted 58 lines · Krzysztof Kozlowski
Quoted 55 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd

Quoted 5 lines

Quoted 3 lines
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?

I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.

Best regards,
Krzysztof

Naresh Solanki

author

2023-08-22 09:02 UTC #12 lore raw

Quoted 64 lines · Krzysztof Kozlowski

Quoted 62 lines · Naresh Solanki
Hi Krzysztof,
Quoted 58 lines · Krzysztof Kozlowski
Quoted 55 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?
I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.

Based on your feedback, will update to below:
infineon,fixed-level-en-pin:
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up).
type: boolean

Quoted 5 lines

Best regards,
Krzysztof

Guenter Roeck

maintainer

2023-08-22 13:17 UTC #13 lore raw

Quoted 74 lines · Naresh Solanki

Hi
Quoted 70 lines · Krzysztof Kozlowski
Quoted 67 lines · Naresh Solanki
Hi Krzysztof,
Quoted 54 lines · Krzysztof Kozlowski
Quoted 52 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
Quoted 7 lines
Quoted 3 lines
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?

Quoted 8 lines

Quoted 2 lines
I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.
Based on your feedback, will update to below:
infineon,fixed-level-en-pin:
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up).
type: boolean

Messy, because while it reflects physical connectivity, it doesn't reflect its use in the system at all. The pin may be at fixed level or left unconnected, but the system vendor doesn't want to give users the means to control output power (which would be the normal situation).

But then, if that is the only way to get a property accepted, so be it.

Guenter

Naresh Solanki

author

2023-08-22 16:12 UTC #14 lore raw

Hi,

Quoted 85 lines · Guenter Roeck

Quoted 74 lines · Naresh Solanki
Hi
Quoted 70 lines · Krzysztof Kozlowski
Quoted 67 lines · Naresh Solanki
Hi Krzysztof,
Quoted 54 lines · Krzysztof Kozlowski
Quoted 52 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
Quoted 7 lines
Quoted 3 lines
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?
Quoted 8 lines
Quoted 2 lines
I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.
Based on your feedback, will update to below:
infineon,fixed-level-en-pin:
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up).
type: boolean

Quoted 4 lines

Messy, because while it reflects physical connectivity, it doesn't reflect its use in the system at all. The pin may be at fixed level or left unconnected, but the system vendor doesn't want to give users the means to control output power (which would be the normal situation).

Maybe this would be better ? infineon,svid-mode-fixed-en-pin
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up) which chip in SVID mode.

Regards,
Naresh

Quoted 4 lines

But then, if that is the only way to get a property accepted, so be it.
Guenter

Guenter Roeck

maintainer

2023-08-22 16:50 UTC #15 lore raw

Quoted 92 lines · Naresh Solanki

Hi,
Quoted 85 lines · Guenter Roeck
Quoted 74 lines · Naresh Solanki
Hi
Quoted 70 lines · Krzysztof Kozlowski
Quoted 67 lines · Naresh Solanki
Hi Krzysztof,
Quoted 54 lines · Krzysztof Kozlowski
Quoted 52 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
Quoted 7 lines
Quoted 3 lines
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?
Quoted 8 lines
Quoted 2 lines
I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.
Based on your feedback, will update to below:
infineon,fixed-level-en-pin:
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up).
type: boolean
Quoted 4 lines
Messy, because while it reflects physical connectivity, it doesn't reflect its use in the system at all. The pin may be at fixed level or left unconnected, but the system vendor doesn't want to give users the means to control output power (which would be the normal situation).

Quoted 6 lines

Maybe this would be better ? infineon,svid-mode-fixed-en-pin
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up) which chip in SVID mode.

which chip ? Do you mean "with the chip" ?

I don't think that makes a difference. It still doesn't describe your use case (which is something like "the chip is in SVID mode, its enable pin is set to fixed level, and we need to manipulate its interpretation by the chip so we can control the enable status from software). I have no idea how to express that in a way that would be acceptable as devicetree property.

It doesn't seem to me that we are making much progress here. I know it isn't supposed to be done, and I don't really like it, but could you use a module parameter in your system ? I'd be open to accept that to make progress.

Thanks,
Guenter

Naresh Solanki

author

2023-08-22 17:39 UTC #16 lore raw

Hi.

Quoted 94 lines · Guenter Roeck

Quoted 92 lines · Naresh Solanki
Hi,
Quoted 89 lines · Guenter Roeck
Quoted 74 lines · Naresh Solanki
Hi
Quoted 70 lines · Krzysztof Kozlowski
Quoted 67 lines · Naresh Solanki
Hi Krzysztof,
Quoted 54 lines · Krzysztof Kozlowski
Quoted 52 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on its mode of operation. When the chip is in SVID mode, only hardware-based output control is supported via ENABLE pin. However, when it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT property 'infineon,en-svid-control'. This property will enable the workaround, which utilizes ENABLE pin polarity flipping for output when the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
Quoted 7 lines
Quoted 3 lines
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?
Quoted 8 lines
Quoted 2 lines
I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.
Based on your feedback, will update to below:
infineon,fixed-level-en-pin:
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up).
type: boolean
Messy, because while it reflects physical connectivity, it doesn't reflect its use in the system at all. The pin may be at fixed level or left unconnected, but the system vendor doesn't want to give users the means to control output power (which would be the normal situation).

Quoted 8 lines

Quoted 6 lines
Maybe this would be better ? infineon,svid-mode-fixed-en-pin
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up) which chip in SVID mode.
which chip ? Do you mean "with the chip" ?

Yep. sorry for the typo.

Quoted 7 lines

I don't think that makes a difference. It still doesn't describe your use case (which is something like "the chip is in SVID mode, its enable pin is set to fixed level, and we need to manipulate its interpretation by the chip so we can control the enable status from software). I have no idea how to express that in a way that would be acceptable as devicetree property.

In typical use case when chip is in SVID mode ,the ENABLE pin isn't fixed i.e., either connected power good or FPGA pin.
If this property is explicitly specified then its clear in the hardware that
1. chip is in SVID mode,
2. ENABLE pin is fixed.
3. Intent to use the workaround.

@Krzysztof , Is this acceptable ? Can you please recommend a way forward please.

Regards,
Naresh

Quoted 8 lines

It doesn't seem to me that we are making much progress here. I know it isn't supposed to be done, and I don't really like it, but could you use a module parameter in your system ? I'd be open to accept that to make progress.
Thanks,
Guenter

Naresh Solanki

author

2023-08-29 14:11 UTC #17 lore raw

Quoted 121 lines · Naresh Solanki

Hi.
Quoted 94 lines · Guenter Roeck
Quoted 92 lines · Naresh Solanki
Hi,
Quoted 89 lines · Guenter Roeck
Quoted 74 lines · Naresh Solanki
Hi
Quoted 70 lines · Krzysztof Kozlowski
Quoted 67 lines · Naresh Solanki
Hi Krzysztof,
Quoted 54 lines · Krzysztof Kozlowski
Quoted 52 lines · Naresh Solanki
Hi,
Quoted 29 lines · Conor Dooley
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Conor Dooley
Quoted 7 lines · Naresh Solanki
From: Patrick Rudolph <[email protected]>
The TDA38640 chip has different output control mechanisms depending on
its mode of operation. When the chip is in SVID mode, only
hardware-based output control is supported via ENABLE pin. However, when
it operates in PMBus mode, software control works perfectly.
Quoted 8 lines
Quoted 4 lines
To enable software control as a workaround in SVID mode, add the DT
property 'infineon,en-svid-control'. This property will enable the
workaround, which utilizes ENABLE pin polarity flipping for output when
the chip is in SVID mode.
Why do you need a custom property for this? How come it is not possible to determine what bus you are on?
Quoted 8 lines
That is not the point. Yes, it can be detected if the control method is PMBus or SVID. However, in SVID mode, SVID is supposed to control the output, not PMBUs. This is bypassed by controlling the polarity of the (physical) output enable signal. We do _not_ want this enabled automatically in SVID mode. Its side effects on random boards using this chip are unknown. Thus, this needs a property which specifically enables this functionality for users who _really_ need to use it and (hopefully) know what they are doing.
Quoted 6 lines
Hmm, reading this it makes a lot more sense why this is a property - I guess I just struggled to understand the commit message here, particularly what the benefit of using the workaround is. I'm still having difficulty parsing the commit & property text though - its unclear to me when you would need to use it - so I will stay out of the way & let Rob or Krzysztof handle things.
To provide context, my system employs a unique power sequence strategy utilizing a BMC (Baseboard Management Controller), rendering the reliance on the ENABLE pin unnecessary.
In this configuration, the ENABLE pin is grounded in the hardware. While most regulators facilitate PMBus Operation for output control, the TDA38640 chip, when in SVID mode, is constrained by the ENABLE pin to align with Intel specifications.
My communication with Infineon confirmed that the recommended approach is to invert the Enable Pin for my use case.
Since this is not typically the use case for most setup & hence DT property is must for enabling the special case.
Quoted 7 lines
Quoted 3 lines
For further insight into my setup's power sequence strategy, you can refer to the following link: https://github.com/9elements/pwrseqd
This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system.
I guess by entire system you mean how the regulators(including TDA38640) connected & operated in our setup ?
Quoted 8 lines
Quoted 2 lines
I mean, property name and description should say what is the characteristic of the hardware/firmware/entire system.
Based on your feedback, will update to below:
infineon,fixed-level-en-pin:
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up).
type: boolean
Messy, because while it reflects physical connectivity, it doesn't reflect its use in the system at all. The pin may be at fixed level or left unconnected, but the system vendor doesn't want to give users the means to control output power (which would be the normal situation).
Quoted 8 lines
Quoted 6 lines
Maybe this would be better ? infineon,svid-mode-fixed-en-pin
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up) which chip in SVID mode.
which chip ? Do you mean "with the chip" ?
Yep. sorry for the typo.
Quoted 7 lines
I don't think that makes a difference. It still doesn't describe your use case (which is something like "the chip is in SVID mode, its enable pin is set to fixed level, and we need to manipulate its interpretation by the chip so we can control the enable status from software). I have no idea how to express that in a way that would be acceptable as devicetree property.
In typical use case when chip is in SVID mode ,the ENABLE pin isn't fixed i.e., either connected power good or FPGA pin.
If this property is explicitly specified then its clear in the hardware that
1. chip is in SVID mode,
2. ENABLE pin is fixed.
3. Intent to use the workaround.

Quoted 2 lines

@Krzysztof , Is this acceptable ? Can you please recommend a way forward please.

I guess the below change in property should be fine. Will push V4 based on it. infineon,svid-mode-fixed-en-pin
description: |
Indicate the ENABLE pin is set at fixed level or left unconnected(has internal pull-up) with the chip in
SVID mode.

Regards,
Naresh

Quoted 11 lines

Regards,
Naresh
Quoted 8 lines
It doesn't seem to me that we are making much progress here. I know it isn't supposed to be done, and I don't really like it, but could you use a module parameter in your system ? I'd be open to accept that to make progress.
Thanks,
Guenter