[PATCH i2c-next 0/2] i2c: aspeed: Add H/W timeout support

[PATCH i2c-next 0/2] i2c: aspeed: Add H/W timeout support

[Jae Hyun Yoo]

In case of multi-master environment, if a peer master incorrectly handles
a bus in the middle of a transaction, I2C hardware hangs in slave state
and it can't escape from the slave state, so this commit adds slave
inactive timeout support to recover the bus in the case.

By applying this change, SDA data-low and SCL clock-low timeout feature
also can be enabled which was disabled previously.

Jae Hyun Yoo (2):
  dt-bindings: i2c: aspeed: add hardware timeout support
  i2c: aspeed: add slave inactive timeout support

 .../devicetree/bindings/i2c/i2c-aspeed.txt    |  2 +
 drivers/i2c/busses/i2c-aspeed.c               | 82 +++++++++++++++++--
 2 files changed, 78 insertions(+), 6 deletions(-)

-- 
2.23.0

[PATCH i2c-next 0/2] i2c: aspeed: Add H/W timeout support

[Jae Hyun Yoo]

In case of multi-master environment, if a peer master incorrectly handles
a bus in the middle of a transaction, I2C hardware hangs in slave state
and it can't escape from the slave state, so this commit adds slave
inactive timeout support to recover the bus in the case.

By applying this change, SDA data-low and SCL clock-low timeout feature
also can be enabled which was disabled previously.

Jae Hyun Yoo (2):
  dt-bindings: i2c: aspeed: add hardware timeout support
  i2c: aspeed: add slave inactive timeout support

 .../devicetree/bindings/i2c/i2c-aspeed.txt    |  2 +
 drivers/i2c/busses/i2c-aspeed.c               | 82 +++++++++++++++++--
 2 files changed, 78 insertions(+), 6 deletions(-)

-- 
2.23.0

[PATCH i2c-next 0/2] i2c: aspeed: Add H/W timeout support

[Jae Hyun Yoo]

In case of multi-master environment, if a peer master incorrectly handles
a bus in the middle of a transaction, I2C hardware hangs in slave state
and it can't escape from the slave state, so this commit adds slave
inactive timeout support to recover the bus in the case.

By applying this change, SDA data-low and SCL clock-low timeout feature
also can be enabled which was disabled previously.

Jae Hyun Yoo (2):
  dt-bindings: i2c: aspeed: add hardware timeout support
  i2c: aspeed: add slave inactive timeout support

 .../devicetree/bindings/i2c/i2c-aspeed.txt    |  2 +
 drivers/i2c/busses/i2c-aspeed.c               | 82 +++++++++++++++++--
 2 files changed, 78 insertions(+), 6 deletions(-)

-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Append a binding to support hardware timeout feature.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
---
 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
index b47f6ccb196a..133bfedf4cdd 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
@@ -17,6 +17,8 @@ Optional Properties:
 - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
 		  specified
 - multi-master	: states that there is another master active on this bus.
+- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
+			  specified, the H/W timeout feature will be disabled.
 
 Example:
 
-- 
2.23.0

[PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Append a binding to support hardware timeout feature.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
---
 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
index b47f6ccb196a..133bfedf4cdd 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
@@ -17,6 +17,8 @@ Optional Properties:
 - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
 		  specified
 - multi-master	: states that there is another master active on this bus.
+- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
+			  specified, the H/W timeout feature will be disabled.
 
 Example:
 
-- 
2.23.0

[PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Append a binding to support hardware timeout feature.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
---
 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
index b47f6ccb196a..133bfedf4cdd 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
@@ -17,6 +17,8 @@ Optional Properties:
 - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
 		  specified
 - multi-master	: states that there is another master active on this bus.
+- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
+			  specified, the H/W timeout feature will be disabled.
 
 Example:
 
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH i2c-next 2/2] i2c: aspeed: add slave inactive timeout support

[Jae Hyun Yoo]

In case of multi-master environment, if a peer master incorrectly handles
a bus in the middle of a transaction, I2C hardware hangs in slave state
and it can't escape from the slave state, so this commit adds slave
inactive timeout support to recover the bus in the case.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Tao Ren <taoren@fb.com>
---
 drivers/i2c/busses/i2c-aspeed.c | 83 ++++++++++++++++++++++++++++++---
 1 file changed, 77 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index a7be6f24450b..d43687cd2ddc 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -7,6 +7,7 @@
  *  Copyright 2017 Google, Inc.
  */
 
+#include <linux/bitfield.h>
 #include <linux/clk.h>
 #include <linux/completion.h>
 #include <linux/err.h>
@@ -43,6 +44,7 @@
 
 /* Device Register Definition */
 /* 0x00 : I2CD Function Control Register  */
+#define ASPEED_I2CD_BUS_AUTO_RECOVERY_EN		BIT(17)
 #define ASPEED_I2CD_MULTI_MASTER_DIS			BIT(15)
 #define ASPEED_I2CD_SDA_DRIVE_1T_EN			BIT(8)
 #define ASPEED_I2CD_M_SDA_DRIVE_1T_EN			BIT(7)
@@ -58,10 +60,14 @@
 #define ASPEED_I2CD_TIME_SCL_HIGH_MASK			GENMASK(19, 16)
 #define ASPEED_I2CD_TIME_SCL_LOW_SHIFT			12
 #define ASPEED_I2CD_TIME_SCL_LOW_MASK			GENMASK(15, 12)
+#define ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_SHIFT	8
+#define ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK	GENMASK(9, 8)
 #define ASPEED_I2CD_TIME_BASE_DIVISOR_MASK		GENMASK(3, 0)
 #define ASPEED_I2CD_TIME_SCL_REG_MAX			GENMASK(3, 0)
+
 /* 0x08 : I2CD Clock and AC Timing Control Register #2 */
-#define ASPEED_NO_TIMEOUT_CTRL				0
+#define ASPEED_I2CD_TIMEOUT_CYCLES_SHIFT		0
+#define ASPEED_I2CD_TIMEOUT_CYCLES_MASK			GENMASK(4, 0)
 
 /* 0x0c : I2CD Interrupt Control Register &
  * 0x10 : I2CD Interrupt Status Register
@@ -69,6 +75,7 @@
  * These share bit definitions, so use the same values for the enable &
  * status bits.
  */
+#define ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT		BIT(15)
 #define ASPEED_I2CD_INTR_SDA_DL_TIMEOUT			BIT(14)
 #define ASPEED_I2CD_INTR_BUS_RECOVER_DONE		BIT(13)
 #define ASPEED_I2CD_INTR_SLAVE_MATCH			BIT(7)
@@ -84,8 +91,11 @@
 		 ASPEED_I2CD_INTR_SCL_TIMEOUT |				       \
 		 ASPEED_I2CD_INTR_ABNORMAL |				       \
 		 ASPEED_I2CD_INTR_ARBIT_LOSS)
+#define ASPEED_I2CD_INTR_SLAVE_ERRORS					       \
+		ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT
 #define ASPEED_I2CD_INTR_ALL						       \
-		(ASPEED_I2CD_INTR_SDA_DL_TIMEOUT |			       \
+		(ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT |		       \
+		 ASPEED_I2CD_INTR_SDA_DL_TIMEOUT |			       \
 		 ASPEED_I2CD_INTR_BUS_RECOVER_DONE |			       \
 		 ASPEED_I2CD_INTR_SCL_TIMEOUT |				       \
 		 ASPEED_I2CD_INTR_ABNORMAL |				       \
@@ -151,6 +161,7 @@ struct aspeed_i2c_bus {
 							   u32 divisor);
 	unsigned long			parent_clk_frequency;
 	u32				bus_frequency;
+	u32				hw_timeout_ms;
 	/* Transaction state. */
 	enum aspeed_i2c_master_state	master_state;
 	struct i2c_msg			*msgs;
@@ -240,6 +251,14 @@ static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus *bus)
 }
 
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
+static int aspeed_i2c_check_slave_error(u32 irq_status)
+{
+	if (irq_status & ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT)
+		return -EIO;
+
+	return 0;
+}
+
 static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 {
 	u32 command, irq_handled = 0;
@@ -249,6 +268,14 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	if (!slave)
 		return 0;
 
+	if (aspeed_i2c_check_slave_error(irq_status)) {
+		dev_dbg(bus->dev, "received slave error interrupt: 0x%08x\n",
+			irq_status);
+		irq_handled |= (irq_status & ASPEED_I2CD_INTR_SLAVE_ERRORS);
+		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+		return irq_handled;
+	}
+
 	command = readl(bus->base + ASPEED_I2C_CMD_REG);
 
 	/* Slave was requested, restart state machine. */
@@ -386,7 +413,7 @@ static void aspeed_i2c_next_msg_or_stop(struct aspeed_i2c_bus *bus)
 	}
 }
 
-static int aspeed_i2c_is_irq_error(u32 irq_status)
+static int aspeed_i2c_check_master_error(u32 irq_status)
 {
 	if (irq_status & ASPEED_I2CD_INTR_ARBIT_LOSS)
 		return -EAGAIN;
@@ -417,9 +444,9 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	 * should clear the command queue effectively taking us back to the
 	 * INACTIVE state.
 	 */
-	ret = aspeed_i2c_is_irq_error(irq_status);
+	ret = aspeed_i2c_check_master_error(irq_status);
 	if (ret) {
-		dev_dbg(bus->dev, "received error interrupt: 0x%08x\n",
+		dev_dbg(bus->dev, "received master error interrupt: 0x%08x\n",
 			irq_status);
 		irq_handled |= (irq_status & ASPEED_I2CD_INTR_MASTER_ERRORS);
 		if (bus->master_state != ASPEED_I2C_MASTER_INACTIVE) {
@@ -875,6 +902,7 @@ static u32 aspeed_i2c_25xx_get_clk_reg_val(struct device *dev, u32 divisor)
 /* precondition: bus.lock has been acquired. */
 static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus)
 {
+	u32 timeout_base_divisor, timeout_tick_us, timeout_cycles;
 	u32 divisor, clk_reg_val;
 
 	divisor = DIV_ROUND_UP(bus->parent_clk_frequency, bus->bus_frequency);
@@ -883,8 +911,46 @@ static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus)
 			ASPEED_I2CD_TIME_THDSTA_MASK |
 			ASPEED_I2CD_TIME_TACST_MASK);
 	clk_reg_val |= bus->get_clk_reg_val(bus->dev, divisor);
+
+	if (bus->hw_timeout_ms) {
+		u8 div_max = ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK >>
+			     ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_SHIFT;
+		u8 cycles_max = ASPEED_I2CD_TIMEOUT_CYCLES_MASK >>
+				ASPEED_I2CD_TIMEOUT_CYCLES_SHIFT;
+
+		timeout_base_divisor = 0;
+
+		do {
+			timeout_tick_us = 1000 * (16384 <<
+						  (timeout_base_divisor << 1)) /
+					  (bus->parent_clk_frequency / 1000);
+
+			if (timeout_base_divisor == div_max ||
+			    timeout_tick_us * ASPEED_I2CD_TIMEOUT_CYCLES_MASK >=
+			    bus->hw_timeout_ms * 1000)
+				break;
+		} while (timeout_base_divisor++ < div_max);
+
+		if (timeout_tick_us) {
+			timeout_cycles = DIV_ROUND_UP(bus->hw_timeout_ms * 1000,
+						      timeout_tick_us);
+			if (timeout_cycles == 0)
+				timeout_cycles = 1;
+			else if (timeout_cycles > cycles_max)
+				timeout_cycles = cycles_max;
+		} else {
+			timeout_cycles = 0;
+		}
+	} else {
+		timeout_base_divisor = 0;
+		timeout_cycles = 0;
+	}
+
+	clk_reg_val |= FIELD_PREP(ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK,
+				  timeout_base_divisor);
+
 	writel(clk_reg_val, bus->base + ASPEED_I2C_AC_TIMING_REG1);
-	writel(ASPEED_NO_TIMEOUT_CTRL, bus->base + ASPEED_I2C_AC_TIMING_REG2);
+	writel(timeout_cycles, bus->base + ASPEED_I2C_AC_TIMING_REG2);
 
 	return 0;
 }
@@ -899,6 +965,11 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus,
 	/* Disable everything. */
 	writel(0, bus->base + ASPEED_I2C_FUN_CTRL_REG);
 
+	device_property_read_u32(&pdev->dev, "aspeed,hw-timeout-ms",
+				 &bus->hw_timeout_ms);
+	if (bus->hw_timeout_ms)
+		fun_ctrl_reg |= ASPEED_I2CD_BUS_AUTO_RECOVERY_EN;
+
 	ret = aspeed_i2c_init_clk(bus);
 	if (ret < 0)
 		return ret;
-- 
2.23.0

[PATCH i2c-next 2/2] i2c: aspeed: add slave inactive timeout support

[Jae Hyun Yoo]

In case of multi-master environment, if a peer master incorrectly handles
a bus in the middle of a transaction, I2C hardware hangs in slave state
and it can't escape from the slave state, so this commit adds slave
inactive timeout support to recover the bus in the case.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Tao Ren <taoren@fb.com>
---
 drivers/i2c/busses/i2c-aspeed.c | 83 ++++++++++++++++++++++++++++++---
 1 file changed, 77 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index a7be6f24450b..d43687cd2ddc 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -7,6 +7,7 @@
  *  Copyright 2017 Google, Inc.
  */
 
+#include <linux/bitfield.h>
 #include <linux/clk.h>
 #include <linux/completion.h>
 #include <linux/err.h>
@@ -43,6 +44,7 @@
 
 /* Device Register Definition */
 /* 0x00 : I2CD Function Control Register  */
+#define ASPEED_I2CD_BUS_AUTO_RECOVERY_EN		BIT(17)
 #define ASPEED_I2CD_MULTI_MASTER_DIS			BIT(15)
 #define ASPEED_I2CD_SDA_DRIVE_1T_EN			BIT(8)
 #define ASPEED_I2CD_M_SDA_DRIVE_1T_EN			BIT(7)
@@ -58,10 +60,14 @@
 #define ASPEED_I2CD_TIME_SCL_HIGH_MASK			GENMASK(19, 16)
 #define ASPEED_I2CD_TIME_SCL_LOW_SHIFT			12
 #define ASPEED_I2CD_TIME_SCL_LOW_MASK			GENMASK(15, 12)
+#define ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_SHIFT	8
+#define ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK	GENMASK(9, 8)
 #define ASPEED_I2CD_TIME_BASE_DIVISOR_MASK		GENMASK(3, 0)
 #define ASPEED_I2CD_TIME_SCL_REG_MAX			GENMASK(3, 0)
+
 /* 0x08 : I2CD Clock and AC Timing Control Register #2 */
-#define ASPEED_NO_TIMEOUT_CTRL				0
+#define ASPEED_I2CD_TIMEOUT_CYCLES_SHIFT		0
+#define ASPEED_I2CD_TIMEOUT_CYCLES_MASK			GENMASK(4, 0)
 
 /* 0x0c : I2CD Interrupt Control Register &
  * 0x10 : I2CD Interrupt Status Register
@@ -69,6 +75,7 @@
  * These share bit definitions, so use the same values for the enable &
  * status bits.
  */
+#define ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT		BIT(15)
 #define ASPEED_I2CD_INTR_SDA_DL_TIMEOUT			BIT(14)
 #define ASPEED_I2CD_INTR_BUS_RECOVER_DONE		BIT(13)
 #define ASPEED_I2CD_INTR_SLAVE_MATCH			BIT(7)
@@ -84,8 +91,11 @@
 		 ASPEED_I2CD_INTR_SCL_TIMEOUT |				       \
 		 ASPEED_I2CD_INTR_ABNORMAL |				       \
 		 ASPEED_I2CD_INTR_ARBIT_LOSS)
+#define ASPEED_I2CD_INTR_SLAVE_ERRORS					       \
+		ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT
 #define ASPEED_I2CD_INTR_ALL						       \
