| Message ID | ZG5UI7cJvmLXvtLg@davidzhe-DESK |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v3] i2c: designware: fix idx_write_cnt in read loop | expand |
On 5/24/23 21:14, 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> > --- > Changes in v2: > - Send I2C_SLAVE_WRITE_REQUESTED for HW does not have FIRST_DATA_BYTE > Changes in v3: > - Move DW_IC_DATA_CMD_FIRST_DATA_BYTE next to DW_IC_DATA_CMD_DAT define > --- > drivers/i2c/busses/i2c-designware-core.h | 1 + > drivers/i2c/busses/i2c-designware-slave.c | 4 ++++ > 2 files changed, 5 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h > index c5d87aae39c6..bf23bfb51aea 100644 > --- a/drivers/i2c/busses/i2c-designware-core.h > +++ b/drivers/i2c/busses/i2c-designware-core.h > @@ -40,6 +40,7 @@ > #define DW_IC_CON_BUS_CLEAR_CTRL BIT(11) > > #define DW_IC_DATA_CMD_DAT GENMASK(7, 0) > +#define DW_IC_DATA_CMD_FIRST_DATA_BYTE BIT(11) > > /* > * Registers offset > diff --git a/drivers/i2c/busses/i2c-designware-slave.c b/drivers/i2c/busses/i2c-designware-slave.c > index cec25054bb24..2e079cf20bb5 100644 > --- a/drivers/i2c/busses/i2c-designware-slave.c > +++ b/drivers/i2c/busses/i2c-designware-slave.c > @@ -176,6 +176,10 @@ static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id) > > 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); Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
On Fri, May 26, 2023 at 04:58:26PM +0300, Jarkko Nikula wrote: > On 5/24/23 21:14, 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> Applied to for-current, thanks! Someone maybe has a Fixes tag for it?
On 6/5/23 13:02, Wolfram Sang wrote: > On Fri, May 26, 2023 at 04:58:26PM +0300, Jarkko Nikula wrote: >> On 5/24/23 21:14, 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> > > Applied to for-current, thanks! > > Someone maybe has a Fixes tag for it? > In my opinion this patch is more improvement rather than a regression fix. I see it's continuation to the commits dcf1bf648f94 ("i2c: designware: Empty receive FIFO in slave interrupt handler") and 3b5f7f10ff6e ("i2c: designware: slave should do WRITE_REQUESTED before WRITE_RECEIVED").
> In my opinion this patch is more improvement rather than a regression fix.
Okay, then, thanks!
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h index c5d87aae39c6..bf23bfb51aea 100644 --- a/drivers/i2c/busses/i2c-designware-core.h +++ b/drivers/i2c/busses/i2c-designware-core.h @@ -40,6 +40,7 @@ #define DW_IC_CON_BUS_CLEAR_CTRL BIT(11) #define DW_IC_DATA_CMD_DAT GENMASK(7, 0) +#define DW_IC_DATA_CMD_FIRST_DATA_BYTE BIT(11) /* * Registers offset diff --git a/drivers/i2c/busses/i2c-designware-slave.c b/drivers/i2c/busses/i2c-designware-slave.c index cec25054bb24..2e079cf20bb5 100644 --- a/drivers/i2c/busses/i2c-designware-slave.c +++ b/drivers/i2c/busses/i2c-designware-slave.c @@ -176,6 +176,10 @@ static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id) 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> --- Changes in v2: - Send I2C_SLAVE_WRITE_REQUESTED for HW does not have FIRST_DATA_BYTE Changes in v3: - Move DW_IC_DATA_CMD_FIRST_DATA_BYTE next to DW_IC_DATA_CMD_DAT define --- drivers/i2c/busses/i2c-designware-core.h | 1 + drivers/i2c/busses/i2c-designware-slave.c | 4 ++++ 2 files changed, 5 insertions(+)