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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Wolfram,

On Thursday 03 September 2015 22:40:00 Wolfram Sang wrote:
> >> 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.

I'll test it ASAP, but that might take a while as I'm busy with VSP+DU on Gen3 
now.

> >> 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.

I meant without polling. Does the hardware design prevent from using I2C in 
interrupt mode in a race-free way ?

-- 
Regards,

Laurent Pinchart