-		(ASPEED_I2CD_INTR_SDA_DL_TIMEOUT |			       \
+		(ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT |		       \
+		 ASPEED_I2CD_INTR_SDA_DL_TIMEOUT |			       \
 		 ASPEED_I2CD_INTR_BUS_RECOVER_DONE |			       \
 		 ASPEED_I2CD_INTR_SCL_TIMEOUT |				       \
 		 ASPEED_I2CD_INTR_ABNORMAL |				       \
@@ -151,6 +161,7 @@ struct aspeed_i2c_bus {
 							   u32 divisor);
 	unsigned long			parent_clk_frequency;
 	u32				bus_frequency;
+	u32				hw_timeout_ms;
 	/* Transaction state. */
 	enum aspeed_i2c_master_state	master_state;
 	struct i2c_msg			*msgs;
@@ -240,6 +251,14 @@ static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus *bus)
 }
 
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
+static int aspeed_i2c_check_slave_error(u32 irq_status)
+{
+	if (irq_status & ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT)
+		return -EIO;
+
+	return 0;
+}
+
 static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 {
 	u32 command, irq_handled = 0;
@@ -249,6 +268,14 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	if (!slave)
 		return 0;
 
+	if (aspeed_i2c_check_slave_error(irq_status)) {
+		dev_dbg(bus->dev, "received slave error interrupt: 0x%08x\n",
+			irq_status);
+		irq_handled |= (irq_status & ASPEED_I2CD_INTR_SLAVE_ERRORS);
+		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+		return irq_handled;
+	}
+
 	command = readl(bus->base + ASPEED_I2C_CMD_REG);
 
 	/* Slave was requested, restart state machine. */
@@ -386,7 +413,7 @@ static void aspeed_i2c_next_msg_or_stop(struct aspeed_i2c_bus *bus)
 	}
 }
 
-static int aspeed_i2c_is_irq_error(u32 irq_status)
+static int aspeed_i2c_check_master_error(u32 irq_status)
 {
 	if (irq_status & ASPEED_I2CD_INTR_ARBIT_LOSS)
 		return -EAGAIN;
@@ -417,9 +444,9 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	 * should clear the command queue effectively taking us back to the
 	 * INACTIVE state.
 	 */
-	ret = aspeed_i2c_is_irq_error(irq_status);
+	ret = aspeed_i2c_check_master_error(irq_status);
 	if (ret) {
-		dev_dbg(bus->dev, "received error interrupt: 0x%08x\n",
+		dev_dbg(bus->dev, "received master error interrupt: 0x%08x\n",
 			irq_status);
 		irq_handled |= (irq_status & ASPEED_I2CD_INTR_MASTER_ERRORS);
 		if (bus->master_state != ASPEED_I2C_MASTER_INACTIVE) {
@@ -875,6 +902,7 @@ static u32 aspeed_i2c_25xx_get_clk_reg_val(struct device *dev, u32 divisor)
 /* precondition: bus.lock has been acquired. */
 static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus)
 {
+	u32 timeout_base_divisor, timeout_tick_us, timeout_cycles;
 	u32 divisor, clk_reg_val;
 
 	divisor = DIV_ROUND_UP(bus->parent_clk_frequency, bus->bus_frequency);
@@ -883,8 +911,46 @@ static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus)
 			ASPEED_I2CD_TIME_THDSTA_MASK |
 			ASPEED_I2CD_TIME_TACST_MASK);
 	clk_reg_val |= bus->get_clk_reg_val(bus->dev, divisor);
+
+	if (bus->hw_timeout_ms) {
+		u8 div_max = ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK >>
+			     ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_SHIFT;
+		u8 cycles_max = ASPEED_I2CD_TIMEOUT_CYCLES_MASK >>
+				ASPEED_I2CD_TIMEOUT_CYCLES_SHIFT;
+
+		timeout_base_divisor = 0;
+
+		do {
+			timeout_tick_us = 1000 * (16384 <<
+						  (timeout_base_divisor << 1)) /
+					  (bus->parent_clk_frequency / 1000);
+
+			if (timeout_base_divisor == div_max ||
+			    timeout_tick_us * ASPEED_I2CD_TIMEOUT_CYCLES_MASK >=
+			    bus->hw_timeout_ms * 1000)
+				break;
+		} while (timeout_base_divisor++ < div_max);
+
+		if (timeout_tick_us) {
+			timeout_cycles = DIV_ROUND_UP(bus->hw_timeout_ms * 1000,
+						      timeout_tick_us);
+			if (timeout_cycles == 0)
+				timeout_cycles = 1;
+			else if (timeout_cycles > cycles_max)
+				timeout_cycles = cycles_max;
+		} else {
+			timeout_cycles = 0;
+		}
+	} else {
+		timeout_base_divisor = 0;
+		timeout_cycles = 0;
+	}
+
+	clk_reg_val |= FIELD_PREP(ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK,
+				  timeout_base_divisor);
+
 	writel(clk_reg_val, bus->base + ASPEED_I2C_AC_TIMING_REG1);
-	writel(ASPEED_NO_TIMEOUT_CTRL, bus->base + ASPEED_I2C_AC_TIMING_REG2);
+	writel(timeout_cycles, bus->base + ASPEED_I2C_AC_TIMING_REG2);
 
 	return 0;
 }
@@ -899,6 +965,11 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus,
 	/* Disable everything. */
 	writel(0, bus->base + ASPEED_I2C_FUN_CTRL_REG);
 
+	device_property_read_u32(&pdev->dev, "aspeed,hw-timeout-ms",
+				 &bus->hw_timeout_ms);
+	if (bus->hw_timeout_ms)
+		fun_ctrl_reg |= ASPEED_I2CD_BUS_AUTO_RECOVERY_EN;
+
 	ret = aspeed_i2c_init_clk(bus);
 	if (ret < 0)
 		return ret;
-- 
2.23.0

[PATCH i2c-next 2/2] i2c: aspeed: add slave inactive timeout support

[Jae Hyun Yoo]

In case of multi-master environment, if a peer master incorrectly handles
a bus in the middle of a transaction, I2C hardware hangs in slave state
and it can't escape from the slave state, so this commit adds slave
inactive timeout support to recover the bus in the case.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Tao Ren <taoren@fb.com>
---
 drivers/i2c/busses/i2c-aspeed.c | 83 ++++++++++++++++++++++++++++++---
 1 file changed, 77 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index a7be6f24450b..d43687cd2ddc 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -7,6 +7,7 @@
  *  Copyright 2017 Google, Inc.
  */
 
+#include <linux/bitfield.h>
 #include <linux/clk.h>
 #include <linux/completion.h>
 #include <linux/err.h>
@@ -43,6 +44,7 @@
 
 /* Device Register Definition */
 /* 0x00 : I2CD Function Control Register  */
+#define ASPEED_I2CD_BUS_AUTO_RECOVERY_EN		BIT(17)
 #define ASPEED_I2CD_MULTI_MASTER_DIS			BIT(15)
 #define ASPEED_I2CD_SDA_DRIVE_1T_EN			BIT(8)
 #define ASPEED_I2CD_M_SDA_DRIVE_1T_EN			BIT(7)
@@ -58,10 +60,14 @@
 #define ASPEED_I2CD_TIME_SCL_HIGH_MASK			GENMASK(19, 16)
 #define ASPEED_I2CD_TIME_SCL_LOW_SHIFT			12
 #define ASPEED_I2CD_TIME_SCL_LOW_MASK			GENMASK(15, 12)
+#define ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_SHIFT	8
+#define ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK	GENMASK(9, 8)
 #define ASPEED_I2CD_TIME_BASE_DIVISOR_MASK		GENMASK(3, 0)
 #define ASPEED_I2CD_TIME_SCL_REG_MAX			GENMASK(3, 0)
+
 /* 0x08 : I2CD Clock and AC Timing Control Register #2 */
-#define ASPEED_NO_TIMEOUT_CTRL				0
+#define ASPEED_I2CD_TIMEOUT_CYCLES_SHIFT		0
+#define ASPEED_I2CD_TIMEOUT_CYCLES_MASK			GENMASK(4, 0)
 
 /* 0x0c : I2CD Interrupt Control Register &
  * 0x10 : I2CD Interrupt Status Register
@@ -69,6 +75,7 @@
  * These share bit definitions, so use the same values for the enable &
  * status bits.
  */
+#define ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT		BIT(15)
 #define ASPEED_I2CD_INTR_SDA_DL_TIMEOUT			BIT(14)
 #define ASPEED_I2CD_INTR_BUS_RECOVER_DONE		BIT(13)
 #define ASPEED_I2CD_INTR_SLAVE_MATCH			BIT(7)
@@ -84,8 +91,11 @@
 		 ASPEED_I2CD_INTR_SCL_TIMEOUT |				       \
 		 ASPEED_I2CD_INTR_ABNORMAL |				       \
 		 ASPEED_I2CD_INTR_ARBIT_LOSS)
+#define ASPEED_I2CD_INTR_SLAVE_ERRORS					       \
+		ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT
 #define ASPEED_I2CD_INTR_ALL						       \
-		(ASPEED_I2CD_INTR_SDA_DL_TIMEOUT |			       \
+		(ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT |		       \
+		 ASPEED_I2CD_INTR_SDA_DL_TIMEOUT |			       \
 		 ASPEED_I2CD_INTR_BUS_RECOVER_DONE |			       \
 		 ASPEED_I2CD_INTR_SCL_TIMEOUT |				       \
 		 ASPEED_I2CD_INTR_ABNORMAL |				       \
@@ -151,6 +161,7 @@ struct aspeed_i2c_bus {
 							   u32 divisor);
 	unsigned long			parent_clk_frequency;
 	u32				bus_frequency;
+	u32				hw_timeout_ms;
 	/* Transaction state. */
 	enum aspeed_i2c_master_state	master_state;
 	struct i2c_msg			*msgs;
@@ -240,6 +251,14 @@ static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus *bus)
 }
 
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
+static int aspeed_i2c_check_slave_error(u32 irq_status)
+{
+	if (irq_status & ASPEED_I2CD_INTR_SLAVE_INACTIVE_TIMEOUT)
+		return -EIO;
+
+	return 0;
+}
+
 static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 {
 	u32 command, irq_handled = 0;
@@ -249,6 +268,14 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	if (!slave)
 		return 0;
 
+	if (aspeed_i2c_check_slave_error(irq_status)) {
+		dev_dbg(bus->dev, "received slave error interrupt: 0x%08x\n",
+			irq_status);
+		irq_handled |= (irq_status & ASPEED_I2CD_INTR_SLAVE_ERRORS);
+		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+		return irq_handled;
+	}
+
 	command = readl(bus->base + ASPEED_I2C_CMD_REG);
 
 	/* Slave was requested, restart state machine. */
@@ -386,7 +413,7 @@ static void aspeed_i2c_next_msg_or_stop(struct aspeed_i2c_bus *bus)
 	}
 }
 
