Re: [PATCH 0/9] i2c: rcar: tackle race conditions in the driver

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]


> > 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]