Hi Rayagonda/Dhananjay, On 8/5/2020 2:17 AM, Wolfram Sang wrote: > On Mon, Jul 27, 2020 at 01:43:40PM -0700, Ray Jui wrote: >> >> >> On 7/27/2020 1:26 PM, Wolfram Sang wrote: >>> On Mon, Jul 27, 2020 at 08:13:46PM +0200, Wolfram Sang wrote: >>>> >>>>> Can you confirm that even if we have irq pending at the i2c IP core >>>>> level, as long as we execute Step 2. below (to disable/mask all slave >>>>> interrupts), after 'enable_irq' is called, we still will not receive any >>>>> further i2c slave interrupt? >>>> >>>> This is HW dependant. From my tests with Renesas HW, this is not the >>>> case. But the actual error case was impossible to trigger for me, so >>>> far. I might try again later. But even in the worst case, I would only >>>> get a "spurious interrupt" and not an NULL-ptr OOPS. >>> >>> Let me explain how I verified this: >>> >>> 0) add a debug print whenever the slave irq part is called >>> >>> 1) Put a 2 second delay after disable_irq() and before clearing >>> interrupt enable register >>> >>> 2) unbind the slave driver in the background, triggering the 2s delay >>> >>> 3) during the delay, try to read from the to-be-unbound slave in the >>> foreground >>> >>> 4) ensure there is no prinout from the slave irq >>> >>> Worked fine for me with the Renesas R-Car I2C IP interface. As mentioned >>> before, I couldn't trigger a bad case with my setup. So, I hope this new >>> fix will work for Rayagonda's test case, too! >>> >> >> Sure. I suggest Dhananjay gives the sequence you proposed here a try >> (with delay added during the testing to widen the window to cover corner >> cases). If it works, we can just go with your proposed sequence here. > > Any progress yet? > I don't know if Dhananjay is actively working on this or not. Rayagonda, given that you have the I2C slave setup already, do you think you can help to to test and above sequence from Wolfram (by using the widened delay window as instructed)? Thanks, Ray