-static int aspeed_i2c_is_irq_error(u32 irq_status)
+static int aspeed_i2c_check_master_error(u32 irq_status)
 {
 	if (irq_status & ASPEED_I2CD_INTR_ARBIT_LOSS)
 		return -EAGAIN;
@@ -417,9 +444,9 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	 * should clear the command queue effectively taking us back to the
 	 * INACTIVE state.
 	 */
-	ret = aspeed_i2c_is_irq_error(irq_status);
+	ret = aspeed_i2c_check_master_error(irq_status);
 	if (ret) {
-		dev_dbg(bus->dev, "received error interrupt: 0x%08x\n",
+		dev_dbg(bus->dev, "received master error interrupt: 0x%08x\n",
 			irq_status);
 		irq_handled |= (irq_status & ASPEED_I2CD_INTR_MASTER_ERRORS);
 		if (bus->master_state != ASPEED_I2C_MASTER_INACTIVE) {
@@ -875,6 +902,7 @@ static u32 aspeed_i2c_25xx_get_clk_reg_val(struct device *dev, u32 divisor)
 /* precondition: bus.lock has been acquired. */
 static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus)
 {
+	u32 timeout_base_divisor, timeout_tick_us, timeout_cycles;
 	u32 divisor, clk_reg_val;
 
 	divisor = DIV_ROUND_UP(bus->parent_clk_frequency, bus->bus_frequency);
@@ -883,8 +911,46 @@ static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus)
 			ASPEED_I2CD_TIME_THDSTA_MASK |
 			ASPEED_I2CD_TIME_TACST_MASK);
 	clk_reg_val |= bus->get_clk_reg_val(bus->dev, divisor);
+
+	if (bus->hw_timeout_ms) {
+		u8 div_max = ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK >>
+			     ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_SHIFT;
+		u8 cycles_max = ASPEED_I2CD_TIMEOUT_CYCLES_MASK >>
+				ASPEED_I2CD_TIMEOUT_CYCLES_SHIFT;
+
+		timeout_base_divisor = 0;
+
+		do {
+			timeout_tick_us = 1000 * (16384 <<
+						  (timeout_base_divisor << 1)) /
+					  (bus->parent_clk_frequency / 1000);
+
+			if (timeout_base_divisor == div_max ||
+			    timeout_tick_us * ASPEED_I2CD_TIMEOUT_CYCLES_MASK >=
+			    bus->hw_timeout_ms * 1000)
+				break;
+		} while (timeout_base_divisor++ < div_max);
+
+		if (timeout_tick_us) {
+			timeout_cycles = DIV_ROUND_UP(bus->hw_timeout_ms * 1000,
+						      timeout_tick_us);
+			if (timeout_cycles == 0)
+				timeout_cycles = 1;
+			else if (timeout_cycles > cycles_max)
+				timeout_cycles = cycles_max;
+		} else {
+			timeout_cycles = 0;
+		}
+	} else {
+		timeout_base_divisor = 0;
+		timeout_cycles = 0;
+	}
+
+	clk_reg_val |= FIELD_PREP(ASPEED_I2CD_TIME_TIMEOUT_BASE_DIVISOR_MASK,
+				  timeout_base_divisor);
+
 	writel(clk_reg_val, bus->base + ASPEED_I2C_AC_TIMING_REG1);
-	writel(ASPEED_NO_TIMEOUT_CTRL, bus->base + ASPEED_I2C_AC_TIMING_REG2);
+	writel(timeout_cycles, bus->base + ASPEED_I2C_AC_TIMING_REG2);
 
 	return 0;
 }
@@ -899,6 +965,11 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus,
 	/* Disable everything. */
 	writel(0, bus->base + ASPEED_I2C_FUN_CTRL_REG);
 
+	device_property_read_u32(&pdev->dev, "aspeed,hw-timeout-ms",
+				 &bus->hw_timeout_ms);
+	if (bus->hw_timeout_ms)
+		fun_ctrl_reg |= ASPEED_I2CD_BUS_AUTO_RECOVERY_EN;
+
 	ret = aspeed_i2c_init_clk(bus);
 	if (ret < 0)
 		return ret;
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> Append a binding to support hardware timeout feature.
> 
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> index b47f6ccb196a..133bfedf4cdd 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> @@ -17,6 +17,8 @@ Optional Properties:
>  - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>  		  specified
>  - multi-master	: states that there is another master active on this bus.
> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> +			  specified, the H/W timeout feature will be disabled.
>  
>  Example:
>  
> 

Some SMBus clients support a smbus-timeout-disable binding for disabling
timeouts like this, for cases where the I2C adapter in question on occasion
is unable to keep the pace. Adding that property thus avoids undesired
timeouts when the client is SMBus conformant without it. Your new binding
is the reverse situation, where you want to add a timeout where one is
otherwise missing.

Anyway, since I2C does not have a specified lowest possible frequency, this
feels like something that is more in the SMBus arena. Should the property
perhaps be a generic property named smbus-timeout-ms, or something like
that?

If the above is not wanted or appropriate, then I would personally prefer
aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
like a (more serious) timeout between the CPU and the I2C peripheral unit
or something like that. But I don't care deeply...

Cheers,
Peter

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> Append a binding to support hardware timeout feature.
> 
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> index b47f6ccb196a..133bfedf4cdd 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> @@ -17,6 +17,8 @@ Optional Properties:
>  - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>  		  specified
>  - multi-master	: states that there is another master active on this bus.
> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> +			  specified, the H/W timeout feature will be disabled.
>  
>  Example:
>  
> 

Some SMBus clients support a smbus-timeout-disable binding for disabling
timeouts like this, for cases where the I2C adapter in question on occasion
is unable to keep the pace. Adding that property thus avoids undesired
timeouts when the client is SMBus conformant without it. Your new binding
is the reverse situation, where you want to add a timeout where one is
otherwise missing.

Anyway, since I2C does not have a specified lowest possible frequency, this
feels like something that is more in the SMBus arena. Should the property
perhaps be a generic property named smbus-timeout-ms, or something like
that?

If the above is not wanted or appropriate, then I would personally prefer
aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
like a (more serious) timeout between the CPU and the I2C peripheral unit
or something like that. But I don't care deeply...

Cheers,
Peter

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> Append a binding to support hardware timeout feature.
> 
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> index b47f6ccb196a..133bfedf4cdd 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> @@ -17,6 +17,8 @@ Optional Properties:
>  - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>  		  specified
>  - multi-master	: states that there is another master active on this bus.
> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> +			  specified, the H/W timeout feature will be disabled.
>  
>  Example:
>  
> 

Some SMBus clients support a smbus-timeout-disable binding for disabling
timeouts like this, for cases where the I2C adapter in question on occasion
is unable to keep the pace. Adding that property thus avoids undesired
timeouts when the client is SMBus conformant without it. Your new binding
is the reverse situation, where you want to add a timeout where one is
otherwise missing.

Anyway, since I2C does not have a specified lowest possible frequency, this
feels like something that is more in the SMBus arena. Should the property
perhaps be a generic property named smbus-timeout-ms, or something like
that?

If the above is not wanted or appropriate, then I would personally prefer
aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
like a (more serious) timeout between the CPU and the I2C peripheral unit
or something like that. But I don't care deeply...

Cheers,
Peter

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> Append a binding to support hardware timeout feature.
> 
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> index b47f6ccb196a..133bfedf4cdd 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> @@ -17,6 +17,8 @@ Optional Properties:
>  - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>  		  specified
>  - multi-master	: states that there is another master active on this bus.
> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> +			  specified, the H/W timeout feature will be disabled.
>  
>  Example:
>  
> 

Some SMBus clients support a smbus-timeout-disable binding for disabling
timeouts like this, for cases where the I2C adapter in question on occasion
is unable to keep the pace. Adding that property thus avoids undesired
timeouts when the client is SMBus conformant without it. Your new binding
is the reverse situation, where you want to add a timeout where one is
otherwise missing.

Anyway, since I2C does not have a specified lowest possible frequency, this
feels like something that is more in the SMBus arena. Should the property
perhaps be a generic property named smbus-timeout-ms, or something like
that?

If the above is not wanted or appropriate, then I would personally prefer
aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
like a (more serious) timeout between the CPU and the I2C peripheral unit
or something like that. But I don't care deeply...

Cheers,
Peter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Hi Peter,

On 10/21/2019 2:05 PM, Peter Rosin wrote:
> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>> Append a binding to support hardware timeout feature.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> index b47f6ccb196a..133bfedf4cdd 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> @@ -17,6 +17,8 @@ Optional Properties:
>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>   		  specified
>>   - multi-master	: states that there is another master active on this bus.
>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>> +			  specified, the H/W timeout feature will be disabled.
>>   
>>   Example:
>>   
>>
> 
> Some SMBus clients support a smbus-timeout-disable binding for disabling
> timeouts like this, for cases where the I2C adapter in question on occasion
> is unable to keep the pace. Adding that property thus avoids undesired
> timeouts when the client is SMBus conformant without it. Your new binding
> is the reverse situation, where you want to add a timeout where one is
> otherwise missing.
> 
> Anyway, since I2C does not have a specified lowest possible frequency, this
> feels like something that is more in the SMBus arena. Should the property
> perhaps be a generic property named smbus-timeout-ms, or something like
> that?

Well, I tried upstreaming of the generic timeout property a year ago but
I agreed that the generic bus timeout property can be set by an ioctl
command so it didn't need to be added into device tree at that time. Not
sure if any need has come recently but I haven't heard that. This driver
still uses the generic timeout property which is provided by i2c core
for handling command timeouts, and it's out of scope from this patch
series.

> If the above is not wanted or appropriate, then I would personally prefer
> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> like a (more serious) timeout between the CPU and the I2C peripheral unit
> or something like that. But I don't care deeply...

Changes I submitted in this patch set is for a different purpose which
is very Aspeed H/W specific, and actually it's a more serious timeout
setting indeed. If this H/W is used in multi-master environment, it
could meet a H/W hang that freezes itself in slave mode and it can't
escape from the state. To resolve the specific case, this H/W provides
self-recovery feature which monitors abnormal state of SDA, SCL and its
H/W state machine using the timeout setting to determine the escape
condition.

Generally, this H/W timeout value is smaller than the generic bus
timeout value (I'm using 300ms for the H/W timeout while I'm using 1
second for the generic bus timeout) so I think it should be
distinguished from the generic bus timeout.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Hi Peter,

On 10/21/2019 2:05 PM, Peter Rosin wrote:
> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>> Append a binding to support hardware timeout feature.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> index b47f6ccb196a..133bfedf4cdd 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> @@ -17,6 +17,8 @@ Optional Properties:
>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>   		  specified
>>   - multi-master	: states that there is another master active on this bus.
>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>> +			  specified, the H/W timeout feature will be disabled.
>>   
>>   Example:
>>   
>>
> 
> Some SMBus clients support a smbus-timeout-disable binding for disabling
> timeouts like this, for cases where the I2C adapter in question on occasion
> is unable to keep the pace. Adding that property thus avoids undesired
> timeouts when the client is SMBus conformant without it. Your new binding
> is the reverse situation, where you want to add a timeout where one is
> otherwise missing.
> 
> Anyway, since I2C does not have a specified lowest possible frequency, this
> feels like something that is more in the SMBus arena. Should the property
> perhaps be a generic property named smbus-timeout-ms, or something like
> that?

Well, I tried upstreaming of the generic timeout property a year ago but
I agreed that the generic bus timeout property can be set by an ioctl
command so it didn't need to be added into device tree at that time. Not
sure if any need has come recently but I haven't heard that. This driver
still uses the generic timeout property which is provided by i2c core
for handling command timeouts, and it's out of scope from this patch
series.

> If the above is not wanted or appropriate, then I would personally prefer
> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> like a (more serious) timeout between the CPU and the I2C peripheral unit
> or something like that. But I don't care deeply...

Changes I submitted in this patch set is for a different purpose which
is very Aspeed H/W specific, and actually it's a more serious timeout
setting indeed. If this H/W is used in multi-master environment, it
could meet a H/W hang that freezes itself in slave mode and it can't
escape from the state. To resolve the specific case, this H/W provides
self-recovery feature which monitors abnormal state of SDA, SCL and its
H/W state machine using the timeout setting to determine the escape
condition.

Generally, this H/W timeout value is smaller than the generic bus
timeout value (I'm using 300ms for the H/W timeout while I'm using 1
second for the generic bus timeout) so I think it should be
distinguished from the generic bus timeout.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Hi Peter,

On 10/21/2019 2:05 PM, Peter Rosin wrote:
> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>> Append a binding to support hardware timeout feature.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> index b47f6ccb196a..133bfedf4cdd 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> @@ -17,6 +17,8 @@ Optional Properties:
>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>   		  specified
>>   - multi-master	: states that there is another master active on this bus.
>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>> +			  specified, the H/W timeout feature will be disabled.
>>   
>>   Example:
>>   
>>
> 
> Some SMBus clients support a smbus-timeout-disable binding for disabling
> timeouts like this, for cases where the I2C adapter in question on occasion
> is unable to keep the pace. Adding that property thus avoids undesired
> timeouts when the client is SMBus conformant without it. Your new binding
> is the reverse situation, where you want to add a timeout where one is
> otherwise missing.
> 
> Anyway, since I2C does not have a specified lowest possible frequency, this
> feels like something that is more in the SMBus arena. Should the property
> perhaps be a generic property named smbus-timeout-ms, or something like
> that?

Well, I tried upstreaming of the generic timeout property a year ago but
I agreed that the generic bus timeout property can be set by an ioctl
command so it didn't need to be added into device tree at that time. Not
sure if any need has come recently but I haven't heard that. This driver
still uses the generic timeout property which is provided by i2c core
for handling command timeouts, and it's out of scope from this patch
series.

> If the above is not wanted or appropriate, then I would personally prefer
> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> like a (more serious) timeout between the CPU and the I2C peripheral unit
> or something like that. But I don't care deeply...

Changes I submitted in this patch set is for a different purpose which
is very Aspeed H/W specific, and actually it's a more serious timeout
setting indeed. If this H/W is used in multi-master environment, it
could meet a H/W hang that freezes itself in slave mode and it can't
escape from the state. To resolve the specific case, this H/W provides
self-recovery feature which monitors abnormal state of SDA, SCL and its
H/W state machine using the timeout setting to determine the escape
condition.

Generally, this H/W timeout value is smaller than the generic bus
timeout value (I'm using 300ms for the H/W timeout while I'm using 1
second for the generic bus timeout) so I think it should be
distinguished from the generic bus timeout.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

Hi Peter,

On 10/21/2019 2:05 PM, Peter Rosin wrote:
> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>> Append a binding to support hardware timeout feature.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> index b47f6ccb196a..133bfedf4cdd 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>> @@ -17,6 +17,8 @@ Optional Properties:
>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>   		  specified
>>   - multi-master	: states that there is another master active on this bus.
>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>> +			  specified, the H/W timeout feature will be disabled.
>>   
>>   Example:
>>   
>>
> 
> Some SMBus clients support a smbus-timeout-disable binding for disabling
> timeouts like this, for cases where the I2C adapter in question on occasion
> is unable to keep the pace. Adding that property thus avoids undesired
> timeouts when the client is SMBus conformant without it. Your new binding
> is the reverse situation, where you want to add a timeout where one is
> otherwise missing.
> 
> Anyway, since I2C does not have a specified lowest possible frequency, this
> feels like something that is more in the SMBus arena. Should the property
> perhaps be a generic property named smbus-timeout-ms, or something like
> that?

Well, I tried upstreaming of the generic timeout property a year ago but
I agreed that the generic bus timeout property can be set by an ioctl
command so it didn't need to be added into device tree at that time. Not
sure if any need has come recently but I haven't heard that. This driver
still uses the generic timeout property which is provided by i2c core
for handling command timeouts, and it's out of scope from this patch
series.

> If the above is not wanted or appropriate, then I would personally prefer
> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> like a (more serious) timeout between the CPU and the I2C peripheral unit
> or something like that. But I don't care deeply...

Changes I submitted in this patch set is for a different purpose which
is very Aspeed H/W specific, and actually it's a more serious timeout
setting indeed. If this H/W is used in multi-master environment, it
could meet a H/W hang that freezes itself in slave mode and it can't
escape from the state. To resolve the specific case, this H/W provides
self-recovery feature which monitors abnormal state of SDA, SCL and its
H/W state machine using the timeout setting to determine the escape
condition.

Generally, this H/W timeout value is smaller than the generic bus
timeout value (I'm using 300ms for the H/W timeout while I'm using 1
second for the generic bus timeout) so I think it should be
distinguished from the generic bus timeout.

Thanks,

Jae

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]


> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Thanks for the summary. I just wonder on what the timeout value depends.
Do we really need to put in DT or can we derive it e.g. from the
compatible value in the driver?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 689 bytes --]


> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Thanks for the summary. I just wonder on what the timeout value depends.
Do we really need to put in DT or can we derive it e.g. from the
compatible value in the driver?


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]


> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Thanks for the summary. I just wonder on what the timeout value depends.
Do we really need to put in DT or can we derive it e.g. from the
compatible value in the driver?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> Hi Peter,
> 
> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>> Append a binding to support hardware timeout feature.
>>>
>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>> ---
>>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> index b47f6ccb196a..133bfedf4cdd 100644
>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>   		  specified
>>>   - multi-master	: states that there is another master active on this bus.
>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>> +			  specified, the H/W timeout feature will be disabled.
>>>   
>>>   Example:
>>>   
>>>
>>
>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>> timeouts like this, for cases where the I2C adapter in question on occasion
>> is unable to keep the pace. Adding that property thus avoids undesired
>> timeouts when the client is SMBus conformant without it. Your new binding
>> is the reverse situation, where you want to add a timeout where one is
>> otherwise missing.
>>
>> Anyway, since I2C does not have a specified lowest possible frequency, this
>> feels like something that is more in the SMBus arena. Should the property
>> perhaps be a generic property named smbus-timeout-ms, or something like
>> that?
> 
> Well, I tried upstreaming of the generic timeout property a year ago but
> I agreed that the generic bus timeout property can be set by an ioctl
> command so it didn't need to be added into device tree at that time. Not
> sure if any need has come recently but I haven't heard that. This driver
> still uses the generic timeout property which is provided by i2c core
> for handling command timeouts, and it's out of scope from this patch
> series.
> 
>> If the above is not wanted or appropriate, then I would personally prefer
>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>> or something like that. But I don't care deeply...
> 
> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Are you saying that the aspeed HW is buggy and that this abnormal state
is self inflicted by the aspeed HW even if other masters on the bus
behave sanely? Because I didn't quite read it that way at all...

To me, it sounded *exactly* like the state I2C clients end up in when an
I2C master "dies" and stops communicating in the middle of a transaction.
I.e. the thing that the SMBus timeout is designed to prevent (and the
state the I2C nine-clk-recovery sequence addresses). The only twist (that
I saw) was that the aspeed HW is also a master and that the aspeed master
driver is completely locked out from the bus while some obnoxious master
fails to complete its transaction (or whatever it was up to).

If this can only be triggered when the HW is acting as a slave, and by
aborted or otherwise funky master activity on the bus, then I wouldn't
call it an HW issue. Then it would be a bus issue. I.e. something needing
a bus-timeout instead of a hw-timeout.

I don't have the specifics, so I can't tell which way it is. I'm just
reacting to the presented information.

Cheers,
Peter

> Generally, this H/W timeout value is smaller than the generic bus
> timeout value (I'm using 300ms for the H/W timeout while I'm using 1
> second for the generic bus timeout) so I think it should be
> distinguished from the generic bus timeout.
> 
> Thanks,
> 
> Jae
> 

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> Hi Peter,
> 
> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>> Append a binding to support hardware timeout feature.
>>>
>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>> ---
>>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> index b47f6ccb196a..133bfedf4cdd 100644
>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>   		  specified
>>>   - multi-master	: states that there is another master active on this bus.
>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>> +			  specified, the H/W timeout feature will be disabled.
>>>   
>>>   Example:
>>>   
>>>
>>
>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>> timeouts like this, for cases where the I2C adapter in question on occasion
>> is unable to keep the pace. Adding that property thus avoids undesired
>> timeouts when the client is SMBus conformant without it. Your new binding
>> is the reverse situation, where you want to add a timeout where one is
>> otherwise missing.
>>
>> Anyway, since I2C does not have a specified lowest possible frequency, this
>> feels like something that is more in the SMBus arena. Should the property
>> perhaps be a generic property named smbus-timeout-ms, or something like
>> that?
> 
> Well, I tried upstreaming of the generic timeout property a year ago but
> I agreed that the generic bus timeout property can be set by an ioctl
> command so it didn't need to be added into device tree at that time. Not
> sure if any need has come recently but I haven't heard that. This driver
> still uses the generic timeout property which is provided by i2c core
> for handling command timeouts, and it's out of scope from this patch
> series.
> 
>> If the above is not wanted or appropriate, then I would personally prefer
>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>> or something like that. But I don't care deeply...
> 
> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Are you saying that the aspeed HW is buggy and that this abnormal state
is self inflicted by the aspeed HW even if other masters on the bus
behave sanely? Because I didn't quite read it that way at all...

To me, it sounded *exactly* like the state I2C clients end up in when an
I2C master "dies" and stops communicating in the middle of a transaction.
I.e. the thing that the SMBus timeout is designed to prevent (and the
state the I2C nine-clk-recovery sequence addresses). The only twist (that
I saw) was that the aspeed HW is also a master and that the aspeed master
driver is completely locked out from the bus while some obnoxious master
fails to complete its transaction (or whatever it was up to).

If this can only be triggered when the HW is acting as a slave, and by
aborted or otherwise funky master activity on the bus, then I wouldn't
call it an HW issue. Then it would be a bus issue. I.e. something needing
a bus-timeout instead of a hw-timeout.

I don't have the specifics, so I can't tell which way it is. I'm just
reacting to the presented information.

Cheers,
Peter

> Generally, this H/W timeout value is smaller than the generic bus
> timeout value (I'm using 300ms for the H/W timeout while I'm using 1
> second for the generic bus timeout) so I think it should be
> distinguished from the generic bus timeout.
> 
> Thanks,
> 
> Jae
> 

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> Hi Peter,
> 
> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>> Append a binding to support hardware timeout feature.
>>>
>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>> ---
>>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> index b47f6ccb196a..133bfedf4cdd 100644
>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>   		  specified
>>>   - multi-master	: states that there is another master active on this bus.
>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>> +			  specified, the H/W timeout feature will be disabled.
>>>   
>>>   Example:
>>>   
>>>
>>
>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>> timeouts like this, for cases where the I2C adapter in question on occasion
>> is unable to keep the pace. Adding that property thus avoids undesired
>> timeouts when the client is SMBus conformant without it. Your new binding
>> is the reverse situation, where you want to add a timeout where one is
>> otherwise missing.
>>
>> Anyway, since I2C does not have a specified lowest possible frequency, this
>> feels like something that is more in the SMBus arena. Should the property
>> perhaps be a generic property named smbus-timeout-ms, or something like
>> that?
> 
> Well, I tried upstreaming of the generic timeout property a year ago but
> I agreed that the generic bus timeout property can be set by an ioctl
> command so it didn't need to be added into device tree at that time. Not
> sure if any need has come recently but I haven't heard that. This driver
> still uses the generic timeout property which is provided by i2c core
> for handling command timeouts, and it's out of scope from this patch
> series.
> 
>> If the above is not wanted or appropriate, then I would personally prefer
>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>> or something like that. But I don't care deeply...
> 
> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Are you saying that the aspeed HW is buggy and that this abnormal state
is self inflicted by the aspeed HW even if other masters on the bus
behave sanely? Because I didn't quite read it that way at all...

