> -----Original Message----- > From: Marek Vasut <marex@xxxxxxx> > Sent: Wednesday, August 26, 2020 2:21 AM > 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/25/20 11:44 AM, Raviteja Narayanam wrote: > > Hi, > > [...] > > >>>>>>> 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. > > Is this dynamic/standard mode switching what is already in the downstream > xilinx kernel tree ? > > I think we should fix what is already upstream first, and only then add more > complexity. Yes, agreed. But, that would be a hardware fix in the future IP release. Since we have to support existing IP versions, we are planning to upstream the standard mode and based on the DT property (IP version), we will switch. Thanks, Raviteja N > > [...]
