> > So I refactored the driver to setup new messages in interrupt context, too. > > This avoids the race for b) because we are now setting up the new message > > before we release the i2c bus clock (before we released the clock and set up > > the message in process context). > > Could this fix the HDMI EDID read issue on Koelsch ? I surely hope so. I can't test because I don't have Koelsch. > > c) is also fixed, this was not a race but a bug in the state handling. a) > > however is not fixed 100% :( We have the race window as small as possible > > now when utilizing interrupts, so it is an improvement and worked for my > > test cases well. There were experiments by me and Renesas engineers to use > > polling to prevent the issue but this caused other side effects, sadly. So, > > let's improve the situation now and let's see where we get. > > Does that mean that, due to hardware design, it's impossible to use I2C > interrupts in a race-free way ? It would be interesting to document why in a > commit log message, or possibly in the code itself. It can maybe be done when polling. However, this might need busy looping for ~1us. Also, the repeated start handling needs to be rewritten and I am not sure this goes well with polling.
Attachment:
signature.asc
Description: Digital signature