To me, it sounded *exactly* like the state I2C clients end up in when an
I2C master "dies" and stops communicating in the middle of a transaction.
I.e. the thing that the SMBus timeout is designed to prevent (and the
state the I2C nine-clk-recovery sequence addresses). The only twist (that
I saw) was that the aspeed HW is also a master and that the aspeed master
driver is completely locked out from the bus while some obnoxious master
fails to complete its transaction (or whatever it was up to).

If this can only be triggered when the HW is acting as a slave, and by
aborted or otherwise funky master activity on the bus, then I wouldn't
call it an HW issue. Then it would be a bus issue. I.e. something needing
a bus-timeout instead of a hw-timeout.

I don't have the specifics, so I can't tell which way it is. I'm just
reacting to the presented information.

Cheers,
Peter

> Generally, this H/W timeout value is smaller than the generic bus
> timeout value (I'm using 300ms for the H/W timeout while I'm using 1
> second for the generic bus timeout) so I think it should be
> distinguished from the generic bus timeout.
> 
> Thanks,
> 
> Jae
> 

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> Hi Peter,
> 
> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>> Append a binding to support hardware timeout feature.
>>>
>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>> ---
>>>   Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> index b47f6ccb196a..133bfedf4cdd 100644
>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>   - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>   		  specified
>>>   - multi-master	: states that there is another master active on this bus.
>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>> +			  specified, the H/W timeout feature will be disabled.
>>>   
>>>   Example:
>>>   
>>>
>>
>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>> timeouts like this, for cases where the I2C adapter in question on occasion
>> is unable to keep the pace. Adding that property thus avoids undesired
>> timeouts when the client is SMBus conformant without it. Your new binding
>> is the reverse situation, where you want to add a timeout where one is
>> otherwise missing.
>>
>> Anyway, since I2C does not have a specified lowest possible frequency, this
>> feels like something that is more in the SMBus arena. Should the property
>> perhaps be a generic property named smbus-timeout-ms, or something like
>> that?
> 
> Well, I tried upstreaming of the generic timeout property a year ago but
> I agreed that the generic bus timeout property can be set by an ioctl
> command so it didn't need to be added into device tree at that time. Not
> sure if any need has come recently but I haven't heard that. This driver
> still uses the generic timeout property which is provided by i2c core
> for handling command timeouts, and it's out of scope from this patch
> series.
> 
>> If the above is not wanted or appropriate, then I would personally prefer
>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>> or something like that. But I don't care deeply...
> 
> Changes I submitted in this patch set is for a different purpose which
> is very Aspeed H/W specific, and actually it's a more serious timeout
> setting indeed. If this H/W is used in multi-master environment, it
> could meet a H/W hang that freezes itself in slave mode and it can't
> escape from the state. To resolve the specific case, this H/W provides
> self-recovery feature which monitors abnormal state of SDA, SCL and its
> H/W state machine using the timeout setting to determine the escape
> condition.

Are you saying that the aspeed HW is buggy and that this abnormal state
is self inflicted by the aspeed HW even if other masters on the bus
behave sanely? Because I didn't quite read it that way at all...

To me, it sounded *exactly* like the state I2C clients end up in when an
I2C master "dies" and stops communicating in the middle of a transaction.
I.e. the thing that the SMBus timeout is designed to prevent (and the
state the I2C nine-clk-recovery sequence addresses). The only twist (that
I saw) was that the aspeed HW is also a master and that the aspeed master
driver is completely locked out from the bus while some obnoxious master
fails to complete its transaction (or whatever it was up to).

If this can only be triggered when the HW is acting as a slave, and by
aborted or otherwise funky master activity on the bus, then I wouldn't
call it an HW issue. Then it would be a bus issue. I.e. something needing
a bus-timeout instead of a hw-timeout.

I don't have the specifics, so I can't tell which way it is. I'm just
reacting to the presented information.

Cheers,
Peter

> Generally, this H/W timeout value is smaller than the generic bus
> timeout value (I'm using 300ms for the H/W timeout while I'm using 1
> second for the generic bus timeout) so I think it should be
> distinguished from the generic bus timeout.
> 
> Thanks,
> 
> Jae
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/21/2019 9:56 PM, Wolfram Sang wrote:
> 
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Thanks for the summary. I just wonder on what the timeout value depends.
> Do we really need to put in DT or can we derive it e.g. from the
> compatible value in the driver?

It could be derived from the bus timeout value by computing 'divide by
x' roughly but it couldn't cover all use cases because this H/W timeout
value would depends on each environment. There are many factors that
can affect it such as bus speed, peer-master's bus driving
characteristic, average transaction period on the bus and so on thus
it may need fine adjustments through a DT setting, I think.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/21/2019 9:56 PM, Wolfram Sang wrote:
> 
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Thanks for the summary. I just wonder on what the timeout value depends.
> Do we really need to put in DT or can we derive it e.g. from the
> compatible value in the driver?

It could be derived from the bus timeout value by computing 'divide by
x' roughly but it couldn't cover all use cases because this H/W timeout
value would depends on each environment. There are many factors that
can affect it such as bus speed, peer-master's bus driving
characteristic, average transaction period on the bus and so on thus
it may need fine adjustments through a DT setting, I think.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/21/2019 9:56 PM, Wolfram Sang wrote:
> 
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Thanks for the summary. I just wonder on what the timeout value depends.
> Do we really need to put in DT or can we derive it e.g. from the
> compatible value in the driver?

It could be derived from the bus timeout value by computing 'divide by
x' roughly but it couldn't cover all use cases because this H/W timeout
value would depends on each environment. There are many factors that
can affect it such as bus speed, peer-master's bus driving
characteristic, average transaction period on the bus and so on thus
it may need fine adjustments through a DT setting, I think.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/21/2019 9:56 PM, Wolfram Sang wrote:
> 
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Thanks for the summary. I just wonder on what the timeout value depends.
> Do we really need to put in DT or can we derive it e.g. from the
> compatible value in the driver?

It could be derived from the bus timeout value by computing 'divide by
x' roughly but it couldn't cover all use cases because this H/W timeout
value would depends on each environment. There are many factors that
can affect it such as bus speed, peer-master's bus driving
characteristic, average transaction period on the bus and so on thus
it may need fine adjustments through a DT setting, I think.

Thanks,

Jae

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/22/2019 1:45 AM, Peter Rosin wrote:
> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>> Hi Peter,
>>
>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>> Append a binding to support hardware timeout feature.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>    		  specified
>>>>    - multi-master	: states that there is another master active on this bus.
>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>    
>>>>    Example:
>>>>    
>>>>
>>>
>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>> is unable to keep the pace. Adding that property thus avoids undesired
>>> timeouts when the client is SMBus conformant without it. Your new binding
>>> is the reverse situation, where you want to add a timeout where one is
>>> otherwise missing.
>>>
>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>> feels like something that is more in the SMBus arena. Should the property
>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>> that?
>>
>> Well, I tried upstreaming of the generic timeout property a year ago but
>> I agreed that the generic bus timeout property can be set by an ioctl
>> command so it didn't need to be added into device tree at that time. Not
>> sure if any need has come recently but I haven't heard that. This driver
>> still uses the generic timeout property which is provided by i2c core
>> for handling command timeouts, and it's out of scope from this patch
>> series.
>>
>>> If the above is not wanted or appropriate, then I would personally prefer
>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>> or something like that. But I don't care deeply...
>>
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Are you saying that the aspeed HW is buggy and that this abnormal state
> is self inflicted by the aspeed HW even if other masters on the bus
> behave sanely? Because I didn't quite read it that way at all...

I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
very severe environments if it is used as a Baseboard Management
Controller which needs two or more multi-masters on a bus depends on
HW design. Also, it should expect unknown or buggy device attachment
on a bus through add-on card slots. Aspeed HW provides HW timeout
feature to support exceptional cases handling which comes from the
severe use cases.

> To me, it sounded *exactly* like the state I2C clients end up in when an
> I2C master "dies" and stops communicating in the middle of a transaction.
> I.e. the thing that the SMBus timeout is designed to prevent (and the
> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> I saw) was that the aspeed HW is also a master and that the aspeed master
> driver is completely locked out from the bus while some obnoxious master
> fails to complete its transaction (or whatever it was up to).

If this HW runs on a single-master bus, any master dying issue will be
cured by recovery logic which this driver already has and the logic uses
the bus timeout setting you are saying.

This patch set is mainly focusing on a 'slave mode hang' issue on a
'multi-master' bus which can't be covered by the recovery logic.

> If this can only be triggered when the HW is acting as a slave, and by
> aborted or otherwise funky master activity on the bus, then I wouldn't
> call it an HW issue. Then it would be a bus issue. I.e. something needing
> a bus-timeout instead of a hw-timeout.

Here is an example. In a multi-node BMC system, a peer master can be
shutdown in the middle of transaction, then this Aspeed HW keeps waiting
for a next event from the peer master but it can't happen because the
peer master was already shutdown. If we enable the 'slave inactive
timeout feature' using the HW timeout setting, the this HW can escape
from the waiting state. If we don't, this HW hangs forever in the
waiting state and it's the reason why I implemented this patch set.

The hw-timeout setting needs fine tuning depends on HW environment so
it should be different from the bus-timeout.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/22/2019 1:45 AM, Peter Rosin wrote:
> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>> Hi Peter,
>>
>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>> Append a binding to support hardware timeout feature.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>    		  specified
>>>>    - multi-master	: states that there is another master active on this bus.
>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>    
>>>>    Example:
>>>>    
>>>>
>>>
>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>> is unable to keep the pace. Adding that property thus avoids undesired
>>> timeouts when the client is SMBus conformant without it. Your new binding
>>> is the reverse situation, where you want to add a timeout where one is
>>> otherwise missing.
>>>
>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>> feels like something that is more in the SMBus arena. Should the property
>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>> that?
>>
>> Well, I tried upstreaming of the generic timeout property a year ago but
>> I agreed that the generic bus timeout property can be set by an ioctl
>> command so it didn't need to be added into device tree at that time. Not
>> sure if any need has come recently but I haven't heard that. This driver
>> still uses the generic timeout property which is provided by i2c core
>> for handling command timeouts, and it's out of scope from this patch
>> series.
>>
>>> If the above is not wanted or appropriate, then I would personally prefer
>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>> or something like that. But I don't care deeply...
>>
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Are you saying that the aspeed HW is buggy and that this abnormal state
> is self inflicted by the aspeed HW even if other masters on the bus
> behave sanely? Because I didn't quite read it that way at all...

I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
very severe environments if it is used as a Baseboard Management
Controller which needs two or more multi-masters on a bus depends on
HW design. Also, it should expect unknown or buggy device attachment
on a bus through add-on card slots. Aspeed HW provides HW timeout
feature to support exceptional cases handling which comes from the
severe use cases.

> To me, it sounded *exactly* like the state I2C clients end up in when an
> I2C master "dies" and stops communicating in the middle of a transaction.
> I.e. the thing that the SMBus timeout is designed to prevent (and the
> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> I saw) was that the aspeed HW is also a master and that the aspeed master
> driver is completely locked out from the bus while some obnoxious master
> fails to complete its transaction (or whatever it was up to).

If this HW runs on a single-master bus, any master dying issue will be
cured by recovery logic which this driver already has and the logic uses
the bus timeout setting you are saying.

This patch set is mainly focusing on a 'slave mode hang' issue on a
'multi-master' bus which can't be covered by the recovery logic.

> If this can only be triggered when the HW is acting as a slave, and by
> aborted or otherwise funky master activity on the bus, then I wouldn't
> call it an HW issue. Then it would be a bus issue. I.e. something needing
> a bus-timeout instead of a hw-timeout.

Here is an example. In a multi-node BMC system, a peer master can be
shutdown in the middle of transaction, then this Aspeed HW keeps waiting
for a next event from the peer master but it can't happen because the
peer master was already shutdown. If we enable the 'slave inactive
timeout feature' using the HW timeout setting, the this HW can escape
from the waiting state. If we don't, this HW hangs forever in the
waiting state and it's the reason why I implemented this patch set.

The hw-timeout setting needs fine tuning depends on HW environment so
it should be different from the bus-timeout.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/22/2019 1:45 AM, Peter Rosin wrote:
> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>> Hi Peter,
>>
>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>> Append a binding to support hardware timeout feature.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>    		  specified
>>>>    - multi-master	: states that there is another master active on this bus.
>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>    
>>>>    Example:
>>>>    
>>>>
>>>
>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>> is unable to keep the pace. Adding that property thus avoids undesired
>>> timeouts when the client is SMBus conformant without it. Your new binding
>>> is the reverse situation, where you want to add a timeout where one is
>>> otherwise missing.
>>>
>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>> feels like something that is more in the SMBus arena. Should the property
>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>> that?
>>
>> Well, I tried upstreaming of the generic timeout property a year ago but
>> I agreed that the generic bus timeout property can be set by an ioctl
>> command so it didn't need to be added into device tree at that time. Not
>> sure if any need has come recently but I haven't heard that. This driver
>> still uses the generic timeout property which is provided by i2c core
>> for handling command timeouts, and it's out of scope from this patch
>> series.
>>
>>> If the above is not wanted or appropriate, then I would personally prefer
>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>> or something like that. But I don't care deeply...
>>
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Are you saying that the aspeed HW is buggy and that this abnormal state
> is self inflicted by the aspeed HW even if other masters on the bus
> behave sanely? Because I didn't quite read it that way at all...

I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
very severe environments if it is used as a Baseboard Management
Controller which needs two or more multi-masters on a bus depends on
HW design. Also, it should expect unknown or buggy device attachment
on a bus through add-on card slots. Aspeed HW provides HW timeout
feature to support exceptional cases handling which comes from the
severe use cases.

> To me, it sounded *exactly* like the state I2C clients end up in when an
> I2C master "dies" and stops communicating in the middle of a transaction.
> I.e. the thing that the SMBus timeout is designed to prevent (and the
> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> I saw) was that the aspeed HW is also a master and that the aspeed master
> driver is completely locked out from the bus while some obnoxious master
> fails to complete its transaction (or whatever it was up to).

If this HW runs on a single-master bus, any master dying issue will be
cured by recovery logic which this driver already has and the logic uses
the bus timeout setting you are saying.

This patch set is mainly focusing on a 'slave mode hang' issue on a
'multi-master' bus which can't be covered by the recovery logic.

> If this can only be triggered when the HW is acting as a slave, and by
> aborted or otherwise funky master activity on the bus, then I wouldn't
> call it an HW issue. Then it would be a bus issue. I.e. something needing
> a bus-timeout instead of a hw-timeout.

Here is an example. In a multi-node BMC system, a peer master can be
shutdown in the middle of transaction, then this Aspeed HW keeps waiting
for a next event from the peer master but it can't happen because the
peer master was already shutdown. If we enable the 'slave inactive
timeout feature' using the HW timeout setting, the this HW can escape
from the waiting state. If we don't, this HW hangs forever in the
waiting state and it's the reason why I implemented this patch set.

The hw-timeout setting needs fine tuning depends on HW environment so
it should be different from the bus-timeout.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/22/2019 1:45 AM, Peter Rosin wrote:
> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>> Hi Peter,
>>
>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>> Append a binding to support hardware timeout feature.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>    		  specified
>>>>    - multi-master	: states that there is another master active on this bus.
>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>    
>>>>    Example:
>>>>    
>>>>
>>>
>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>> is unable to keep the pace. Adding that property thus avoids undesired
>>> timeouts when the client is SMBus conformant without it. Your new binding
>>> is the reverse situation, where you want to add a timeout where one is
>>> otherwise missing.
>>>
>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>> feels like something that is more in the SMBus arena. Should the property
>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>> that?
>>
>> Well, I tried upstreaming of the generic timeout property a year ago but
>> I agreed that the generic bus timeout property can be set by an ioctl
>> command so it didn't need to be added into device tree at that time. Not
>> sure if any need has come recently but I haven't heard that. This driver
>> still uses the generic timeout property which is provided by i2c core
>> for handling command timeouts, and it's out of scope from this patch
>> series.
>>
>>> If the above is not wanted or appropriate, then I would personally prefer
>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>> or something like that. But I don't care deeply...
>>
>> Changes I submitted in this patch set is for a different purpose which
>> is very Aspeed H/W specific, and actually it's a more serious timeout
>> setting indeed. If this H/W is used in multi-master environment, it
>> could meet a H/W hang that freezes itself in slave mode and it can't
>> escape from the state. To resolve the specific case, this H/W provides
>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>> H/W state machine using the timeout setting to determine the escape
>> condition.
> 
> Are you saying that the aspeed HW is buggy and that this abnormal state
> is self inflicted by the aspeed HW even if other masters on the bus
> behave sanely? Because I didn't quite read it that way at all...

