On 8/24/20 10:27 AM, Raviteja Narayanam wrote: [...] >>>>> So, this local_irq_save()/local_irq_restore() is not related to >>>>> exclusive access in the driver (xiic_process vs xiic_start), but to >>>>> supply the >>>> byte count to controller before it completes transmitting START and >>>> slave address. >>>> >>>> But then shouldn't the XIIC IP be fixed / extended with support for >>>> such an atomic update instead ? >>> >>> I have started communicating with the hardware team on why the IP >> behavior is like this. >> >> Any news from the hardware team ? > > " The expectation from the IP is un interrupted read i.e the read command should be un interrupted and max delay expected is not more than 35-40 us provided IIC frequency is 100 Khz. Please check if we can manage this in Software. If delay is not managed enable iic control only after stop related data is received" > That was the response as is. > The workaround suggested above is to enable the AXI I2C only after second register write(STOP bit info with read count) is completed. This is not generic, so we couldn't move forward. > Our typical application scenario is like this "START WRITE, REPEATED START READ, STOP". So, we must enable AXI I2C before read count is sent. So, if I understand it correctly, the XIIC IP is broken and cannot be fixed in software reliably ? How shall we proceed then ?
