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

On Thu, Sep 03, 2015 at 10:20:04PM +0200, Wolfram Sang wrote: > Hello RCar Fans! > > Two issues people have seen with the i2c-rcar driver was: > > a) immediately restarted messages after NACK from client > b) duplicated data bytes in messages > > Some people already worked on those and had a

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

> > 'No EDID data' says bootlog. Also, all 0 when reading that i2c client > > address afterwards. I don't see or sense anything suspicious with the > > I2C transfers itself from remote. > > Did you use the DRM/KMS modetest program to display stuff on the HDMI > monitor? To trigger the error case

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

> Yes, now a HD-ready TV is hooked up. It should give you something over > EDID. Let me know when you're done and I'll move things back. 'No EDID data' says bootlog. Also, all 0 when reading that i2c client address afterwards. I don't see or sense anything suspicious with the I2C transfers

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

Hi Wolfram, On Tue, Sep 8, 2015 at 7:53 PM, Wolfram Sang wrote: > >> Yes, now a HD-ready TV is hooked up. It should give you something over >> EDID. Let me know when you're done and I'll move things back. > > 'No EDID data' says bootlog. Also, all 0 when reading that i2c

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

Hi Wolfram, On Sat, Sep 5, 2015 at 4:31 PM, Wolfram Sang wrote: > On Fri, Sep 04, 2015 at 01:33:39PM +0900, Magnus Damm wrote: >> Hi Wolfram, >> >> On Fri, Sep 4, 2015 at 5:40 AM, Wolfram Sang wrote: >> > >> >> > So I refactored the driver to setup new

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

On Fri, Sep 04, 2015 at 01:33:39PM +0900, Magnus Damm wrote: > Hi Wolfram, > > On Fri, Sep 4, 2015 at 5:40 AM, 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

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

Hello RCar Fans! Two issues people have seen with the i2c-rcar driver was: a) immediately restarted messages after NACK from client b) duplicated data bytes in messages Some people already worked on those and had a tough time because it was hard to reproduce these issues on non-customer setup.

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

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

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

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 >

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

> I meant without polling. Does the hardware design prevent from using I2C in > interrupt mode in a race-free way ? Yes, when we get a NACK after address phase. HW automatically creates a STOP condition after a NACK. After this STOP, if we haven't been fast enough to clear the ESG bit (which

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

Hi Wolfram, On Thursday 03 September 2015 22:20:04 Wolfram Sang wrote: > Hello RCar Fans! > > Two issues people have seen with the i2c-rcar driver was: > > a) immediately restarted messages after NACK from client > b) duplicated data bytes in messages > > Some people already worked on those

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

Hi Wolfram, On Fri, Sep 4, 2015 at 5:40 AM, 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