I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
very severe environments if it is used as a Baseboard Management
Controller which needs two or more multi-masters on a bus depends on
HW design. Also, it should expect unknown or buggy device attachment
on a bus through add-on card slots. Aspeed HW provides HW timeout
feature to support exceptional cases handling which comes from the
severe use cases.

> To me, it sounded *exactly* like the state I2C clients end up in when an
> I2C master "dies" and stops communicating in the middle of a transaction.
> I.e. the thing that the SMBus timeout is designed to prevent (and the
> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> I saw) was that the aspeed HW is also a master and that the aspeed master
> driver is completely locked out from the bus while some obnoxious master
> fails to complete its transaction (or whatever it was up to).

If this HW runs on a single-master bus, any master dying issue will be
cured by recovery logic which this driver already has and the logic uses
the bus timeout setting you are saying.

This patch set is mainly focusing on a 'slave mode hang' issue on a
'multi-master' bus which can't be covered by the recovery logic.

> If this can only be triggered when the HW is acting as a slave, and by
> aborted or otherwise funky master activity on the bus, then I wouldn't
> call it an HW issue. Then it would be a bus issue. I.e. something needing
> a bus-timeout instead of a hw-timeout.

Here is an example. In a multi-node BMC system, a peer master can be
shutdown in the middle of transaction, then this Aspeed HW keeps waiting
for a next event from the peer master but it can't happen because the
peer master was already shutdown. If we enable the 'slave inactive
timeout feature' using the HW timeout setting, the this HW can escape
from the waiting state. If we don't, this HW hangs forever in the
waiting state and it's the reason why I implemented this patch set.

The hw-timeout setting needs fine tuning depends on HW environment so
it should be different from the bus-timeout.

Thanks,

Jae

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>> Hi Peter,
>>>
>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>> Append a binding to support hardware timeout feature.
>>>>>
>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>    		  specified
>>>>>    - multi-master	: states that there is another master active on this bus.
>>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>>    
>>>>>    Example:
>>>>>    
>>>>>
>>>>
>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>> is the reverse situation, where you want to add a timeout where one is
>>>> otherwise missing.
>>>>
>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>> feels like something that is more in the SMBus arena. Should the property
>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>> that?
>>>
>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>> I agreed that the generic bus timeout property can be set by an ioctl
>>> command so it didn't need to be added into device tree at that time. Not
>>> sure if any need has come recently but I haven't heard that. This driver
>>> still uses the generic timeout property which is provided by i2c core
>>> for handling command timeouts, and it's out of scope from this patch
>>> series.
>>>
>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>> or something like that. But I don't care deeply...
>>>
>>> Changes I submitted in this patch set is for a different purpose which
>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>> setting indeed. If this H/W is used in multi-master environment, it
>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>> escape from the state. To resolve the specific case, this H/W provides
>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>> H/W state machine using the timeout setting to determine the escape
>>> condition.
>>
>> Are you saying that the aspeed HW is buggy and that this abnormal state
>> is self inflicted by the aspeed HW even if other masters on the bus
>> behave sanely? Because I didn't quite read it that way at all...
> 
> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> very severe environments if it is used as a Baseboard Management
> Controller which needs two or more multi-masters on a bus depends on
> HW design. Also, it should expect unknown or buggy device attachment
> on a bus through add-on card slots. Aspeed HW provides HW timeout
> feature to support exceptional cases handling which comes from the
> severe use cases.
> 
>> To me, it sounded *exactly* like the state I2C clients end up in when an
>> I2C master "dies" and stops communicating in the middle of a transaction.
>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>> I saw) was that the aspeed HW is also a master and that the aspeed master
>> driver is completely locked out from the bus while some obnoxious master
>> fails to complete its transaction (or whatever it was up to).
> 
> If this HW runs on a single-master bus, any master dying issue will be
> cured by recovery logic which this driver already has and the logic uses
> the bus timeout setting you are saying.
> 
> This patch set is mainly focusing on a 'slave mode hang' issue on a
> 'multi-master' bus which can't be covered by the recovery logic.
> 
>> If this can only be triggered when the HW is acting as a slave, and by
>> aborted or otherwise funky master activity on the bus, then I wouldn't
>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>> a bus-timeout instead of a hw-timeout.
> 
> Here is an example. In a multi-node BMC system, a peer master can be
> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> for a next event from the peer master but it can't happen because the
> peer master was already shutdown. If we enable the 'slave inactive
> timeout feature' using the HW timeout setting, the this HW can escape
> from the waiting state. If we don't, this HW hangs forever in the
> waiting state and it's the reason why I implemented this patch set.
> 
> The hw-timeout setting needs fine tuning depends on HW environment so
> it should be different from the bus-timeout.

Yeah, ok, so you're basically confirming everything I said. I do
sense some confusion though, as you come across as a bit
defensive and seem to think that I am against the whole notion of
the patches. And that's not the case at all! My only issue is
with the naming. And I happen to think hw-timeout-ms is a really
bad name. It's way too broad and can mean just about anything.
When I read that, I think of some workaround for broken hardware,
not normal things like the other masters on the bus doing
confusing things. Funky bus activity from remote masters is
simply not an HW issue in my book, at least not an HW issue on
the local side of the bus. It's just something you *must expect*.

Let me list some scenarios, so that I can describe why I came up
with my suggested alternate naming:

Suppose you have a simple setup with a bus featuring a single
aspeed master and a single slave. If the slave is, say, a jc42
temperature sensor, then it by default will follow the SMBus spec
and implement a bus timeout. Meaning that if the master is
stalling for too long, then the jc42 slave will timeout the
transaction and make itself available to any potential other
masters on the bus. The jc42 chip does not know that it is on a
single master bus. But this is only the default, you can tell the
jc42 driver to disable this timeout, which is sometimes crucial
for reliable behavior, e.g. if the master is not always able to
keep the deadlines for whatever reason.

Next scenario. Suppose you have a simple setup with a bus
featuring a single remote master of some sort and the aspeed
acting as slave only. Since there is only a single master, and
there are no other slaves on the bus, there's no point for the
aspeed to act as master. The aspeed without your patches behave
as the jc42 chip above, when it has been instructed to /remove
the timeout/. And that's fine in this scenario since there is
only one master and the aspeed, as slave, can defer recovering
the bus to that master. So, when aspeed is operating as
slave-only, these patches enable the addition of the same timeout
that was there by default in the first scenario.

Final scenario, some as last but with some other slave(s) on the
bus. Now, it becomes interesting for the aspeed to act as master,
and it becomes interesting indeed to have a timeout that "breaks
out" when some remote master hogs the aspeed in slave mode.

I claim that the timeouts mentioned in all these scenarios are
related. In the first scenario, you disable the timeout by adding
smbus-timeout-disable to the relevant device tree node. I was
merely suggesting that, since the timeouts are basically doing
the same thing in all scenarios, the naming should perhaps be
consistent and be something more specific than hw-timeout-ms. What
popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
remote-timeout-ms, or something, would also work...

Note that the timeouts I'm talking about has nothing to do with
the adapter timeout in the linux I2C core. This is all about
timeouts when acting as I2C slave and the remote master fails to
complete (or otherwise messes up) transfers.

I hope that clarifies my position!

Cheers,
Peter

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>> Hi Peter,
>>>
>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>> Append a binding to support hardware timeout feature.
>>>>>
>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>    		  specified
>>>>>    - multi-master	: states that there is another master active on this bus.
>>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>>    
>>>>>    Example:
>>>>>    
>>>>>
>>>>
>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>> is the reverse situation, where you want to add a timeout where one is
>>>> otherwise missing.
>>>>
>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>> feels like something that is more in the SMBus arena. Should the property
>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>> that?
>>>
>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>> I agreed that the generic bus timeout property can be set by an ioctl
>>> command so it didn't need to be added into device tree at that time. Not
>>> sure if any need has come recently but I haven't heard that. This driver
>>> still uses the generic timeout property which is provided by i2c core
>>> for handling command timeouts, and it's out of scope from this patch
>>> series.
>>>
>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>> or something like that. But I don't care deeply...
>>>
>>> Changes I submitted in this patch set is for a different purpose which
>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>> setting indeed. If this H/W is used in multi-master environment, it
>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>> escape from the state. To resolve the specific case, this H/W provides
>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>> H/W state machine using the timeout setting to determine the escape
>>> condition.
>>
>> Are you saying that the aspeed HW is buggy and that this abnormal state
>> is self inflicted by the aspeed HW even if other masters on the bus
>> behave sanely? Because I didn't quite read it that way at all...
> 
> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> very severe environments if it is used as a Baseboard Management
> Controller which needs two or more multi-masters on a bus depends on
> HW design. Also, it should expect unknown or buggy device attachment
> on a bus through add-on card slots. Aspeed HW provides HW timeout
> feature to support exceptional cases handling which comes from the
> severe use cases.
> 
>> To me, it sounded *exactly* like the state I2C clients end up in when an
>> I2C master "dies" and stops communicating in the middle of a transaction.
>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>> I saw) was that the aspeed HW is also a master and that the aspeed master
>> driver is completely locked out from the bus while some obnoxious master
>> fails to complete its transaction (or whatever it was up to).
> 
> If this HW runs on a single-master bus, any master dying issue will be
> cured by recovery logic which this driver already has and the logic uses
> the bus timeout setting you are saying.
> 
> This patch set is mainly focusing on a 'slave mode hang' issue on a
> 'multi-master' bus which can't be covered by the recovery logic.
> 
>> If this can only be triggered when the HW is acting as a slave, and by
>> aborted or otherwise funky master activity on the bus, then I wouldn't
>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>> a bus-timeout instead of a hw-timeout.
> 
> Here is an example. In a multi-node BMC system, a peer master can be
> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> for a next event from the peer master but it can't happen because the
> peer master was already shutdown. If we enable the 'slave inactive
> timeout feature' using the HW timeout setting, the this HW can escape
> from the waiting state. If we don't, this HW hangs forever in the
> waiting state and it's the reason why I implemented this patch set.
> 
> The hw-timeout setting needs fine tuning depends on HW environment so
> it should be different from the bus-timeout.

Yeah, ok, so you're basically confirming everything I said. I do
sense some confusion though, as you come across as a bit
defensive and seem to think that I am against the whole notion of
the patches. And that's not the case at all! My only issue is
with the naming. And I happen to think hw-timeout-ms is a really
bad name. It's way too broad and can mean just about anything.
When I read that, I think of some workaround for broken hardware,
not normal things like the other masters on the bus doing
confusing things. Funky bus activity from remote masters is
simply not an HW issue in my book, at least not an HW issue on
the local side of the bus. It's just something you *must expect*.

Let me list some scenarios, so that I can describe why I came up
with my suggested alternate naming:

Suppose you have a simple setup with a bus featuring a single
aspeed master and a single slave. If the slave is, say, a jc42
temperature sensor, then it by default will follow the SMBus spec
and implement a bus timeout. Meaning that if the master is
stalling for too long, then the jc42 slave will timeout the
transaction and make itself available to any potential other
masters on the bus. The jc42 chip does not know that it is on a
single master bus. But this is only the default, you can tell the
jc42 driver to disable this timeout, which is sometimes crucial
for reliable behavior, e.g. if the master is not always able to
keep the deadlines for whatever reason.

Next scenario. Suppose you have a simple setup with a bus
featuring a single remote master of some sort and the aspeed
acting as slave only. Since there is only a single master, and
there are no other slaves on the bus, there's no point for the
aspeed to act as master. The aspeed without your patches behave
as the jc42 chip above, when it has been instructed to /remove
the timeout/. And that's fine in this scenario since there is
only one master and the aspeed, as slave, can defer recovering
the bus to that master. So, when aspeed is operating as
slave-only, these patches enable the addition of the same timeout
that was there by default in the first scenario.

Final scenario, some as last but with some other slave(s) on the
bus. Now, it becomes interesting for the aspeed to act as master,
and it becomes interesting indeed to have a timeout that "breaks
out" when some remote master hogs the aspeed in slave mode.

I claim that the timeouts mentioned in all these scenarios are
related. In the first scenario, you disable the timeout by adding
smbus-timeout-disable to the relevant device tree node. I was
merely suggesting that, since the timeouts are basically doing
the same thing in all scenarios, the naming should perhaps be
consistent and be something more specific than hw-timeout-ms. What
popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
remote-timeout-ms, or something, would also work...

Note that the timeouts I'm talking about has nothing to do with
the adapter timeout in the linux I2C core. This is all about
timeouts when acting as I2C slave and the remote master fails to
complete (or otherwise messes up) transfers.

I hope that clarifies my position!

Cheers,
Peter

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>> Hi Peter,
>>>
>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>> Append a binding to support hardware timeout feature.
>>>>>
>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>    		  specified
>>>>>    - multi-master	: states that there is another master active on this bus.
>>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>>    
>>>>>    Example:
>>>>>    
>>>>>
>>>>
>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>> is the reverse situation, where you want to add a timeout where one is
>>>> otherwise missing.
>>>>
>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>> feels like something that is more in the SMBus arena. Should the property
>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>> that?
>>>
>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>> I agreed that the generic bus timeout property can be set by an ioctl
>>> command so it didn't need to be added into device tree at that time. Not
>>> sure if any need has come recently but I haven't heard that. This driver
>>> still uses the generic timeout property which is provided by i2c core
>>> for handling command timeouts, and it's out of scope from this patch
>>> series.
>>>
>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>> or something like that. But I don't care deeply...
>>>
>>> Changes I submitted in this patch set is for a different purpose which
>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>> setting indeed. If this H/W is used in multi-master environment, it
>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>> escape from the state. To resolve the specific case, this H/W provides
>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>> H/W state machine using the timeout setting to determine the escape
>>> condition.
>>
>> Are you saying that the aspeed HW is buggy and that this abnormal state
>> is self inflicted by the aspeed HW even if other masters on the bus
>> behave sanely? Because I didn't quite read it that way at all...
> 
> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> very severe environments if it is used as a Baseboard Management
> Controller which needs two or more multi-masters on a bus depends on
> HW design. Also, it should expect unknown or buggy device attachment
> on a bus through add-on card slots. Aspeed HW provides HW timeout
> feature to support exceptional cases handling which comes from the
> severe use cases.
> 
>> To me, it sounded *exactly* like the state I2C clients end up in when an
>> I2C master "dies" and stops communicating in the middle of a transaction.
>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>> I saw) was that the aspeed HW is also a master and that the aspeed master
>> driver is completely locked out from the bus while some obnoxious master
>> fails to complete its transaction (or whatever it was up to).
> 
> If this HW runs on a single-master bus, any master dying issue will be
> cured by recovery logic which this driver already has and the logic uses
> the bus timeout setting you are saying.
> 
> This patch set is mainly focusing on a 'slave mode hang' issue on a
> 'multi-master' bus which can't be covered by the recovery logic.
> 
>> If this can only be triggered when the HW is acting as a slave, and by
>> aborted or otherwise funky master activity on the bus, then I wouldn't
>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>> a bus-timeout instead of a hw-timeout.
> 
> Here is an example. In a multi-node BMC system, a peer master can be
> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> for a next event from the peer master but it can't happen because the
> peer master was already shutdown. If we enable the 'slave inactive
> timeout feature' using the HW timeout setting, the this HW can escape
> from the waiting state. If we don't, this HW hangs forever in the
> waiting state and it's the reason why I implemented this patch set.
> 
> The hw-timeout setting needs fine tuning depends on HW environment so
> it should be different from the bus-timeout.

Yeah, ok, so you're basically confirming everything I said. I do
sense some confusion though, as you come across as a bit
defensive and seem to think that I am against the whole notion of
the patches. And that's not the case at all! My only issue is
with the naming. And I happen to think hw-timeout-ms is a really
bad name. It's way too broad and can mean just about anything.
When I read that, I think of some workaround for broken hardware,
not normal things like the other masters on the bus doing
confusing things. Funky bus activity from remote masters is
simply not an HW issue in my book, at least not an HW issue on
the local side of the bus. It's just something you *must expect*.

Let me list some scenarios, so that I can describe why I came up
with my suggested alternate naming:

