[PATCH v2] i2c: davinci: Fix race when setting up for TX

[PATCH v2] i2c: davinci: Fix race when setting up for TX

[Jon Povey]

When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits > 1 byte long.

The hardware starts sending immediately that MDR is loaded. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.

Move the MDR load after DXR,IMR loads to avoid this race without locking.

Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985

Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
---
Troy, thanks for the input. I tried reordering the IMR load before but got
occasional timeouts. Went back to the logic analyser today and worked out
why, see above comment in the commit message.

Moving the MDR load seems to fix things without locking, much neater and
tiny patch.

As I understand it we can be confident inside i2c_davinci_xfer_msg() that
the peripheral is not busy sending or receiving something else, I had a
look at the other interrupt sources in the datasheet and this seems safe
enough.

I'm not sure what the correct thing to do for followup message IDs here..
My original email? Troy's? Clues welcome for next time.

 drivers/i2c/busses/i2c-davinci.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 72df4af..baa5209 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -349,9 +349,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 
 	dev->terminate = 0;
 
-	/* write the data into mode register */
-	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
-
 	/*
 	 * First byte should be set here, not after interrupt,
 	 * because transmit-data-ready interrupt can come before
@@ -371,6 +368,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 		w |= DAVINCI_I2C_IMR_XRDY;
 	davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
 
+	/* write the data into mode register; start transmitting */
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
 	r = wait_for_completion_interruptible_timeout(&dev->cmd_complete,
 						      dev->adapter.timeout);
 	if (r == 0) {
-- 
1.6.3.3

[PATCH v3] i2c: davinci: Fix race when setting up for TX

[Jon Povey]

When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits > 1 byte long.

The hardware starts sending immediately that MDR is loaded. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.

Move the MDR load after DXR,IMR loads to avoid this race without locking.

Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985

Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
---
Oops, v2 was based on the wrong version. Rebased so this should apply
against mainline.

Troy, thanks for the input. I tried reordering the IMR load before but got
occasional timeouts. Went back to the logic analyser today and worked out
why, see above comment in the commit message.

Moving the MDR load seems to fix things without locking, much neater and
tiny patch.

As I understand it we can be confident inside i2c_davinci_xfer_msg() that
the peripheral is not busy sending or receiving something else, I had a
look at the other interrupt sources in the datasheet and this seems safe
enough.

I'm not sure what the correct thing to do for followup message IDs here..
My original email? Troy's? Clues welcome for next time.

 drivers/i2c/busses/i2c-davinci.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 2222c87..b8feac5 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -357,9 +357,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 
 	dev->terminate = 0;
 
-	/* write the data into mode register */
-	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
-
 	/*
 	 * First byte should be set here, not after interrupt,
 	 * because transmit-data-ready interrupt can come before
@@ -371,6 +368,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 		dev->buf_len--;
 	}
 
+	/* write the data into mode register; start transmitting */
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
 	r = wait_for_completion_interruptible_timeout(&dev->cmd_complete,
 						      dev->adapter.timeout);
 	if (r == 0) {
-- 
1.6.3.3

RE: [PATCH v3] i2c: davinci: Fix race when setting up for TX

[Sudhakar Rajashekhara]

Hi,

On Fri, Sep 17, 2010 at 08:32:11, Jon Povey wrote:
> When setting up to transmit, a race exists between the ISR and
> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
> This is mostly visible for transmits > 1 byte long.
> 
> The hardware starts sending immediately that MDR is loaded. IMR trickery
> doesn't work because if we start sending, finish the first byte and an
> XRDY event occurs before we load IMR to unmask it, we never get an
> interrupt, and we timeout.
> 
> Move the MDR load after DXR,IMR loads to avoid this race without locking.
> 
> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
> 

I remember I had some issues on OMAP-L138 with this fix, that's when I
reverted to configuring ICMDR before writing to DXR (Please see here:
https://patchwork.kernel.org/patch/75262/). I checked the BIOS I2C
driver code for OMAP-L138 and there also we are configuring MDR before
accessing DXR.

Regards,
Sudhakar

Re: [PATCH v3] i2c: davinci: Fix race when setting up for TX

[Troy Kisky]

On 9/17/2010 6:09 AM, Sudhakar Rajashekhara wrote:
> Hi,
> 
> On Fri, Sep 17, 2010 at 08:32:11, Jon Povey wrote:
>> When setting up to transmit, a race exists between the ISR and
>> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>> This is mostly visible for transmits > 1 byte long.
>>
>> The hardware starts sending immediately that MDR is loaded. IMR trickery
>> doesn't work because if we start sending, finish the first byte and an
>> XRDY event occurs before we load IMR to unmask it, we never get an
>> interrupt, and we timeout.
>>
>> Move the MDR load after DXR,IMR loads to avoid this race without locking.
>>
>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>
> 
> I remember I had some issues on OMAP-L138 with this fix, that's when I
> reverted to configuring ICMDR before writing to DXR (Please see here:
> https://patchwork.kernel.org/patch/75262/). I checked the BIOS I2C
> driver code for OMAP-L138 and there also we are configuring MDR before
> accessing DXR.
> 
> Regards,
> Sudhakar

How about killing the lines from commit c6c7c729a22bfeb8e63eafce48dbaeea20e68703
-------------------------------
/*
 * First byte should be set here, not after interrupt,
 * because transmit-data-ready interrupt can come before
 * NACK-interrupt during sending of previous message and
 * ICDXR may have wrong data
 */
if ((!(msg->flags & I2C_M_RD)) && dev->buf_len) {
        davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev->buf++);
        dev->buf_len--;
}
----------------------

and resetting the i2c upon a NAK interrupt (after the stop) to clear the bad fifo data?

RE: [PATCH v3] i2c: davinci: Fix race when setting up for TX

[Jon Povey]

Troy Kisky wrote:
> On 9/17/2010 6:09 AM, Sudhakar Rajashekhara wrote:
>> Hi,

Seems I didn't get Sudhakar's email.. I wonder why?

>> On Fri, Sep 17, 2010 at 08:32:11, Jon Povey wrote:
>>> Move the MDR load after DXR,IMR loads to avoid this race without
>>> locking.
>>
>> I remember I had some issues on OMAP-L138 with this fix, that's when
>> I reverted to configuring ICMDR before writing to DXR (Please see
>> here: https://patchwork.kernel.org/patch/75262/). I checked the BIOS
>> I2C driver code for OMAP-L138 and there also we are configuring MDR
>> before accessing DXR.

Ah :/

> How about killing the lines from commit
> c6c7c729a22bfeb8e63eafce48dbaeea20e68703
> -------------------------------
> /*
>  * First byte should be set here, not after interrupt,
>  * because transmit-data-ready interrupt can come before
>  * NACK-interrupt during sending of previous message and
>  * ICDXR may have wrong data
>  */
> if ((!(msg->flags & I2C_M_RD)) && dev->buf_len) {
>         davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev->buf++);
> dev->buf_len--; }
> ----------------------
>
> and resetting the i2c upon a NAK interrupt (after the stop)
> to clear the bad fifo data?

I can't really comment on how valid that would be and can't easily test it.

However preloading DXR does save one interrupt on transmit so the whole operation is faster and more efficient.

Maybe v1 of my patch, with locking, is the best option?

--
Jon Povey
jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

Re: [PATCH v3] i2c: davinci: Fix race when setting up for TX

[Troy Kisky]

>> On 9/17/2010 6:09 AM, Sudhakar Rajashekhara wrote:
>>> I remember I had some issues on OMAP-L138 with this fix, that's when
>>> I reverted to configuring ICMDR before writing to DXR (Please see
>>> here: https://patchwork.kernel.org/patch/75262/). I checked the BIOS
>>> I2C driver code for OMAP-L138 and there also we are configuring MDR
>>> before accessing DXR.
> 
> Ah :/
> 
>>
>> and resetting the i2c upon a NAK interrupt (after the stop)
>> to clear the bad fifo data?
> 
> I can't really comment on how valid that would be and can't easily test it.
> 
> However preloading DXR does save one interrupt on transmit so the whole operation is faster and more efficient.
> 
> Maybe v1 of my patch, with locking, is the best option?
> 
> --
> Jon Povey

How about writing MDR twice? Once where Sudakar wants it, without the start bit.
And then where you want it with the start bit?


Troy

[PATCH v4] i2c: davinci: Fix race when setting up for TX

[Jon Povey]

When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits > 1 byte long.

The hardware starts sending immediately that MDR.STT is set. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.

Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
settings before DXR for correct behaviour, so load MDR first with
STT cleared and later load again with STT set.

Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985

Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
Reworked after comments by Troy and Sudhakar.

Looking at the datasheet it seemed like setting STP without STT early
might cause a stray STOP to be generated, so I moved it into the second
MDR load.

This passes a quick smoke test but I can't do much more testing right at
the moment. Sudhakar, your comments would be welcomed.

 drivers/i2c/busses/i2c-davinci.c |   24 +++++++++++++++---------
 1 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 2222c87..5795c83 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -331,21 +331,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 	INIT_COMPLETION(dev->cmd_complete);
 	dev->cmd_err = 0;
 
-	/* Take I2C out of reset, configure it as master and set the
-	 * start bit */
-	flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST | DAVINCI_I2C_MDR_STT;
+	/* Take I2C out of reset and configure it as master */
+	flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST;
 
 	/* if the slave address is ten bit address, enable XA bit */
 	if (msg->flags & I2C_M_TEN)
 		flag |= DAVINCI_I2C_MDR_XA;
 	if (!(msg->flags & I2C_M_RD))
 		flag |= DAVINCI_I2C_MDR_TRX;
-	if (stop)
-		flag |= DAVINCI_I2C_MDR_STP;
-	if (msg->len == 0) {
+	if (msg->len == 0)
 		flag |= DAVINCI_I2C_MDR_RM;
-		flag &= ~DAVINCI_I2C_MDR_STP;
-	}
 
 	/* Enable receive or transmit interrupts */
 	w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
@@ -357,7 +352,11 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 
 	dev->terminate = 0;
 
-	/* write the data into mode register */
+	/*
+	 * Write mode register first as needed for correct behaviour
+	 * on OMAP-L138, but don't set STT yet to avoid a race with XRDY
+	 * occuring before we have loaded DXR
+	 */
 	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
 
 	/*
@@ -365,12 +364,19 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 	 * because transmit-data-ready interrupt can come before
 	 * NACK-interrupt during sending of previous message and
 	 * ICDXR may have wrong data
+	 * It also saves us one interrupt, slightly faster
 	 */
 	if ((!(msg->flags & I2C_M_RD)) && dev->buf_len) {
 		davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev->buf++);
 		dev->buf_len--;
 	}
 
+	/* Set STT to begin transmit now DXR is loaded */
+	flag |= DAVINCI_I2C_MDR_STT;
+	if (stop && msg->len != 0)
+		flag |= DAVINCI_I2C_MDR_STP;
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
 	r = wait_for_completion_interruptible_timeout(&dev->cmd_complete,
 						      dev->adapter.timeout);
 	if (r == 0) {
-- 
1.6.3.3

RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Sudhakar Rajashekhara]

Hi,

On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
> When setting up to transmit, a race exists between the ISR and
> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
> This is mostly visible for transmits > 1 byte long.
> 
> The hardware starts sending immediately that MDR.STT is set. IMR trickery
> doesn't work because if we start sending, finish the first byte and an
> XRDY event occurs before we load IMR to unmask it, we never get an
> interrupt, and we timeout.
> 
> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
> settings before DXR for correct behaviour, so load MDR first with
> STT cleared and later load again with STT set.
> 
> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
> 
> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> ---
> Reworked after comments by Troy and Sudhakar.
> 
> Looking at the datasheet it seemed like setting STP without STT early
> might cause a stray STOP to be generated, so I moved it into the second
> MDR load.
> 
> This passes a quick smoke test but I can't do much more testing right at
> the moment. Sudhakar, your comments would be welcomed.
> 

Looks good to me. I can test on couple of platforms I have and update the result
by tomorrow.

Thanks,
Sudhakar

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Troy Kisky]

On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote:
> Hi,
> 
> On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
>> When setting up to transmit, a race exists between the ISR and
>> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>> This is mostly visible for transmits > 1 byte long.
>>
>> The hardware starts sending immediately that MDR.STT is set. IMR trickery
>> doesn't work because if we start sending, finish the first byte and an
>> XRDY event occurs before we load IMR to unmask it, we never get an
>> interrupt, and we timeout.
>>
>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
>> settings before DXR for correct behaviour, so load MDR first with
>> STT cleared and later load again with STT set.
>>
>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>
>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> ---
>> Reworked after comments by Troy and Sudhakar.
>>
>> Looking at the datasheet it seemed like setting STP without STT early
>> might cause a stray STOP to be generated, so I moved it into the second
>> MDR load.
>>
>> This passes a quick smoke test but I can't do much more testing right at
>> the moment. Sudhakar, your comments would be welcomed.
>>
> 
> Looks good to me. I can test on couple of platforms I have and update the result
> by tomorrow.
> 
> Thanks,
> Sudhakar
> 
> 
> 
I like it too. I hope it works for omap.

Thanks as well
Troy

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Ben Dooks]

On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote:
> On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote:
> > Hi,
> > 
> > On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
> >> When setting up to transmit, a race exists between the ISR and
> >> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
> >> This is mostly visible for transmits > 1 byte long.
> >>
> >> The hardware starts sending immediately that MDR.STT is set. IMR trickery
> >> doesn't work because if we start sending, finish the first byte and an
> >> XRDY event occurs before we load IMR to unmask it, we never get an
> >> interrupt, and we timeout.
> >>
> >> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
> >> settings before DXR for correct behaviour, so load MDR first with
> >> STT cleared and later load again with STT set.
> >>
> >> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
> >>
> >> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
> >> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> >> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> >> ---
> >> Reworked after comments by Troy and Sudhakar.
> >>
> >> Looking at the datasheet it seemed like setting STP without STT early
> >> might cause a stray STOP to be generated, so I moved it into the second
> >> MDR load.
> >>
> >> This passes a quick smoke test but I can't do much more testing right at
> >> the moment. Sudhakar, your comments would be welcomed.
> >>
> > 
> > Looks good to me. I can test on couple of platforms I have and update the result
> > by tomorrow.
> > 
> > Thanks,
> > Sudhakar
> > 
> > 
> > 
> I like it too. I hope it works for omap.
> 
> Thanks as well
> Troy

Ok, any objections to this being applied, or should I wait?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Sudhakar Rajashekhara]

