fsi: core: Allow more BREAKs to recover a failing link

PATCH In review Christopher Bostic 3 participants 4 messages Oct 20, 2017 – Oct 30, 2017 FSI

Share & tools

Christopher Bostic

author

2017-10-20 17:32 UTC #0 lore raw

PATCH 1/1 fsi: core: Allow more BREAKs to recover a failing link

Recovering a failing FSI link can require more than a single BREAK command to reset the FSI slave. Test results indicate that communications can be restored when a second or third BREAK is sent when the previous attempts fail. Additionally, even if a BREAK succeeds during error recovery process the FSI slave may flag following access errors to SMODE, SISC, or SSTAT. Repeated BREAKs will get the slave out of this fail mode.

Signed-off-by Christopher Bostic <[email protected]>

---
 drivers/fsi/fsi-core.c | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

drivers/fsi/fsi-core.c +19 -8

index 8a17176..f3dd7f6 100644
@@ -85,6 +85,7 @@ struct fsi_slave {
 #define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
 
 static const int slave_retries = 2;
+static const int break_retries = 5;
 static int discard_errors;
 
 static int fsi_master_read(struct fsi_master *master, int link,

@@ -228,7 +229,7 @@ int fsi_slave_handle_error(struct fsi_slave *slave, bool write, uint32_t addr,
 		size_t size)
 {
 	struct fsi_master *master = slave->master;
-	int rc, link;
+	int rc, link, i;
 	uint32_t reg;
 	uint8_t id;

@@ -262,15 +263,25 @@ int fsi_slave_handle_error(struct fsi_slave *slave, bool write, uint32_t addr,
 	}
 
 	/* getting serious, reset the slave via BREAK */
-	rc = fsi_master_break(master, link);
-	if (rc)
-		return rc;
+	for (i = 0; i < break_retries; i++) {
 
-	rc = fsi_slave_set_smode(master, link, id);
-	if (rc)
-		return rc;
+		dev_dbg(&slave->dev, "recovery break attempt %d of %d max", i+1,
+			break_retries);
+
+		rc = fsi_master_break(master, link);
+		if (rc)
+			continue;
 
-	return fsi_slave_report_and_clear_errors(slave);
+		rc = fsi_slave_set_smode(master, link, id);
+		if (rc)
+			continue;
+
+		rc = fsi_slave_report_and_clear_errors(slave);
+		if (!rc)
+			break;
+	}
+
+	return rc;
 }
 
 int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,

Signature · 1 line

1.8.2.2

Jeremy Kerr

2017-10-23 02:57 UTC #1 lore raw

Hi Chris,

Quoted 4 lines

Recovering a failing FSI link can require more than a single BREAK command to reset the FSI slave. Test results indicate that communications can be restored when a second or third BREAK is sent when the previous attempts fail.

This seems somewhat suspicious to me. Do we have any indication from the CFAM documentation, or the folks responsible for the CFAM implentation, that multiple breaks will actually cause any difference in behaviour that a single one? Or is this based only on experimentation?

I'm worried that we'd be papering-over the underlying issue here.

Regards,

Jeremy

Andrew Jeffery

2017-10-30 04:04 UTC #2 lore raw

Quoted 7 lines · Jeremy Kerr

Hi Chris,
Quoted 4 lines
Recovering a failing FSI link can require more than a single BREAK command to reset the FSI slave. Test results indicate that communications can be restored when a second or third BREAK is sent when the previous attempts fail.

Quoted 7 lines

This seems somewhat suspicious to me. Do we have any indication from the CFAM documentation, or the folks responsible for the CFAM implentation, that multiple breaks will actually cause any difference in behaviour that a single one? Or is this based only on experimentation?
I'm worried that we'd be papering-over the underlying issue here.

Chris, my understanding is we're abandoning the approach in this patch. Is that correct?

Andrew

Christopher Bostic

author

2017-10-30 18:20 UTC #3 lore raw

Quoted 12 lines · Andrew Jeffery

Quoted 11 lines · Jeremy Kerr
Hi Chris,
Quoted 4 lines
Recovering a failing FSI link can require more than a single BREAK command to reset the FSI slave. Test results indicate that communications can be restored when a second or third BREAK is sent when the previous attempts fail.
This seems somewhat suspicious to me. Do we have any indication from the CFAM documentation, or the folks responsible for the CFAM implentation, that multiple breaks will actually cause any difference in behaviour that a single one? Or is this based only on experimentation?

Quoted 4 lines

Quoted 2 lines
I'm worried that we'd be papering-over the underlying issue here.
Chris, my understanding is we're abandoning the approach in this patch. Is that correct?

Yes that's correct. Focus is now on finding cause for the bus contention instead of recovering from it.

Chris

Quoted 2 lines

Andrew