Suppose you have a simple setup with a bus featuring a single
aspeed master and a single slave. If the slave is, say, a jc42
temperature sensor, then it by default will follow the SMBus spec
and implement a bus timeout. Meaning that if the master is
stalling for too long, then the jc42 slave will timeout the
transaction and make itself available to any potential other
masters on the bus. The jc42 chip does not know that it is on a
single master bus. But this is only the default, you can tell the
jc42 driver to disable this timeout, which is sometimes crucial
for reliable behavior, e.g. if the master is not always able to
keep the deadlines for whatever reason.

Next scenario. Suppose you have a simple setup with a bus
featuring a single remote master of some sort and the aspeed
acting as slave only. Since there is only a single master, and
there are no other slaves on the bus, there's no point for the
aspeed to act as master. The aspeed without your patches behave
as the jc42 chip above, when it has been instructed to /remove
the timeout/. And that's fine in this scenario since there is
only one master and the aspeed, as slave, can defer recovering
the bus to that master. So, when aspeed is operating as
slave-only, these patches enable the addition of the same timeout
that was there by default in the first scenario.

Final scenario, some as last but with some other slave(s) on the
bus. Now, it becomes interesting for the aspeed to act as master,
and it becomes interesting indeed to have a timeout that "breaks
out" when some remote master hogs the aspeed in slave mode.

I claim that the timeouts mentioned in all these scenarios are
related. In the first scenario, you disable the timeout by adding
smbus-timeout-disable to the relevant device tree node. I was
merely suggesting that, since the timeouts are basically doing
the same thing in all scenarios, the naming should perhaps be
consistent and be something more specific than hw-timeout-ms. What
popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
remote-timeout-ms, or something, would also work...

Note that the timeouts I'm talking about has nothing to do with
the adapter timeout in the linux I2C core. This is all about
timeouts when acting as I2C slave and the remote master fails to
complete (or otherwise messes up) transfers.

I hope that clarifies my position!

Cheers,
Peter

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Peter Rosin]

On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>> Hi Peter,
>>>
>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>> Append a binding to support hardware timeout feature.
>>>>>
>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>    		  specified
>>>>>    - multi-master	: states that there is another master active on this bus.
>>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
>>>>> +			  specified, the H/W timeout feature will be disabled.
>>>>>    
>>>>>    Example:
>>>>>    
>>>>>
>>>>
>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>> is the reverse situation, where you want to add a timeout where one is
>>>> otherwise missing.
>>>>
>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>> feels like something that is more in the SMBus arena. Should the property
>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>> that?
>>>
>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>> I agreed that the generic bus timeout property can be set by an ioctl
>>> command so it didn't need to be added into device tree at that time. Not
>>> sure if any need has come recently but I haven't heard that. This driver
>>> still uses the generic timeout property which is provided by i2c core
>>> for handling command timeouts, and it's out of scope from this patch
>>> series.
>>>
>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>> or something like that. But I don't care deeply...
>>>
>>> Changes I submitted in this patch set is for a different purpose which
>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>> setting indeed. If this H/W is used in multi-master environment, it
>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>> escape from the state. To resolve the specific case, this H/W provides
>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>> H/W state machine using the timeout setting to determine the escape
>>> condition.
>>
>> Are you saying that the aspeed HW is buggy and that this abnormal state
>> is self inflicted by the aspeed HW even if other masters on the bus
>> behave sanely? Because I didn't quite read it that way at all...
> 
> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> very severe environments if it is used as a Baseboard Management
> Controller which needs two or more multi-masters on a bus depends on
> HW design. Also, it should expect unknown or buggy device attachment
> on a bus through add-on card slots. Aspeed HW provides HW timeout
> feature to support exceptional cases handling which comes from the
> severe use cases.
> 
>> To me, it sounded *exactly* like the state I2C clients end up in when an
>> I2C master "dies" and stops communicating in the middle of a transaction.
>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>> I saw) was that the aspeed HW is also a master and that the aspeed master
>> driver is completely locked out from the bus while some obnoxious master
>> fails to complete its transaction (or whatever it was up to).
> 
> If this HW runs on a single-master bus, any master dying issue will be
> cured by recovery logic which this driver already has and the logic uses
> the bus timeout setting you are saying.
> 
> This patch set is mainly focusing on a 'slave mode hang' issue on a
> 'multi-master' bus which can't be covered by the recovery logic.
> 
>> If this can only be triggered when the HW is acting as a slave, and by
>> aborted or otherwise funky master activity on the bus, then I wouldn't
>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>> a bus-timeout instead of a hw-timeout.
> 
> Here is an example. In a multi-node BMC system, a peer master can be
> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> for a next event from the peer master but it can't happen because the
> peer master was already shutdown. If we enable the 'slave inactive
> timeout feature' using the HW timeout setting, the this HW can escape
> from the waiting state. If we don't, this HW hangs forever in the
> waiting state and it's the reason why I implemented this patch set.
> 
> The hw-timeout setting needs fine tuning depends on HW environment so
> it should be different from the bus-timeout.

Yeah, ok, so you're basically confirming everything I said. I do
sense some confusion though, as you come across as a bit
defensive and seem to think that I am against the whole notion of
the patches. And that's not the case at all! My only issue is
with the naming. And I happen to think hw-timeout-ms is a really
bad name. It's way too broad and can mean just about anything.
When I read that, I think of some workaround for broken hardware,
not normal things like the other masters on the bus doing
confusing things. Funky bus activity from remote masters is
simply not an HW issue in my book, at least not an HW issue on
the local side of the bus. It's just something you *must expect*.

Let me list some scenarios, so that I can describe why I came up
with my suggested alternate naming:

Suppose you have a simple setup with a bus featuring a single
aspeed master and a single slave. If the slave is, say, a jc42
temperature sensor, then it by default will follow the SMBus spec
and implement a bus timeout. Meaning that if the master is
stalling for too long, then the jc42 slave will timeout the
transaction and make itself available to any potential other
masters on the bus. The jc42 chip does not know that it is on a
single master bus. But this is only the default, you can tell the
jc42 driver to disable this timeout, which is sometimes crucial
for reliable behavior, e.g. if the master is not always able to
keep the deadlines for whatever reason.

Next scenario. Suppose you have a simple setup with a bus
featuring a single remote master of some sort and the aspeed
acting as slave only. Since there is only a single master, and
there are no other slaves on the bus, there's no point for the
aspeed to act as master. The aspeed without your patches behave
as the jc42 chip above, when it has been instructed to /remove
the timeout/. And that's fine in this scenario since there is
only one master and the aspeed, as slave, can defer recovering
the bus to that master. So, when aspeed is operating as
slave-only, these patches enable the addition of the same timeout
that was there by default in the first scenario.

Final scenario, some as last but with some other slave(s) on the
bus. Now, it becomes interesting for the aspeed to act as master,
and it becomes interesting indeed to have a timeout that "breaks
out" when some remote master hogs the aspeed in slave mode.

I claim that the timeouts mentioned in all these scenarios are
related. In the first scenario, you disable the timeout by adding
smbus-timeout-disable to the relevant device tree node. I was
merely suggesting that, since the timeouts are basically doing
the same thing in all scenarios, the naming should perhaps be
consistent and be something more specific than hw-timeout-ms. What
popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
remote-timeout-ms, or something, would also work...

Note that the timeouts I'm talking about has nothing to do with
the adapter timeout in the linux I2C core. This is all about
timeouts when acting as I2C slave and the remote master fails to
complete (or otherwise messes up) transfers.

I hope that clarifies my position!

Cheers,
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Tao Ren]

On Wed, Oct 23, 2019 at 09:17:16PM +0000, Peter Rosin wrote:
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>    		  specified
> >>>>>    - multi-master	: states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> >>>>> +			  specified, the H/W timeout feature will be disabled.
> >>>>>    
> >>>>>    Example:
> >>>>>    
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> > 
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> > 
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> > 
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> > 
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> > 
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> > 
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> > 
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
> 
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.
> 
> Let me list some scenarios, so that I can describe why I came up
> with my suggested alternate naming:
> 
> Suppose you have a simple setup with a bus featuring a single
> aspeed master and a single slave. If the slave is, say, a jc42
> temperature sensor, then it by default will follow the SMBus spec
> and implement a bus timeout. Meaning that if the master is
> stalling for too long, then the jc42 slave will timeout the
> transaction and make itself available to any potential other
> masters on the bus. The jc42 chip does not know that it is on a
> single master bus. But this is only the default, you can tell the
> jc42 driver to disable this timeout, which is sometimes crucial
> for reliable behavior, e.g. if the master is not always able to
> keep the deadlines for whatever reason.
> 
> Next scenario. Suppose you have a simple setup with a bus
> featuring a single remote master of some sort and the aspeed
> acting as slave only. Since there is only a single master, and
> there are no other slaves on the bus, there's no point for the
> aspeed to act as master. The aspeed without your patches behave
> as the jc42 chip above, when it has been instructed to /remove
> the timeout/. And that's fine in this scenario since there is
> only one master and the aspeed, as slave, can defer recovering
> the bus to that master. So, when aspeed is operating as
> slave-only, these patches enable the addition of the same timeout
> that was there by default in the first scenario.
> 
> Final scenario, some as last but with some other slave(s) on the
> bus. Now, it becomes interesting for the aspeed to act as master,
> and it becomes interesting indeed to have a timeout that "breaks
> out" when some remote master hogs the aspeed in slave mode.
> 
> I claim that the timeouts mentioned in all these scenarios are
> related. In the first scenario, you disable the timeout by adding
> smbus-timeout-disable to the relevant device tree node. I was
> merely suggesting that, since the timeouts are basically doing
> the same thing in all scenarios, the naming should perhaps be
> consistent and be something more specific than hw-timeout-ms. What
> popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
> remote-timeout-ms, or something, would also work...
> 
> Note that the timeouts I'm talking about has nothing to do with
> the adapter timeout in the linux I2C core. This is all about
> timeouts when acting as I2C slave and the remote master fails to
> complete (or otherwise messes up) transfers.
> 
> I hope that clarifies my position!
> 
> Cheers,
> Peter

Let me share my findings on Facebook Minipack BMC, and hopefully it
helps with the topic.

Both AST2500 and BIC (Bridged IC) can be bus master on Minipack i2c-0,
and they send ipmi messages to each other. After several rounds of
message sharing, BIC becomes the master and starts to send bytes to
AST2500 BMC: BMC receives first a few bytes successfully but then BIC
stops sending bytes, and STOP pattern is not detected on the bus,
either.

Because of this, BMC gets stuck in slave-rx-done state (expecting more
bytes or STOP), and all the master transactions initiated from BMC side
would also fail with timeout even though both SDA/SCL lines are high.
So far I can find 2 ways to recover the apseed controller: a) reset the
controller explicitly, or b) enabling the slave mode inactive timeout
interrupt to bring aspped controller's state to idle automatically when
the controller stays in slave mode for "too long" time.


Cheers,

Tao

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Tao Ren]

On Wed, Oct 23, 2019 at 09:17:16PM +0000, Peter Rosin wrote:
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>    		  specified
> >>>>>    - multi-master	: states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> >>>>> +			  specified, the H/W timeout feature will be disabled.
> >>>>>    
> >>>>>    Example:
> >>>>>    
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> > 
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> > 
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> > 
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> > 
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> > 
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> > 
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> > 
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
> 
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.
> 
> Let me list some scenarios, so that I can describe why I came up
> with my suggested alternate naming:
> 
> Suppose you have a simple setup with a bus featuring a single
> aspeed master and a single slave. If the slave is, say, a jc42
> temperature sensor, then it by default will follow the SMBus spec
> and implement a bus timeout. Meaning that if the master is
> stalling for too long, then the jc42 slave will timeout the
> transaction and make itself available to any potential other
> masters on the bus. The jc42 chip does not know that it is on a
> single master bus. But this is only the default, you can tell the
> jc42 driver to disable this timeout, which is sometimes crucial
> for reliable behavior, e.g. if the master is not always able to
> keep the deadlines for whatever reason.
> 
> Next scenario. Suppose you have a simple setup with a bus
> featuring a single remote master of some sort and the aspeed
> acting as slave only. Since there is only a single master, and
> there are no other slaves on the bus, there's no point for the
> aspeed to act as master. The aspeed without your patches behave
> as the jc42 chip above, when it has been instructed to /remove
> the timeout/. And that's fine in this scenario since there is
> only one master and the aspeed, as slave, can defer recovering
> the bus to that master. So, when aspeed is operating as
> slave-only, these patches enable the addition of the same timeout
> that was there by default in the first scenario.
> 
> Final scenario, some as last but with some other slave(s) on the
> bus. Now, it becomes interesting for the aspeed to act as master,
> and it becomes interesting indeed to have a timeout that "breaks
> out" when some remote master hogs the aspeed in slave mode.
> 
> I claim that the timeouts mentioned in all these scenarios are
> related. In the first scenario, you disable the timeout by adding
> smbus-timeout-disable to the relevant device tree node. I was
> merely suggesting that, since the timeouts are basically doing
> the same thing in all scenarios, the naming should perhaps be
> consistent and be something more specific than hw-timeout-ms. What
> popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
> remote-timeout-ms, or something, would also work...
> 
> Note that the timeouts I'm talking about has nothing to do with
> the adapter timeout in the linux I2C core. This is all about
> timeouts when acting as I2C slave and the remote master fails to
> complete (or otherwise messes up) transfers.
> 
> I hope that clarifies my position!
> 
> Cheers,
> Peter

Let me share my findings on Facebook Minipack BMC, and hopefully it
helps with the topic.

Both AST2500 and BIC (Bridged IC) can be bus master on Minipack i2c-0,
and they send ipmi messages to each other. After several rounds of
message sharing, BIC becomes the master and starts to send bytes to
AST2500 BMC: BMC receives first a few bytes successfully but then BIC
stops sending bytes, and STOP pattern is not detected on the bus,
either.

Because of this, BMC gets stuck in slave-rx-done state (expecting more
bytes or STOP), and all the master transactions initiated from BMC side
would also fail with timeout even though both SDA/SCL lines are high.
So far I can find 2 ways to recover the apseed controller: a) reset the
controller explicitly, or b) enabling the slave mode inactive timeout
interrupt to bring aspped controller's state to idle automatically when
the controller stays in slave mode for "too long" time.


Cheers,

Tao

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Tao Ren]

On Wed, Oct 23, 2019 at 09:17:16PM +0000, Peter Rosin wrote:
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>    		  specified
> >>>>>    - multi-master	: states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> >>>>> +			  specified, the H/W timeout feature will be disabled.
> >>>>>    
> >>>>>    Example:
> >>>>>    
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> > 
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> > 
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> > 
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> > 
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> > 
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> > 
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> > 
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
> 
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.
> 
> Let me list some scenarios, so that I can describe why I came up
> with my suggested alternate naming:
> 
> Suppose you have a simple setup with a bus featuring a single
> aspeed master and a single slave. If the slave is, say, a jc42
> temperature sensor, then it by default will follow the SMBus spec
> and implement a bus timeout. Meaning that if the master is
> stalling for too long, then the jc42 slave will timeout the
> transaction and make itself available to any potential other
> masters on the bus. The jc42 chip does not know that it is on a
> single master bus. But this is only the default, you can tell the
> jc42 driver to disable this timeout, which is sometimes crucial
> for reliable behavior, e.g. if the master is not always able to
> keep the deadlines for whatever reason.
> 
> Next scenario. Suppose you have a simple setup with a bus
> featuring a single remote master of some sort and the aspeed
> acting as slave only. Since there is only a single master, and
> there are no other slaves on the bus, there's no point for the
> aspeed to act as master. The aspeed without your patches behave
> as the jc42 chip above, when it has been instructed to /remove
> the timeout/. And that's fine in this scenario since there is
> only one master and the aspeed, as slave, can defer recovering
> the bus to that master. So, when aspeed is operating as
> slave-only, these patches enable the addition of the same timeout
> that was there by default in the first scenario.
> 
> Final scenario, some as last but with some other slave(s) on the
> bus. Now, it becomes interesting for the aspeed to act as master,
> and it becomes interesting indeed to have a timeout that "breaks
> out" when some remote master hogs the aspeed in slave mode.
> 
> I claim that the timeouts mentioned in all these scenarios are
> related. In the first scenario, you disable the timeout by adding
> smbus-timeout-disable to the relevant device tree node. I was
> merely suggesting that, since the timeouts are basically doing
> the same thing in all scenarios, the naming should perhaps be
> consistent and be something more specific than hw-timeout-ms. What
> popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
> remote-timeout-ms, or something, would also work...
> 
> Note that the timeouts I'm talking about has nothing to do with
> the adapter timeout in the linux I2C core. This is all about
> timeouts when acting as I2C slave and the remote master fails to
> complete (or otherwise messes up) transfers.
> 
> I hope that clarifies my position!
> 
> Cheers,
> Peter

