> -----Original Message----- > From: Marek Vasut <marex@xxxxxxx> > Sent: Monday, August 24, 2020 5:28 PM > To: Raviteja Narayanam <rna@xxxxxxxxxx>; linux-i2c@xxxxxxxxxxxxxxx > Cc: Michal Simek <michals@xxxxxxxxxx>; Shubhrajyoti Datta > <shubhraj@xxxxxxxxxx>; Wolfram Sang <wsa@xxxxxxxxxx>; Srinivas Goud > <sgoud@xxxxxxxxxx> > Subject: Re: [PATCH 2/5] i2c: xiic: Drop broken interrupt handler > > 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 ? We are thinking of two options. 1. Trying for a SW fix to workaround this problem. Waiting on the HW IP team for any other suggestions. 2. XIIC IP has two modes of operation as stated in the user guide - Dynamic and Standard modes. Currently, the linux driver is using only dynamic mode and this bug appears here. The SW programming for standard mode is different and we are testing it for all possible use cases. Once That comes out successful, we will send out the patches.