Hi,

On Wed, Sep 22, 2010 at 05:39:16, Ben Dooks wrote:
> On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote:
> > On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote:
> > > Hi,
> > > 
> > > On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
> > >> When setting up to transmit, a race exists between the ISR and
> > >> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
> > >> This is mostly visible for transmits > 1 byte long.
> > >>
> > >> The hardware starts sending immediately that MDR.STT is set. IMR trickery
> > >> doesn't work because if we start sending, finish the first byte and an
> > >> XRDY event occurs before we load IMR to unmask it, we never get an
> > >> interrupt, and we timeout.
> > >>
> > >> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
> > >> settings before DXR for correct behaviour, so load MDR first with
> > >> STT cleared and later load again with STT set.
> > >>
> > >> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
> > >>
> > >> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
> > >> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> > >> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> > >> ---
> > >> Reworked after comments by Troy and Sudhakar.
> > >>
> > >> Looking at the datasheet it seemed like setting STP without STT early
> > >> might cause a stray STOP to be generated, so I moved it into the second
> > >> MDR load.
> > >>
> > >> This passes a quick smoke test but I can't do much more testing right at
> > >> the moment. Sudhakar, your comments would be welcomed.
> > >>
> > > 
> > > Looks good to me. I can test on couple of platforms I have and update the result
> > > by tomorrow.
> > > 
> > > Thanks,
> > > Sudhakar
> > > 
> > > 
> > > 
> > I like it too. I hope it works for omap.
> > 
> > Thanks as well
> > Troy
> 
> Ok, any objections to this being applied, or should I wait?
> 