Let me share my findings on Facebook Minipack BMC, and hopefully it
helps with the topic.

Both AST2500 and BIC (Bridged IC) can be bus master on Minipack i2c-0,
and they send ipmi messages to each other. After several rounds of
message sharing, BIC becomes the master and starts to send bytes to
AST2500 BMC: BMC receives first a few bytes successfully but then BIC
stops sending bytes, and STOP pattern is not detected on the bus,
either.

Because of this, BMC gets stuck in slave-rx-done state (expecting more
bytes or STOP), and all the master transactions initiated from BMC side
would also fail with timeout even though both SDA/SCL lines are high.
So far I can find 2 ways to recover the apseed controller: a) reset the
controller explicitly, or b) enabling the slave mode inactive timeout
interrupt to bring aspped controller's state to idle automatically when
the controller stays in slave mode for "too long" time.


Cheers,

Tao

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Tao Ren]

On Wed, Oct 23, 2019 at 09:17:16PM +0000, Peter Rosin wrote:
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency	: frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>    		  specified
> >>>>>    - multi-master	: states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms	: Hardware timeout in milliseconds. If it's not
> >>>>> +			  specified, the H/W timeout feature will be disabled.
> >>>>>    
> >>>>>    Example:
> >>>>>    
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> > 
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> > 
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> > 
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> > 
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> > 
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> > 
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> > 
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
> 
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.
> 
> Let me list some scenarios, so that I can describe why I came up
> with my suggested alternate naming:
> 
> Suppose you have a simple setup with a bus featuring a single
> aspeed master and a single slave. If the slave is, say, a jc42
> temperature sensor, then it by default will follow the SMBus spec
> and implement a bus timeout. Meaning that if the master is
> stalling for too long, then the jc42 slave will timeout the
> transaction and make itself available to any potential other
> masters on the bus. The jc42 chip does not know that it is on a
> single master bus. But this is only the default, you can tell the
> jc42 driver to disable this timeout, which is sometimes crucial
> for reliable behavior, e.g. if the master is not always able to
> keep the deadlines for whatever reason.
> 
> Next scenario. Suppose you have a simple setup with a bus
> featuring a single remote master of some sort and the aspeed
> acting as slave only. Since there is only a single master, and
> there are no other slaves on the bus, there's no point for the
> aspeed to act as master. The aspeed without your patches behave
> as the jc42 chip above, when it has been instructed to /remove
> the timeout/. And that's fine in this scenario since there is
> only one master and the aspeed, as slave, can defer recovering
> the bus to that master. So, when aspeed is operating as
> slave-only, these patches enable the addition of the same timeout
> that was there by default in the first scenario.
> 
> Final scenario, some as last but with some other slave(s) on the
> bus. Now, it becomes interesting for the aspeed to act as master,
> and it becomes interesting indeed to have a timeout that "breaks
> out" when some remote master hogs the aspeed in slave mode.
> 
> I claim that the timeouts mentioned in all these scenarios are
> related. In the first scenario, you disable the timeout by adding
> smbus-timeout-disable to the relevant device tree node. I was
> merely suggesting that, since the timeouts are basically doing
> the same thing in all scenarios, the naming should perhaps be
> consistent and be something more specific than hw-timeout-ms. What
> popped up was bus-timeout-ms or smbus-timeout-ms. I suppose
> remote-timeout-ms, or something, would also work...
> 
> Note that the timeouts I'm talking about has nothing to do with
> the adapter timeout in the linux I2C core. This is all about
> timeouts when acting as I2C slave and the remote master fails to
> complete (or otherwise messes up) transfers.
> 
> I hope that clarifies my position!
> 
> Cheers,
> Peter

Let me share my findings on Facebook Minipack BMC, and hopefully it
helps with the topic.

Both AST2500 and BIC (Bridged IC) can be bus master on Minipack i2c-0,
and they send ipmi messages to each other. After several rounds of
message sharing, BIC becomes the master and starts to send bytes to
AST2500 BMC: BMC receives first a few bytes successfully but then BIC
stops sending bytes, and STOP pattern is not detected on the bus,
either.

Because of this, BMC gets stuck in slave-rx-done state (expecting more
bytes or STOP), and all the master transactions initiated from BMC side
would also fail with timeout even though both SDA/SCL lines are high.
So far I can find 2 ways to recover the apseed controller: a) reset the
controller explicitly, or b) enabling the slave mode inactive timeout
interrupt to bring aspped controller's state to idle automatically when
the controller stays in slave mode for "too long" time.


Cheers,

Tao

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Brendan Higgins]

On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>                     specified
> >>>>>    - multi-master : states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
> >>>>> +                   specified, the H/W timeout feature will be disabled.
> >>>>>
> >>>>>    Example:
> >>>>>
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> >
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> >
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> >
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> >
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> >
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> >
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> >
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
>
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.

Sorry for not jumping in earlier, but I agree with Peter.

I like the name bus-timeout-ms better. It was not immediately clear
from reading your commit descriptions what this was all about.

Cheers!

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Brendan Higgins]

On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>                     specified
> >>>>>    - multi-master : states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
> >>>>> +                   specified, the H/W timeout feature will be disabled.
> >>>>>
> >>>>>    Example:
> >>>>>
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> >
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> >
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> >
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> >
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> >
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> >
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> >
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
>
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.

Sorry for not jumping in earlier, but I agree with Peter.

I like the name bus-timeout-ms better. It was not immediately clear
from reading your commit descriptions what this was all about.

Cheers!

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Brendan Higgins]

On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>                     specified
> >>>>>    - multi-master : states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
> >>>>> +                   specified, the H/W timeout feature will be disabled.
> >>>>>
> >>>>>    Example:
> >>>>>
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> >
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> >
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> >
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> >
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> >
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> >
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> >
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
>
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.

Sorry for not jumping in earlier, but I agree with Peter.

I like the name bus-timeout-ms better. It was not immediately clear
from reading your commit descriptions what this was all about.

Cheers!

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Brendan Higgins]

On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>
> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
> > On 10/22/2019 1:45 AM, Peter Rosin wrote:
> >> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
> >>> Hi Peter,
> >>>
> >>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
> >>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
> >>>>> Append a binding to support hardware timeout feature.
> >>>>>
> >>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> >>>>> ---
> >>>>>    Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
> >>>>>    1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> index b47f6ccb196a..133bfedf4cdd 100644
> >>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> >>>>> @@ -17,6 +17,8 @@ Optional Properties:
> >>>>>    - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
> >>>>>                     specified
> >>>>>    - multi-master : states that there is another master active on this bus.
> >>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
> >>>>> +                   specified, the H/W timeout feature will be disabled.
> >>>>>
> >>>>>    Example:
> >>>>>
> >>>>>
> >>>>
> >>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
> >>>> timeouts like this, for cases where the I2C adapter in question on occasion
> >>>> is unable to keep the pace. Adding that property thus avoids undesired
> >>>> timeouts when the client is SMBus conformant without it. Your new binding
> >>>> is the reverse situation, where you want to add a timeout where one is
> >>>> otherwise missing.
> >>>>
> >>>> Anyway, since I2C does not have a specified lowest possible frequency, this
> >>>> feels like something that is more in the SMBus arena. Should the property
> >>>> perhaps be a generic property named smbus-timeout-ms, or something like
> >>>> that?
> >>>
> >>> Well, I tried upstreaming of the generic timeout property a year ago but
> >>> I agreed that the generic bus timeout property can be set by an ioctl
> >>> command so it didn't need to be added into device tree at that time. Not
> >>> sure if any need has come recently but I haven't heard that. This driver
> >>> still uses the generic timeout property which is provided by i2c core
> >>> for handling command timeouts, and it's out of scope from this patch
> >>> series.
> >>>
> >>>> If the above is not wanted or appropriate, then I would personally prefer
> >>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
> >>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
> >>>> or something like that. But I don't care deeply...
> >>>
> >>> Changes I submitted in this patch set is for a different purpose which
> >>> is very Aspeed H/W specific, and actually it's a more serious timeout
> >>> setting indeed. If this H/W is used in multi-master environment, it
> >>> could meet a H/W hang that freezes itself in slave mode and it can't
> >>> escape from the state. To resolve the specific case, this H/W provides
> >>> self-recovery feature which monitors abnormal state of SDA, SCL and its
> >>> H/W state machine using the timeout setting to determine the escape
> >>> condition.
> >>
> >> Are you saying that the aspeed HW is buggy and that this abnormal state
> >> is self inflicted by the aspeed HW even if other masters on the bus
> >> behave sanely? Because I didn't quite read it that way at all...
> >
> > I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
> > very severe environments if it is used as a Baseboard Management
> > Controller which needs two or more multi-masters on a bus depends on
> > HW design. Also, it should expect unknown or buggy device attachment
> > on a bus through add-on card slots. Aspeed HW provides HW timeout
> > feature to support exceptional cases handling which comes from the
> > severe use cases.
> >
> >> To me, it sounded *exactly* like the state I2C clients end up in when an
> >> I2C master "dies" and stops communicating in the middle of a transaction.
> >> I.e. the thing that the SMBus timeout is designed to prevent (and the
> >> state the I2C nine-clk-recovery sequence addresses). The only twist (that
> >> I saw) was that the aspeed HW is also a master and that the aspeed master
> >> driver is completely locked out from the bus while some obnoxious master
> >> fails to complete its transaction (or whatever it was up to).
> >
> > If this HW runs on a single-master bus, any master dying issue will be
> > cured by recovery logic which this driver already has and the logic uses
> > the bus timeout setting you are saying.
> >
> > This patch set is mainly focusing on a 'slave mode hang' issue on a
> > 'multi-master' bus which can't be covered by the recovery logic.
> >
> >> If this can only be triggered when the HW is acting as a slave, and by
> >> aborted or otherwise funky master activity on the bus, then I wouldn't
> >> call it an HW issue. Then it would be a bus issue. I.e. something needing
> >> a bus-timeout instead of a hw-timeout.
> >
> > Here is an example. In a multi-node BMC system, a peer master can be
> > shutdown in the middle of transaction, then this Aspeed HW keeps waiting
> > for a next event from the peer master but it can't happen because the
> > peer master was already shutdown. If we enable the 'slave inactive
> > timeout feature' using the HW timeout setting, the this HW can escape
> > from the waiting state. If we don't, this HW hangs forever in the
> > waiting state and it's the reason why I implemented this patch set.
> >
> > The hw-timeout setting needs fine tuning depends on HW environment so
> > it should be different from the bus-timeout.
>
> Yeah, ok, so you're basically confirming everything I said. I do
> sense some confusion though, as you come across as a bit
> defensive and seem to think that I am against the whole notion of
> the patches. And that's not the case at all! My only issue is
> with the naming. And I happen to think hw-timeout-ms is a really
> bad name. It's way too broad and can mean just about anything.
> When I read that, I think of some workaround for broken hardware,
> not normal things like the other masters on the bus doing
> confusing things. Funky bus activity from remote masters is
> simply not an HW issue in my book, at least not an HW issue on
> the local side of the bus. It's just something you *must expect*.

Sorry for not jumping in earlier, but I agree with Peter.

I like the name bus-timeout-ms better. It was not immediately clear
from reading your commit descriptions what this was all about.

Cheers!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/23/2019 5:09 PM, Brendan Higgins wrote:
> On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>>
>> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
>>> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>>>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>>>> Hi Peter,
>>>>>
>>>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>>>> Append a binding to support hardware timeout feature.
>>>>>>>
>>>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>>>> ---
>>>>>>>     Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>>>     - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>>>                      specified
>>>>>>>     - multi-master : states that there is another master active on this bus.
>>>>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
>>>>>>> +                   specified, the H/W timeout feature will be disabled.
>>>>>>>
>>>>>>>     Example:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>>>> is the reverse situation, where you want to add a timeout where one is
>>>>>> otherwise missing.
>>>>>>
>>>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>>>> feels like something that is more in the SMBus arena. Should the property
>>>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>>>> that?
>>>>>
>>>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>>>> I agreed that the generic bus timeout property can be set by an ioctl
>>>>> command so it didn't need to be added into device tree at that time. Not
>>>>> sure if any need has come recently but I haven't heard that. This driver
>>>>> still uses the generic timeout property which is provided by i2c core
>>>>> for handling command timeouts, and it's out of scope from this patch
>>>>> series.
>>>>>
>>>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>>>> or something like that. But I don't care deeply...
>>>>>
>>>>> Changes I submitted in this patch set is for a different purpose which
>>>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>>>> setting indeed. If this H/W is used in multi-master environment, it
>>>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>>>> escape from the state. To resolve the specific case, this H/W provides
>>>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>>>> H/W state machine using the timeout setting to determine the escape
>>>>> condition.
>>>>
>>>> Are you saying that the aspeed HW is buggy and that this abnormal state
>>>> is self inflicted by the aspeed HW even if other masters on the bus
>>>> behave sanely? Because I didn't quite read it that way at all...
>>>
>>> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
>>> very severe environments if it is used as a Baseboard Management
>>> Controller which needs two or more multi-masters on a bus depends on
>>> HW design. Also, it should expect unknown or buggy device attachment
>>> on a bus through add-on card slots. Aspeed HW provides HW timeout
>>> feature to support exceptional cases handling which comes from the
>>> severe use cases.
>>>
>>>> To me, it sounded *exactly* like the state I2C clients end up in when an
>>>> I2C master "dies" and stops communicating in the middle of a transaction.
>>>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>>>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>>>> I saw) was that the aspeed HW is also a master and that the aspeed master
>>>> driver is completely locked out from the bus while some obnoxious master
>>>> fails to complete its transaction (or whatever it was up to).
>>>
>>> If this HW runs on a single-master bus, any master dying issue will be
>>> cured by recovery logic which this driver already has and the logic uses
>>> the bus timeout setting you are saying.
>>>
>>> This patch set is mainly focusing on a 'slave mode hang' issue on a
>>> 'multi-master' bus which can't be covered by the recovery logic.
>>>
>>>> If this can only be triggered when the HW is acting as a slave, and by
>>>> aborted or otherwise funky master activity on the bus, then I wouldn't
>>>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>>>> a bus-timeout instead of a hw-timeout.
>>>
>>> Here is an example. In a multi-node BMC system, a peer master can be
>>> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
>>> for a next event from the peer master but it can't happen because the
>>> peer master was already shutdown. If we enable the 'slave inactive
>>> timeout feature' using the HW timeout setting, the this HW can escape
>>> from the waiting state. If we don't, this HW hangs forever in the
>>> waiting state and it's the reason why I implemented this patch set.
>>>
>>> The hw-timeout setting needs fine tuning depends on HW environment so
>>> it should be different from the bus-timeout.
>>
>> Yeah, ok, so you're basically confirming everything I said. I do
>> sense some confusion though, as you come across as a bit
>> defensive and seem to think that I am against the whole notion of
>> the patches. And that's not the case at all! My only issue is
>> with the naming. And I happen to think hw-timeout-ms is a really
>> bad name. It's way too broad and can mean just about anything.
>> When I read that, I think of some workaround for broken hardware,
>> not normal things like the other masters on the bus doing
>> confusing things. Funky bus activity from remote masters is
>> simply not an HW issue in my book, at least not an HW issue on
>> the local side of the bus. It's just something you *must expect*.
> 
> Sorry for not jumping in earlier, but I agree with Peter.
> 
> I like the name bus-timeout-ms better. It was not immediately clear
> from reading your commit descriptions what this was all about.

Okay, I can change the name if the 'aspeed,hw-timeout-ms' is
inappropriate but I still doubt using of 'bus-timeout-ms'.

The 'bus-timeout-ms' is being used for some client drivers in hwmon
subsystem but it's not being used for any adapter driver currently.
Since adapter drivers also use timeout value which I2C core provides,
it could make confusion with it if I use 'bus-timeout-ms' for an adapter
node in DT. Though, I and Wolfram agreed last year that the adapter
timeout property can't be added into DT because it's purely S/W property
so using of 'bus-timeout-ms' in DT for H/W property setting of an
adapter device could be acceptable if we make consensus here.

