| Message ID | ZGZpEyITTuoBUEAM@davidzhe-DESK |
|---|---|
| State | New |
| Headers | show |
| Series | i2c: designware: fix idx_write_cnt in read loop | expand |
Hi On 5/18/23 21:06, David Zheng wrote: > With IC_INTR_RX_FULL slave interrupt handler reads data in a loop until > RX FIFO is empty. When testing with the slave-eeprom, each transaction > has 2 bytes for address/index and 1 byte for value, the address byte > can be written as data byte due to dropping STOP condition. > > In the test below, the master continuously writes to the slave, first 2 > bytes are index, 3rd byte is value and follow by a STOP condition. > > i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D1-D1] > i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D2-D2] > i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D3-D3] > > Upon receiving STOP condition slave eeprom would reset `idx_write_cnt` so > next 2 bytes can be treated as buffer index for upcoming transaction. > Supposedly the slave eeprom buffer would be written as > > EEPROM[0x00D1] = 0xD1 > EEPROM[0x00D2] = 0xD2 > EEPROM[0x00D3] = 0xD3 > > When CPU load is high the slave irq handler may not read fast enough, > the interrupt status can be seen as 0x204 with both DW_IC_INTR_STOP_DET > (0x200) and DW_IC_INTR_RX_FULL (0x4) bits. The slave device may see > the transactions below. > > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1794 : INTR_STAT=0x204 > 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x1790 : INTR_STAT=0x200 > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 > 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 > > After `D1` is received, read loop continues to read `00` which is the > first bype of next index. Since STOP condition is ignored by the loop, > eeprom buffer index increased to `D2` and `00` is written as value. > > So the slave eeprom buffer becomes > > EEPROM[0x00D1] = 0xD1 > EEPROM[0x00D2] = 0x00 > EEPROM[0x00D3] = 0xD3 > > The fix is to use `FIRST_DATA_BYTE` (bit 11) in `IC_DATA_CMD` to split > the transactions. The first index byte in this case would have bit 11 > set. Check this indication to inject I2C_SLAVE_WRITE_REQUESTED event > which will reset `idx_write_cnt` in slave eeprom. > > Signed-off-by: David Zheng <david.zheng@intel.com> > --- > drivers/i2c/busses/i2c-designware-core.h | 2 ++ > drivers/i2c/busses/i2c-designware-slave.c | 6 ++++-- > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h > index c5d87aae39c6..8b85147bd518 100644 > --- a/drivers/i2c/busses/i2c-designware-core.h > +++ b/drivers/i2c/busses/i2c-designware-core.h > @@ -123,6 +123,8 @@ > #define DW_IC_COMP_PARAM_1_SPEED_MODE_HIGH (BIT(2) | BIT(3)) > #define DW_IC_COMP_PARAM_1_SPEED_MODE_MASK GENMASK(3, 2) > > +#define DW_IC_DATA_CMD_FIRST_DATA_BYTE BIT(11) > + > /* > * Sofware status flags > */ > diff --git a/drivers/i2c/busses/i2c-designware-slave.c b/drivers/i2c/busses/i2c-designware-slave.c > index cec25054bb24..9549cbcf50aa 100644 > --- a/drivers/i2c/busses/i2c-designware-slave.c > +++ b/drivers/i2c/busses/i2c-designware-slave.c > @@ -170,12 +170,14 @@ static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id) > if (!(dev->status & STATUS_WRITE_IN_PROGRESS)) { > dev->status |= STATUS_WRITE_IN_PROGRESS; > dev->status &= ~STATUS_READ_IN_PROGRESS; > - i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, > - &val); > } > > do { > regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); > + if (tmp & DW_IC_DATA_CMD_FIRST_DATA_BYTE) > + i2c_slave_event(dev->slave, > + I2C_SLAVE_WRITE_REQUESTED, > + &val); > val = tmp; > i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED, > &val); I fear this might cause regression on some use case on HW that doesn't have the FIRST_DATA_BYTE bit in IC_DATA_CMD. That is available on newer Synopsys I2C IPs only. For example my test HW doesn't have it. This means the I2C_SLAVE_WRITE_REQUESTED is never delivered on these HWs that don't implement the FIRST_DATA_BYTE. My quick tests using i2c-slave-eeprom didn't show regression but I'm sure there is a case that will regress because of that.
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h index c5d87aae39c6..8b85147bd518 100644 --- a/drivers/i2c/busses/i2c-designware-core.h +++ b/drivers/i2c/busses/i2c-designware-core.h @@ -123,6 +123,8 @@ #define DW_IC_COMP_PARAM_1_SPEED_MODE_HIGH (BIT(2) | BIT(3)) #define DW_IC_COMP_PARAM_1_SPEED_MODE_MASK GENMASK(3, 2) +#define DW_IC_DATA_CMD_FIRST_DATA_BYTE BIT(11) + /* * Sofware status flags */ diff --git a/drivers/i2c/busses/i2c-designware-slave.c b/drivers/i2c/busses/i2c-designware-slave.c index cec25054bb24..9549cbcf50aa 100644 --- a/drivers/i2c/busses/i2c-designware-slave.c +++ b/drivers/i2c/busses/i2c-designware-slave.c @@ -170,12 +170,14 @@ static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id) if (!(dev->status & STATUS_WRITE_IN_PROGRESS)) { dev->status |= STATUS_WRITE_IN_PROGRESS; dev->status &= ~STATUS_READ_IN_PROGRESS; - i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, - &val); } do { regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); + if (tmp & DW_IC_DATA_CMD_FIRST_DATA_BYTE) + i2c_slave_event(dev->slave, + I2C_SLAVE_WRITE_REQUESTED, + &val); val = tmp; i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED, &val);
With IC_INTR_RX_FULL slave interrupt handler reads data in a loop until RX FIFO is empty. When testing with the slave-eeprom, each transaction has 2 bytes for address/index and 1 byte for value, the address byte can be written as data byte due to dropping STOP condition. In the test below, the master continuously writes to the slave, first 2 bytes are index, 3rd byte is value and follow by a STOP condition. i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D1-D1] i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D2-D2] i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D3-D3] Upon receiving STOP condition slave eeprom would reset `idx_write_cnt` so next 2 bytes can be treated as buffer index for upcoming transaction. Supposedly the slave eeprom buffer would be written as EEPROM[0x00D1] = 0xD1 EEPROM[0x00D2] = 0xD2 EEPROM[0x00D3] = 0xD3 When CPU load is high the slave irq handler may not read fast enough, the interrupt status can be seen as 0x204 with both DW_IC_INTR_STOP_DET (0x200) and DW_IC_INTR_RX_FULL (0x4) bits. The slave device may see the transactions below. 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1794 : INTR_STAT=0x204 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x1790 : INTR_STAT=0x200 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 After `D1` is received, read loop continues to read `00` which is the first bype of next index. Since STOP condition is ignored by the loop, eeprom buffer index increased to `D2` and `00` is written as value. So the slave eeprom buffer becomes EEPROM[0x00D1] = 0xD1 EEPROM[0x00D2] = 0x00 EEPROM[0x00D3] = 0xD3 The fix is to use `FIRST_DATA_BYTE` (bit 11) in `IC_DATA_CMD` to split the transactions. The first index byte in this case would have bit 11 set. Check this indication to inject I2C_SLAVE_WRITE_REQUESTED event which will reset `idx_write_cnt` in slave eeprom. Signed-off-by: David Zheng <david.zheng@intel.com> --- drivers/i2c/busses/i2c-designware-core.h | 2 ++ drivers/i2c/busses/i2c-designware-slave.c | 6 ++++-- 2 files changed, 6 insertions(+), 2 deletions(-)