I am stuck in some other work. If you can wait till I test it, that'll
be good.

Thanks,
Sudhakar

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Kevin Hilman]

Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> writes:

> On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote:
>> Hi,
>> 
>> On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
>>> When setting up to transmit, a race exists between the ISR and
>>> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>>> This is mostly visible for transmits > 1 byte long.
>>>
>>> The hardware starts sending immediately that MDR.STT is set. IMR trickery
>>> doesn't work because if we start sending, finish the first byte and an
>>> XRDY event occurs before we load IMR to unmask it, we never get an
>>> interrupt, and we timeout.
>>>
>>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
>>> settings before DXR for correct behaviour, so load MDR first with
>>> STT cleared and later load again with STT set.
>>>
>>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>>
>>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>>> ---
>>> Reworked after comments by Troy and Sudhakar.
>>>
>>> Looking at the datasheet it seemed like setting STP without STT early
>>> might cause a stray STOP to be generated, so I moved it into the second
>>> MDR load.
>>>
>>> This passes a quick smoke test but I can't do much more testing right at
>>> the moment. Sudhakar, your comments would be welcomed.
>>>
>> 
>> Looks good to me. I can test on couple of platforms I have and update the result
>> by tomorrow.
>> 
>> Thanks,
>> Sudhakar
>> 
>> 
>> 
> I like it too. I hope it works for omap.

Troy, can I take this as an Acked-by from you?  or a Tested-by?

Thanks,

Kevin

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Troy Kisky]

On 9/23/2010 7:27 AM, Kevin Hilman wrote:
> Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> writes:
> 
>> On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote:
>>> Hi,
>>>
>>> On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
>>>> When setting up to transmit, a race exists between the ISR and
>>>> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>>>> This is mostly visible for transmits > 1 byte long.
>>>>
>>>> The hardware starts sending immediately that MDR.STT is set. IMR trickery
>>>> doesn't work because if we start sending, finish the first byte and an
>>>> XRDY event occurs before we load IMR to unmask it, we never get an
>>>> interrupt, and we timeout.
>>>>
>>>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
>>>> settings before DXR for correct behaviour, so load MDR first with
>>>> STT cleared and later load again with STT set.
>>>>
>>>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>>>
>>>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>>>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>>>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>>>> ---
>>>> Reworked after comments by Troy and Sudhakar.
>>>>
>>>> Looking at the datasheet it seemed like setting STP without STT early
>>>> might cause a stray STOP to be generated, so I moved it into the second
>>>> MDR load.
>>>>
>>>> This passes a quick smoke test but I can't do much more testing right at
>>>> the moment. Sudhakar, your comments would be welcomed.
>>>>
>>>
>>> Looks good to me. I can test on couple of platforms I have and update the result
>>> by tomorrow.
>>>
>>> Thanks,
>>> Sudhakar
>>>
>>>
>>>
>> I like it too. I hope it works for omap.
> 
> Troy, can I take this as an Acked-by from you?  or a Tested-by?
> 
> Thanks,
> 
> Kevin
> 
Acked-by is fine, but I didn't test it.

Troy

RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Sudhakar Rajashekhara]

On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
> When setting up to transmit, a race exists between the ISR and
> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
> This is mostly visible for transmits > 1 byte long.
> 
> The hardware starts sending immediately that MDR.STT is set. IMR trickery
> doesn't work because if we start sending, finish the first byte and an
> XRDY event occurs before we load IMR to unmask it, we never get an
> interrupt, and we timeout.
> 
> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
> settings before DXR for correct behaviour, so load MDR first with
> STT cleared and later load again with STT set.
> 
> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
> 
> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> ---

Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>

Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with
i2cdetect function which probes all the devices on the i2c bus.

Thanks,
Sudhakar

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Kevin Hilman]

"Sudhakar Rajashekhara" <sudhakar.raj-l0cyMroinI0@public.gmane.org> writes:

> On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
>> When setting up to transmit, a race exists between the ISR and
>> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>> This is mostly visible for transmits > 1 byte long.
>> 
>> The hardware starts sending immediately that MDR.STT is set. IMR trickery
>> doesn't work because if we start sending, finish the first byte and an
>> XRDY event occurs before we load IMR to unmask it, we never get an
>> interrupt, and we timeout.
>> 
>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
>> settings before DXR for correct behaviour, so load MDR first with
>> STT cleared and later load again with STT set.
>> 
>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>> 
>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> ---
>
> Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>
> Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with
> i2cdetect function which probes all the devices on the i2c bus.


Ben, can you queue this one for 2.6.37 with the addition of:

Acked-by: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>

Thanks,

Kevin

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Ben Dooks]

On Fri, Sep 24, 2010 at 07:37:03AM -0700, Kevin Hilman wrote:
> "Sudhakar Rajashekhara" <sudhakar.raj-l0cyMroinI0@public.gmane.org> writes:
> 
> > On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
> >> When setting up to transmit, a race exists between the ISR and
> >> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
> >> This is mostly visible for transmits > 1 byte long.
> >> 
> >> The hardware starts sending immediately that MDR.STT is set. IMR trickery
> >> doesn't work because if we start sending, finish the first byte and an
> >> XRDY event occurs before we load IMR to unmask it, we never get an
> >> interrupt, and we timeout.
> >> 
> >> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
> >> settings before DXR for correct behaviour, so load MDR first with
> >> STT cleared and later load again with STT set.
> >> 
> >> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
> >> 
> >> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
> >> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> >> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> >> ---
> >
> > Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> >
> > Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with
> > i2cdetect function which probes all the devices on the i2c bus.
> 
> 
> Ben, can you queue this one for 2.6.37 with the addition of:

If it is a worthwhile bugfix i'll send it for the next -rc.
 
> Acked-by: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
> 
> Thanks,
> 
> Kevin
> 

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Kevin Hilman]

Ben Dooks <ben-SMNkleLxa3Z6Wcw2j4pizdi2O/JbrIOy@public.gmane.org> writes:

> On Fri, Sep 24, 2010 at 07:37:03AM -0700, Kevin Hilman wrote:
>> "Sudhakar Rajashekhara" <sudhakar.raj-l0cyMroinI0@public.gmane.org> writes:
>> 
>> > On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
>> >> When setting up to transmit, a race exists between the ISR and
>> >> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>> >> This is mostly visible for transmits > 1 byte long.
>> >> 
>> >> The hardware starts sending immediately that MDR.STT is set. IMR trickery
>> >> doesn't work because if we start sending, finish the first byte and an
>> >> XRDY event occurs before we load IMR to unmask it, we never get an
>> >> interrupt, and we timeout.
>> >> 
>> >> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
>> >> settings before DXR for correct behaviour, so load MDR first with
>> >> STT cleared and later load again with STT set.
>> >> 
>> >> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>> >> 
>> >> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>> >> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> >> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> >> ---
>> >
>> > Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> >
>> > Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with
>> > i2cdetect function which probes all the devices on the i2c bus.
>> 
>> 
>> Ben, can you queue this one for 2.6.37 with the addition of:
>
> If it is a worthwhile bugfix i'll send it for the next -rc.

OK, yeah.  It's probably better to queue for the next -rc.

Thanks,

Kevin

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Kevin Hilman]

Ben Dooks <ben-i2c-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:

> On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote:
>> On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote:
>> > Hi,
>> > 
>> > On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote:
>> >> When setting up to transmit, a race exists between the ISR and
>> >> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
>> >> This is mostly visible for transmits > 1 byte long.
>> >>
>> >> The hardware starts sending immediately that MDR.STT is set. IMR trickery
>> >> doesn't work because if we start sending, finish the first byte and an
>> >> XRDY event occurs before we load IMR to unmask it, we never get an
>> >> interrupt, and we timeout.
>> >>
>> >> Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
>> >> settings before DXR for correct behaviour, so load MDR first with
>> >> STT cleared and later load again with STT set.
>> >>
>> >> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>> >>
>> >> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>> >> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> >> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> >> ---
>> >> Reworked after comments by Troy and Sudhakar.
>> >>
>> >> Looking at the datasheet it seemed like setting STP without STT early
>> >> might cause a stray STOP to be generated, so I moved it into the second
>> >> MDR load.
>> >>
>> >> This passes a quick smoke test but I can't do much more testing right at
>> >> the moment. Sudhakar, your comments would be welcomed.
>> >>
>> > 
>> > Looks good to me. I can test on couple of platforms I have and update the result
>> > by tomorrow.
>> > 
>> > Thanks,
>> > Sudhakar
>> > 
>> > 
>> > 
>> I like it too. I hope it works for omap.
>> 
>> Thanks as well
>> Troy
>
> Ok, any objections to this being applied, or should I wait?

Please apply with:

Acked-by: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>

RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Jon Povey]

Hi Ben,

I am not on the i2c list but noticed this pull request:
http://www.spinics.net/linux/lists/linux-i2c/msg04022.html

I think you have the wrong (old) version of this patch in that branch,
http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0

The correct v4 one from the start of this thread has more lines
of patch and this commit message:

>>>>> When setting up to transmit, a race exists between the ISR and
>>>>> i2c_davinci_xfer_msg() trying to load the first byte and adjust
>>>>> counters. This is mostly visible for transmits > 1 byte long.
>>>>>
>>>>> The hardware starts sending immediately that MDR.STT is set. IMR
>>>>> trickery doesn't work because if we start sending, finish the
>>>>> first byte and an XRDY event occurs before we load IMR to unmask
>>>>> it, we never get an interrupt, and we timeout.
>>>>>
>>>>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires
>>>>> MDR mode settings before DXR for correct behaviour, so load MDR
>>>>> first with STT cleared and later load again with STT set.
>>>>>
>>>>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>>>>
>>>>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>>>>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>>>>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>

It also has some more acks and a tested, via Kevin:

> Acked-by: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
> Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>


--
Jon Povey
jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Kevin Hilman]

Jon Povey <Jon.Povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org> writes:

> Hi Ben,
>
> I am not on the i2c list but noticed this pull request:
> http://www.spinics.net/linux/lists/linux-i2c/msg04022.html
>
> I think you have the wrong (old) version of this patch in that branch,
> http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0
>
> The correct v4 one from the start of this thread has more lines
> of patch and this commit message:

It is also available in my davinci-i2c branch:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c

Thanks Jon for catching this,

Kevin

>>>>>> When setting up to transmit, a race exists between the ISR and
>>>>>> i2c_davinci_xfer_msg() trying to load the first byte and adjust
>>>>>> counters. This is mostly visible for transmits > 1 byte long.
>>>>>>
>>>>>> The hardware starts sending immediately that MDR.STT is set. IMR
>>>>>> trickery doesn't work because if we start sending, finish the
>>>>>> first byte and an XRDY event occurs before we load IMR to unmask
>>>>>> it, we never get an interrupt, and we timeout.
>>>>>>
>>>>>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires
>>>>>> MDR mode settings before DXR for correct behaviour, so load MDR
>>>>>> first with STT cleared and later load again with STT set.
>>>>>>
>>>>>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>>>>>
>>>>>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>>>>>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>>>>>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>
> It also has some more acks and a tested, via Kevin:
>
>> Acked-by: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
>
>
> --
> Jon Povey
> jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org
>
> Racelogic is a limited company registered in England. Registered number 2743719 .
> Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
>
> The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Kevin Hilman]

Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org> writes:

> Jon Povey <Jon.Povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org> writes:
>
>> Hi Ben,
>>
>> I am not on the i2c list but noticed this pull request:
>> http://www.spinics.net/linux/lists/linux-i2c/msg04022.html
>>
>> I think you have the wrong (old) version of this patch in that branch,
>> http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0
>>
>> The correct v4 one from the start of this thread has more lines
>> of patch and this commit message:
>
> It is also available in my davinci-i2c branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c
>
> Thanks Jon for catching this,

I just noticed that it has already been pulled and is part of -rc7.

Jon, care to submit a new patch with v4 diff and including the acks and
tested-bys?

Thanks,

Kevin

RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX

[Jon Povey]

Kevin Hilman wrote:
> I just noticed that it has already been pulled and is part of -rc7.
>
> Jon, care to submit a new patch with v4 diff and including
> the acks and
> tested-bys?

Done and sent:
Message-Id: <1286858825-21540-1-git-send-email-jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>

--
Jon Povey
jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network