Please share your thoughts or suggest a better name for it.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/23/2019 5:09 PM, Brendan Higgins wrote:
> On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>>
>> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
>>> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>>>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>>>> Hi Peter,
>>>>>
>>>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>>>> Append a binding to support hardware timeout feature.
>>>>>>>
>>>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>>>> ---
>>>>>>>     Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>>>     - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>>>                      specified
>>>>>>>     - multi-master : states that there is another master active on this bus.
>>>>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
>>>>>>> +                   specified, the H/W timeout feature will be disabled.
>>>>>>>
>>>>>>>     Example:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>>>> is the reverse situation, where you want to add a timeout where one is
>>>>>> otherwise missing.
>>>>>>
>>>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>>>> feels like something that is more in the SMBus arena. Should the property
>>>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>>>> that?
>>>>>
>>>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>>>> I agreed that the generic bus timeout property can be set by an ioctl
>>>>> command so it didn't need to be added into device tree at that time. Not
>>>>> sure if any need has come recently but I haven't heard that. This driver
>>>>> still uses the generic timeout property which is provided by i2c core
>>>>> for handling command timeouts, and it's out of scope from this patch
>>>>> series.
>>>>>
>>>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>>>> or something like that. But I don't care deeply...
>>>>>
>>>>> Changes I submitted in this patch set is for a different purpose which
>>>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>>>> setting indeed. If this H/W is used in multi-master environment, it
>>>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>>>> escape from the state. To resolve the specific case, this H/W provides
>>>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>>>> H/W state machine using the timeout setting to determine the escape
>>>>> condition.
>>>>
>>>> Are you saying that the aspeed HW is buggy and that this abnormal state
>>>> is self inflicted by the aspeed HW even if other masters on the bus
>>>> behave sanely? Because I didn't quite read it that way at all...
>>>
>>> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
>>> very severe environments if it is used as a Baseboard Management
>>> Controller which needs two or more multi-masters on a bus depends on
>>> HW design. Also, it should expect unknown or buggy device attachment
>>> on a bus through add-on card slots. Aspeed HW provides HW timeout
>>> feature to support exceptional cases handling which comes from the
>>> severe use cases.
>>>
>>>> To me, it sounded *exactly* like the state I2C clients end up in when an
>>>> I2C master "dies" and stops communicating in the middle of a transaction.
>>>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>>>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>>>> I saw) was that the aspeed HW is also a master and that the aspeed master
>>>> driver is completely locked out from the bus while some obnoxious master
>>>> fails to complete its transaction (or whatever it was up to).
>>>
>>> If this HW runs on a single-master bus, any master dying issue will be
>>> cured by recovery logic which this driver already has and the logic uses
>>> the bus timeout setting you are saying.
>>>
>>> This patch set is mainly focusing on a 'slave mode hang' issue on a
>>> 'multi-master' bus which can't be covered by the recovery logic.
>>>
>>>> If this can only be triggered when the HW is acting as a slave, and by
>>>> aborted or otherwise funky master activity on the bus, then I wouldn't
>>>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>>>> a bus-timeout instead of a hw-timeout.
>>>
>>> Here is an example. In a multi-node BMC system, a peer master can be
>>> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
>>> for a next event from the peer master but it can't happen because the
>>> peer master was already shutdown. If we enable the 'slave inactive
>>> timeout feature' using the HW timeout setting, the this HW can escape
>>> from the waiting state. If we don't, this HW hangs forever in the
>>> waiting state and it's the reason why I implemented this patch set.
>>>
>>> The hw-timeout setting needs fine tuning depends on HW environment so
>>> it should be different from the bus-timeout.
>>
>> Yeah, ok, so you're basically confirming everything I said. I do
>> sense some confusion though, as you come across as a bit
>> defensive and seem to think that I am against the whole notion of
>> the patches. And that's not the case at all! My only issue is
>> with the naming. And I happen to think hw-timeout-ms is a really
>> bad name. It's way too broad and can mean just about anything.
>> When I read that, I think of some workaround for broken hardware,
>> not normal things like the other masters on the bus doing
>> confusing things. Funky bus activity from remote masters is
>> simply not an HW issue in my book, at least not an HW issue on
>> the local side of the bus. It's just something you *must expect*.
> 
> Sorry for not jumping in earlier, but I agree with Peter.
> 
> I like the name bus-timeout-ms better. It was not immediately clear
> from reading your commit descriptions what this was all about.

Okay, I can change the name if the 'aspeed,hw-timeout-ms' is
inappropriate but I still doubt using of 'bus-timeout-ms'.

The 'bus-timeout-ms' is being used for some client drivers in hwmon
subsystem but it's not being used for any adapter driver currently.
Since adapter drivers also use timeout value which I2C core provides,
it could make confusion with it if I use 'bus-timeout-ms' for an adapter
node in DT. Though, I and Wolfram agreed last year that the adapter
timeout property can't be added into DT because it's purely S/W property
so using of 'bus-timeout-ms' in DT for H/W property setting of an
adapter device could be acceptable if we make consensus here.

Please share your thoughts or suggest a better name for it.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/23/2019 5:09 PM, Brendan Higgins wrote:
> On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>>
>> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
>>> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>>>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>>>> Hi Peter,
>>>>>
>>>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>>>> Append a binding to support hardware timeout feature.
>>>>>>>
>>>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>>>> ---
>>>>>>>     Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>>>     - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>>>                      specified
>>>>>>>     - multi-master : states that there is another master active on this bus.
>>>>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
>>>>>>> +                   specified, the H/W timeout feature will be disabled.
>>>>>>>
>>>>>>>     Example:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>>>> is the reverse situation, where you want to add a timeout where one is
>>>>>> otherwise missing.
>>>>>>
>>>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>>>> feels like something that is more in the SMBus arena. Should the property
>>>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>>>> that?
>>>>>
>>>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>>>> I agreed that the generic bus timeout property can be set by an ioctl
>>>>> command so it didn't need to be added into device tree at that time. Not
>>>>> sure if any need has come recently but I haven't heard that. This driver
>>>>> still uses the generic timeout property which is provided by i2c core
>>>>> for handling command timeouts, and it's out of scope from this patch
>>>>> series.
>>>>>
>>>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>>>> or something like that. But I don't care deeply...
>>>>>
>>>>> Changes I submitted in this patch set is for a different purpose which
>>>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>>>> setting indeed. If this H/W is used in multi-master environment, it
>>>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>>>> escape from the state. To resolve the specific case, this H/W provides
>>>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>>>> H/W state machine using the timeout setting to determine the escape
>>>>> condition.
>>>>
>>>> Are you saying that the aspeed HW is buggy and that this abnormal state
>>>> is self inflicted by the aspeed HW even if other masters on the bus
>>>> behave sanely? Because I didn't quite read it that way at all...
>>>
>>> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
>>> very severe environments if it is used as a Baseboard Management
>>> Controller which needs two or more multi-masters on a bus depends on
>>> HW design. Also, it should expect unknown or buggy device attachment
>>> on a bus through add-on card slots. Aspeed HW provides HW timeout
>>> feature to support exceptional cases handling which comes from the
>>> severe use cases.
>>>
>>>> To me, it sounded *exactly* like the state I2C clients end up in when an
>>>> I2C master "dies" and stops communicating in the middle of a transaction.
>>>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>>>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>>>> I saw) was that the aspeed HW is also a master and that the aspeed master
>>>> driver is completely locked out from the bus while some obnoxious master
>>>> fails to complete its transaction (or whatever it was up to).
>>>
>>> If this HW runs on a single-master bus, any master dying issue will be
>>> cured by recovery logic which this driver already has and the logic uses
>>> the bus timeout setting you are saying.
>>>
>>> This patch set is mainly focusing on a 'slave mode hang' issue on a
>>> 'multi-master' bus which can't be covered by the recovery logic.
>>>
>>>> If this can only be triggered when the HW is acting as a slave, and by
>>>> aborted or otherwise funky master activity on the bus, then I wouldn't
>>>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>>>> a bus-timeout instead of a hw-timeout.
>>>
>>> Here is an example. In a multi-node BMC system, a peer master can be
>>> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
>>> for a next event from the peer master but it can't happen because the
>>> peer master was already shutdown. If we enable the 'slave inactive
>>> timeout feature' using the HW timeout setting, the this HW can escape
>>> from the waiting state. If we don't, this HW hangs forever in the
>>> waiting state and it's the reason why I implemented this patch set.
>>>
>>> The hw-timeout setting needs fine tuning depends on HW environment so
>>> it should be different from the bus-timeout.
>>
>> Yeah, ok, so you're basically confirming everything I said. I do
>> sense some confusion though, as you come across as a bit
>> defensive and seem to think that I am against the whole notion of
>> the patches. And that's not the case at all! My only issue is
>> with the naming. And I happen to think hw-timeout-ms is a really
>> bad name. It's way too broad and can mean just about anything.
>> When I read that, I think of some workaround for broken hardware,
>> not normal things like the other masters on the bus doing
>> confusing things. Funky bus activity from remote masters is
>> simply not an HW issue in my book, at least not an HW issue on
>> the local side of the bus. It's just something you *must expect*.
> 
> Sorry for not jumping in earlier, but I agree with Peter.
> 
> I like the name bus-timeout-ms better. It was not immediately clear
> from reading your commit descriptions what this was all about.

Okay, I can change the name if the 'aspeed,hw-timeout-ms' is
inappropriate but I still doubt using of 'bus-timeout-ms'.

The 'bus-timeout-ms' is being used for some client drivers in hwmon
subsystem but it's not being used for any adapter driver currently.
Since adapter drivers also use timeout value which I2C core provides,
it could make confusion with it if I use 'bus-timeout-ms' for an adapter
node in DT. Though, I and Wolfram agreed last year that the adapter
timeout property can't be added into DT because it's purely S/W property
so using of 'bus-timeout-ms' in DT for H/W property setting of an
adapter device could be acceptable if we make consensus here.

Please share your thoughts or suggest a better name for it.

Thanks,

Jae

Re: [PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: add hardware timeout support

[Jae Hyun Yoo]

On 10/23/2019 5:09 PM, Brendan Higgins wrote:
> On Wed, Oct 23, 2019 at 2:17 PM Peter Rosin <peda@axentia.se> wrote:
>>
>> On 2019-10-22 19:44, Jae Hyun Yoo wrote:
>>> On 10/22/2019 1:45 AM, Peter Rosin wrote:
>>>> On 2019-10-21 23:57, Jae Hyun Yoo wrote:
>>>>> Hi Peter,
>>>>>
>>>>> On 10/21/2019 2:05 PM, Peter Rosin wrote:
>>>>>> On 2019-10-21 22:24, Jae Hyun Yoo wrote:
>>>>>>> Append a binding to support hardware timeout feature.
>>>>>>>
>>>>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>>>>> ---
>>>>>>>     Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 2 ++
>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> index b47f6ccb196a..133bfedf4cdd 100644
>>>>>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>>>>>>> @@ -17,6 +17,8 @@ Optional Properties:
>>>>>>>     - bus-frequency        : frequency of the bus clock in Hz defaults to 100 kHz when not
>>>>>>>                      specified
>>>>>>>     - multi-master : states that there is another master active on this bus.
>>>>>>> +- aspeed,hw-timeout-ms   : Hardware timeout in milliseconds. If it's not
>>>>>>> +                   specified, the H/W timeout feature will be disabled.
>>>>>>>
>>>>>>>     Example:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Some SMBus clients support a smbus-timeout-disable binding for disabling
>>>>>> timeouts like this, for cases where the I2C adapter in question on occasion
>>>>>> is unable to keep the pace. Adding that property thus avoids undesired
>>>>>> timeouts when the client is SMBus conformant without it. Your new binding
>>>>>> is the reverse situation, where you want to add a timeout where one is
>>>>>> otherwise missing.
>>>>>>
>>>>>> Anyway, since I2C does not have a specified lowest possible frequency, this
>>>>>> feels like something that is more in the SMBus arena. Should the property
>>>>>> perhaps be a generic property named smbus-timeout-ms, or something like
>>>>>> that?
>>>>>
>>>>> Well, I tried upstreaming of the generic timeout property a year ago but
>>>>> I agreed that the generic bus timeout property can be set by an ioctl
>>>>> command so it didn't need to be added into device tree at that time. Not
>>>>> sure if any need has come recently but I haven't heard that. This driver
>>>>> still uses the generic timeout property which is provided by i2c core
>>>>> for handling command timeouts, and it's out of scope from this patch
>>>>> series.
>>>>>
>>>>>> If the above is not wanted or appropriate, then I would personally prefer
>>>>>> aspeed,bus-timeout-ms over aspeed,hw-timeout-ms. To me, hw-timeout-ms sounds
>>>>>> like a (more serious) timeout between the CPU and the I2C peripheral unit
>>>>>> or something like that. But I don't care deeply...
>>>>>
>>>>> Changes I submitted in this patch set is for a different purpose which
>>>>> is very Aspeed H/W specific, and actually it's a more serious timeout
>>>>> setting indeed. If this H/W is used in multi-master environment, it
>>>>> could meet a H/W hang that freezes itself in slave mode and it can't
>>>>> escape from the state. To resolve the specific case, this H/W provides
>>>>> self-recovery feature which monitors abnormal state of SDA, SCL and its
>>>>> H/W state machine using the timeout setting to determine the escape
>>>>> condition.
>>>>
>>>> Are you saying that the aspeed HW is buggy and that this abnormal state
>>>> is self inflicted by the aspeed HW even if other masters on the bus
>>>> behave sanely? Because I didn't quite read it that way at all...
>>>
>>> I don't think it's an Aspeed HW bug. Actually, this HW can be exposed to
>>> very severe environments if it is used as a Baseboard Management
>>> Controller which needs two or more multi-masters on a bus depends on
>>> HW design. Also, it should expect unknown or buggy device attachment
>>> on a bus through add-on card slots. Aspeed HW provides HW timeout
>>> feature to support exceptional cases handling which comes from the
>>> severe use cases.
>>>
>>>> To me, it sounded *exactly* like the state I2C clients end up in when an
>>>> I2C master "dies" and stops communicating in the middle of a transaction.
>>>> I.e. the thing that the SMBus timeout is designed to prevent (and the
>>>> state the I2C nine-clk-recovery sequence addresses). The only twist (that
>>>> I saw) was that the aspeed HW is also a master and that the aspeed master
>>>> driver is completely locked out from the bus while some obnoxious master
>>>> fails to complete its transaction (or whatever it was up to).
>>>
>>> If this HW runs on a single-master bus, any master dying issue will be
>>> cured by recovery logic which this driver already has and the logic uses
>>> the bus timeout setting you are saying.
>>>
>>> This patch set is mainly focusing on a 'slave mode hang' issue on a
>>> 'multi-master' bus which can't be covered by the recovery logic.
>>>
>>>> If this can only be triggered when the HW is acting as a slave, and by
>>>> aborted or otherwise funky master activity on the bus, then I wouldn't
>>>> call it an HW issue. Then it would be a bus issue. I.e. something needing
>>>> a bus-timeout instead of a hw-timeout.
>>>
>>> Here is an example. In a multi-node BMC system, a peer master can be
>>> shutdown in the middle of transaction, then this Aspeed HW keeps waiting
>>> for a next event from the peer master but it can't happen because the
>>> peer master was already shutdown. If we enable the 'slave inactive
>>> timeout feature' using the HW timeout setting, the this HW can escape
>>> from the waiting state. If we don't, this HW hangs forever in the
>>> waiting state and it's the reason why I implemented this patch set.
>>>
>>> The hw-timeout setting needs fine tuning depends on HW environment so
>>> it should be different from the bus-timeout.
>>
>> Yeah, ok, so you're basically confirming everything I said. I do
>> sense some confusion though, as you come across as a bit
>> defensive and seem to think that I am against the whole notion of
>> the patches. And that's not the case at all! My only issue is
>> with the naming. And I happen to think hw-timeout-ms is a really
>> bad name. It's way too broad and can mean just about anything.
>> When I read that, I think of some workaround for broken hardware,
>> not normal things like the other masters on the bus doing
>> confusing things. Funky bus activity from remote masters is
>> simply not an HW issue in my book, at least not an HW issue on
>> the local side of the bus. It's just something you *must expect*.
> 
> Sorry for not jumping in earlier, but I agree with Peter.
> 
> I like the name bus-timeout-ms better. It was not immediately clear
> from reading your commit descriptions what this was all about.

Okay, I can change the name if the 'aspeed,hw-timeout-ms' is
inappropriate but I still doubt using of 'bus-timeout-ms'.

The 'bus-timeout-ms' is being used for some client drivers in hwmon
subsystem but it's not being used for any adapter driver currently.
Since adapter drivers also use timeout value which I2C core provides,
it could make confusion with it if I use 'bus-timeout-ms' for an adapter
node in DT. Though, I and Wolfram agreed last year that the adapter
timeout property can't be added into DT because it's purely S/W property
so using of 'bus-timeout-ms' in DT for H/W property setting of an
adapter device could be acceptable if we make consensus here.

Please share your thoughts or suggest a better name for it.

Thanks,

Jae

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel