[PATCH] at91sam9g45: fix i2c bus speed

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

Use a correct udelay value to get bus speed around 100KHz. The udelay
value was most likely copied from the older devices, but the 9g45
is signicantly faster (400MHz, DDR, ..), so a udelay of 2 gives a
bus speed of around 190KHz, which is too fast for some devices.
A udelay value of 5 gives a bus speed of around 90KHz here.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 arch/arm/mach-at91/at91sam9g45_devices.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 5e71ccd..1276bab 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -426,7 +426,7 @@ static struct i2c_gpio_platform_data pdata_i2c0 = {
 	.sda_is_open_drain	= 1,
 	.scl_pin		= AT91_PIN_PA21,
 	.scl_is_open_drain	= 1,
-	.udelay			= 2,		/* ~100 kHz */
+	.udelay			= 5,		/* ~100 kHz */
 };
 
 static struct platform_device at91sam9g45_twi0_device = {
@@ -440,7 +440,7 @@ static struct i2c_gpio_platform_data pdata_i2c1 = {
 	.sda_is_open_drain	= 1,
 	.scl_pin		= AT91_PIN_PB11,
 	.scl_is_open_drain	= 1,
-	.udelay			= 2,		/* ~100 kHz */
+	.udelay			= 5,		/* ~100 kHz */
 };
 
 static struct platform_device at91sam9g45_twi1_device = {
-- 
1.7.1

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:31 Wed 22 Sep     , Peter Korsgaard wrote:
> Use a correct udelay value to get bus speed around 100KHz. The udelay
> value was most likely copied from the older devices, but the 9g45
> is signicantly faster (400MHz, DDR, ..), so a udelay of 2 gives a
> bus speed of around 190KHz, which is too fast for some devices.
> A udelay value of 5 gives a bus speed of around 90KHz here.
> 
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
in this case it will be better to overwite it at board than force it for all
of them

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:

Hi,

 >> Use a correct udelay value to get bus speed around 100KHz. The udelay
 >> value was most likely copied from the older devices, but the 9g45
 >> is signicantly faster (400MHz, DDR, ..), so a udelay of 2 gives a
 >> bus speed of around 190KHz, which is too fast for some devices.
 >> A udelay value of 5 gives a bus speed of around 90KHz here.
 >> 
 >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

 Jean-Christophe> in this case it will be better to overwite it at board
 Jean-Christophe> than force it for all of them

You don't expect most 9g45 users will run at 400MHz? It seems pretty
likely to me. In any case, a safe (but somewhat slow) default seems
better than a potentially unsafe one.

Now, I agree that it would be nice to add an interface to tweak this
delay if needed (extra argument to at91_add_device_i2c()?), but that's
next to the discussion about what the default should be.

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:08 Wed 22 Sep     , Peter Korsgaard wrote:
> >>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:
> 
> Hi,
> 
>  >> Use a correct udelay value to get bus speed around 100KHz. The udelay
>  >> value was most likely copied from the older devices, but the 9g45
>  >> is signicantly faster (400MHz, DDR, ..), so a udelay of 2 gives a
>  >> bus speed of around 190KHz, which is too fast for some devices.
>  >> A udelay value of 5 gives a bus speed of around 90KHz here.
>  >> 
>  >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> 
>  Jean-Christophe> in this case it will be better to overwite it at board
>  Jean-Christophe> than force it for all of them
> 
> You don't expect most 9g45 users will run at 400MHz? It seems pretty
> likely to me. In any case, a safe (but somewhat slow) default seems
> better than a potentially unsafe one.
> 
> Now, I agree that it would be nice to add an interface to tweak this
> delay if needed (extra argument to at91_add_device_i2c()?), but that's
> next to the discussion about what the default should be.
I'd prefer to calculate it

so we specify which max freq we want in my mind it will be good to be as in
spi to specific per device it's max speed so we can adapt the bus freq

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Wolfgang Wegner]

Hi,

On Wed, Sep 22, 2010 at 04:34:06PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:08 Wed 22 Sep     , Peter Korsgaard wrote:
[...]
> > Now, I agree that it would be nice to add an interface to tweak this
> > delay if needed (extra argument to at91_add_device_i2c()?), but that's
> > next to the discussion about what the default should be.
> I'd prefer to calculate it
> 
> so we specify which max freq we want in my mind it will be good to be as in
> spi to specific per device it's max speed so we can adapt the bus freq

sorry in case I got you wrong, but please keep in mind that in
contrast to SPI the addressing in I2C is done via the serial data,
so the bus speed has to be _permanently_ adapted to match the
slowest device present.

Regards,
Wolfgang

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:54 Wed 22 Sep     , Wolfgang Wegner wrote:
> Hi,
> 
> On Wed, Sep 22, 2010 at 04:34:06PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 13:08 Wed 22 Sep     , Peter Korsgaard wrote:
> [...]
> > > Now, I agree that it would be nice to add an interface to tweak this
> > > delay if needed (extra argument to at91_add_device_i2c()?), but that's
> > > next to the discussion about what the default should be.
> > I'd prefer to calculate it
> > 
> > so we specify which max freq we want in my mind it will be good to be as in
> > spi to specific per device it's max speed so we can adapt the bus freq
> 
> sorry in case I got you wrong, but please keep in mind that in
> contrast to SPI the addressing in I2C is done via the serial data,
> so the bus speed has to be _permanently_ adapted to match the
> slowest device present.
yeah that's the idea but each i2c device specify it's speed then we put the
bus speed at the lowest

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:

Hi,

 >> You don't expect most 9g45 users will run at 400MHz? It seems pretty
 >> likely to me. In any case, a safe (but somewhat slow) default seems
 >> better than a potentially unsafe one.
 >> 
 >> Now, I agree that it would be nice to add an interface to tweak this
 >> delay if needed (extra argument to at91_add_device_i2c()?), but that's
 >> next to the discussion about what the default should be.

 Jean-Christophe> I'd prefer to calculate it

 Jean-Christophe> so we specify which max freq we want in my mind it
 Jean-Christophe> will be good to be as in spi to specific per device
 Jean-Christophe> it's max speed so we can adapt the bus freq

Yes, that sounds like a nice long term idea, but let's fix the immediate
problem in the mean time, right?

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Nicolas Ferre]

Le 22/09/2010 17:18, Peter Korsgaard :
>>>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:
> 
> Hi,
> 
>  >> You don't expect most 9g45 users will run at 400MHz? It seems pretty
>  >> likely to me. In any case, a safe (but somewhat slow) default seems
>  >> better than a potentially unsafe one.
>  >> 
>  >> Now, I agree that it would be nice to add an interface to tweak this
>  >> delay if needed (extra argument to at91_add_device_i2c()?), but that's
>  >> next to the discussion about what the default should be.
> 
>  Jean-Christophe> I'd prefer to calculate it
> 
>  Jean-Christophe> so we specify which max freq we want in my mind it
>  Jean-Christophe> will be good to be as in spi to specific per device
>  Jean-Christophe> it's max speed so we can adapt the bus freq
> 
> Yes, that sounds like a nice long term idea, but let's fix the immediate
> problem in the mean time, right?

I am in favor of this wisdom.

Bye,
-- 
Nicolas Ferre

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:18 Wed 22 Sep     , Peter Korsgaard wrote:
> >>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:
> 
> Hi,
> 
>  >> You don't expect most 9g45 users will run at 400MHz? It seems pretty
>  >> likely to me. In any case, a safe (but somewhat slow) default seems
>  >> better than a potentially unsafe one.
>  >> 
>  >> Now, I agree that it would be nice to add an interface to tweak this
>  >> delay if needed (extra argument to at91_add_device_i2c()?), but that's
>  >> next to the discussion about what the default should be.
> 
>  Jean-Christophe> I'd prefer to calculate it
> 
>  Jean-Christophe> so we specify which max freq we want in my mind it
>  Jean-Christophe> will be good to be as in spi to specific per device
>  Jean-Christophe> it's max speed so we can adapt the bus freq
> 
> Yes, that sounds like a nice long term idea, but let's fix the immediate
> problem in the mean time, right?
so it's will be beeter to add a parameter to fix the speed in the boards

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Nicolas Ferre]

Le 22/09/2010 11:31, Peter Korsgaard :
> Use a correct udelay value to get bus speed around 100KHz. The udelay
> value was most likely copied from the older devices, but the 9g45
> is signicantly faster (400MHz, DDR, ..), so a udelay of 2 gives a
> bus speed of around 190KHz, which is too fast for some devices.
> A udelay value of 5 gives a bus speed of around 90KHz here.
> 
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> ---
>  arch/arm/mach-at91/at91sam9g45_devices.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
> index 5e71ccd..1276bab 100644
> --- a/arch/arm/mach-at91/at91sam9g45_devices.c
> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
> @@ -426,7 +426,7 @@ static struct i2c_gpio_platform_data pdata_i2c0 = {
>  	.sda_is_open_drain	= 1,
>  	.scl_pin		= AT91_PIN_PA21,
>  	.scl_is_open_drain	= 1,
> -	.udelay			= 2,		/* ~100 kHz */
> +	.udelay			= 5,		/* ~100 kHz */
>  };
>  
>  static struct platform_device at91sam9g45_twi0_device = {
> @@ -440,7 +440,7 @@ static struct i2c_gpio_platform_data pdata_i2c1 = {
>  	.sda_is_open_drain	= 1,
>  	.scl_pin		= AT91_PIN_PB11,
>  	.scl_is_open_drain	= 1,
> -	.udelay			= 2,		/* ~100 kHz */
> +	.udelay			= 5,		/* ~100 kHz */
>  };
>  
>  static struct platform_device at91sam9g45_twi1_device = {


-- 
Nicolas Ferre

[PATCH] at91sam9g45: fix i2c bus speed

[Nicolas Ferre]

Le 22/09/2010 11:31, Peter Korsgaard :
> Use a correct udelay value to get bus speed around 100KHz. The udelay
> value was most likely copied from the older devices, but the 9g45
> is signicantly faster (400MHz, DDR, ..), so a udelay of 2 gives a
> bus speed of around 190KHz, which is too fast for some devices.
> A udelay value of 5 gives a bus speed of around 90KHz here.
> 
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
>  arch/arm/mach-at91/at91sam9g45_devices.c |    4 ++--

By the way, I suspect that at91sam9g20 has the same issue (400MHz core
also)...

We may also have a look at at91sam9g10 which embeds a 266MHz core....

[..]

Best regards,
-- 
Nicolas Ferre

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Nicolas" == Nicolas Ferre <nicolas.ferre@atmel.com> writes:

Hi,

 Nicolas> By the way, I suspect that at91sam9g20 has the same issue
 Nicolas> (400MHz core also)...

 Nicolas> We may also have a look at at91sam9g10 which embeds a 266MHz
 Nicolas> core....

Yes, but I don't have access that hw, so it's hard to know exact udelay
values. udelay=5 for 9g20 and udelay=3 for 9g10 probably aren't far off,
but it would be nice if someone with hw could test.

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Russell King - ARM Linux]

On Thu, Sep 23, 2010 at 11:22:36AM +0200, Peter Korsgaard wrote:
> >>>>> "Nicolas" == Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> 
> Hi,
> 
>  Nicolas> By the way, I suspect that at91sam9g20 has the same issue
>  Nicolas> (400MHz core also)...
> 
>  Nicolas> We may also have a look at at91sam9g10 which embeds a 266MHz
>  Nicolas> core....
> 
> Yes, but I don't have access that hw, so it's hard to know exact udelay
> values. udelay=5 for 9g20 and udelay=3 for 9g10 probably aren't far off,
> but it would be nice if someone with hw could test.

udelay(5) should always give something approximating a 5us delay, as we
calibrate this delay loop against the system timer.  What I could believe
is probably going on here is that writing to the hardware is adding
additional delays - but that's nothing to do with the CPU speed itself.

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:31 Thu 23 Sep     , Russell King - ARM Linux wrote:
> On Thu, Sep 23, 2010 at 11:22:36AM +0200, Peter Korsgaard wrote:
> > >>>>> "Nicolas" == Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> > 
> > Hi,
> > 
> >  Nicolas> By the way, I suspect that at91sam9g20 has the same issue
> >  Nicolas> (400MHz core also)...
> > 
> >  Nicolas> We may also have a look at at91sam9g10 which embeds a 266MHz
> >  Nicolas> core....
> > 
> > Yes, but I don't have access that hw, so it's hard to know exact udelay
> > values. udelay=5 for 9g20 and udelay=3 for 9g10 probably aren't far off,
> > but it would be nice if someone with hw could test.
> 
> udelay(5) should always give something approximating a 5us delay, as we
> calibrate this delay loop against the system timer.  What I could believe
> is probably going on here is that writing to the hardware is adding
> additional delays - but that's nothing to do with the CPU speed itself.
 yeah right

I guess as the amba bus and the other IP also is faster so the time spend to
change the state of the pio differ for a chip to an other

and we can not fix it easly so I do think it will be better to pass the speed
of the bus that we want from the board and then calcualte it depending on the
SOC

as we will only have this issue when using bitbanging but we can do the same
for hardware i2c

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:

Hi,

 Jean-Christophe> and we can not fix it easly so I do think it will be
 Jean-Christophe> better to pass the speed of the bus that we want from
 Jean-Christophe> the board and then calcualte it depending on the SOC

Configurable i2c bus speed for boards wanting something else than the
standard 100KHz could certainly be a nice thing, but that's something
that can be added later when/if needed.

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:

Hi,

 Russell> udelay(5) should always give something approximating a 5us
 Russell> delay, as we calibrate this delay loop against the system
 Russell> timer.  What I could believe is probably going on here is that
 Russell> writing to the hardware is adding additional delays - but
 Russell> that's nothing to do with the CPU speed itself.

Well, the gpio handling (sw) overhead is to a certain degree related to
the CPU speed.

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Russell King - ARM Linux]

On Thu, Sep 23, 2010 at 12:21:14PM +0200, Peter Korsgaard wrote:
> >>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:
> 
>  Russell> udelay(5) should always give something approximating a 5us
>  Russell> delay, as we calibrate this delay loop against the system
>  Russell> timer.  What I could believe is probably going on here is that
>  Russell> writing to the hardware is adding additional delays - but
>  Russell> that's nothing to do with the CPU speed itself.
> 
> Well, the gpio handling (sw) overhead is to a certain degree related to
> the CPU speed.

Isn't that what I said?

Jean is right - if you want to care this much about getting the I2C
transfer rate as close to 100kHz or 400kHz (without exceeding it),
you need to pass the required speed and run some sort of calibration
in the driver to calculate the correct delay.

Howver, the danger of using 3us instead of 5us is that you may measure
3us using the bus conditions at the time of measurement - which may be
contributing to the delay.  What happens if these bus conditions change?
For example, if you move to a different operating point and the bus speed
increases ?

Note that the calibration approach will also suffer from this problem.

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:

Hi,

 Russell> Jean is right - if you want to care this much about getting the I2C
 Russell> transfer rate as close to 100kHz or 400kHz (without exceeding it),
 Russell> you need to pass the required speed and run some sort of calibration
 Russell> in the driver to calculate the correct delay.

I don't care about all those things. I just want to fix the obvious bug
that happened while copying this code from the older (slower) SoCs
without taking into consideration the faster gpio handling - E.G.

-       .udelay                 = 2,            /* ~100 kHz */
+       .udelay                 = 5,            /* ~100 kHz */

So the comment matches and devices that don't handle >100KHz works on
the new SoCs as well.

And yes, if you run the SoC at nonstandard (slower) speed this might be
slower than 100Khz, but that's still safe, so not a big deal.

And then if Jean wants to extend the interface to make the speed
configurable from the board code, he can do so independently of this
patch.

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:54 Thu 23 Sep     , Peter Korsgaard wrote:
> >>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:
> 
> Hi,
> 
>  Russell> Jean is right - if you want to care this much about getting the I2C
>  Russell> transfer rate as close to 100kHz or 400kHz (without exceeding it),
>  Russell> you need to pass the required speed and run some sort of calibration
>  Russell> in the driver to calculate the correct delay.
> 
> I don't care about all those things. I just want to fix the obvious bug
> that happened while copying this code from the older (slower) SoCs
> without taking into consideration the faster gpio handling - E.G.
> 
> -       .udelay                 = 2,            /* ~100 kHz */
> +       .udelay                 = 5,            /* ~100 kHz */
> 
> So the comment matches and devices that don't handle >100KHz works on
> the new SoCs as well.
> 
> And yes, if you run the SoC at nonstandard (slower) speed this might be
> slower than 100Khz, but that's still safe, so not a big deal.
except you can also overclock the SoC in some case so it's still not safe

and force this speed for all boards :(

so specify the speed in the board is the right way to fix the current issue

as you may find some stupid i2c chip that does not work at 100kHz (some low
cost MCU as example)

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Peter Korsgaard]

>>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:

Hi,

 >> And yes, if you run the SoC at nonstandard (slower) speed this might be
 >> slower than 100Khz, but that's still safe, so not a big deal.

 Jean-Christophe> except you can also overclock the SoC in some case so
 Jean-Christophe> it's still not safe

Sure, you can do lots of crazy stuff. Instead of discussion this back
and forward, do you agree that udelay=5 is better/safer/more sensible
than the current udelay=2 value?

 Jean-Christophe> and force this speed for all boards :(

Just like it has always been.

 Jean-Christophe> so specify the speed in the board is the right way to
 Jean-Christophe> fix the current issue

I disagree. The problem is that the I2C speed was forced to run too
fast, against what the comment says and the knowledge that some devices
don't support fast/highspeed i2c.

 Jean-Christophe> as you may find some stupid i2c chip that does not
 Jean-Christophe> work at 100kHz (some low cost MCU as example)

If they don't work at 100KHz, then they most likely don't work at 185KHz
either, so that's not a regression.

-- 
Bye, Peter Korsgaard

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:32 Thu 23 Sep     , Peter Korsgaard wrote:
> >>>>> "Jean-Christophe" == Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> writes:
> 
> Hi,
> 
>  >> And yes, if you run the SoC at nonstandard (slower) speed this might be
>  >> slower than 100Khz, but that's still safe, so not a big deal.
> 
>  Jean-Christophe> except you can also overclock the SoC in some case so
>  Jean-Christophe> it's still not safe
> 
> Sure, you can do lots of crazy stuff. Instead of discussion this back
> and forward, do you agree that udelay=5 is better/safer/more sensible
> than the current udelay=2 value?
no it's not safer it's hardcoded value where it's board specific
so we just close our eyes on the problem by doing this
it's time to fix it correctly
> 
>  Jean-Christophe> and force this speed for all boards :(
> 
> Just like it has always been.
does not means it's right

Best Regards,
J.

[PATCH] at91sam9g45: fix i2c bus speed

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:36 Thu 23 Sep     , Russell King - ARM Linux wrote:
> On Thu, Sep 23, 2010 at 12:21:14PM +0200, Peter Korsgaard wrote:
> > >>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes:
> > 
> >  Russell> udelay(5) should always give something approximating a 5us
> >  Russell> delay, as we calibrate this delay loop against the system
> >  Russell> timer.  What I could believe is probably going on here is that
> >  Russell> writing to the hardware is adding additional delays - but
> >  Russell> that's nothing to do with the CPU speed itself.
> > 
> > Well, the gpio handling (sw) overhead is to a certain degree related to
> > the CPU speed.
> 
> Isn't that what I said?
> 
> Jean is right - if you want to care this much about getting the I2C
> transfer rate as close to 100kHz or 400kHz (without exceeding it),
> you need to pass the required speed and run some sort of calibration
> in the driver to calculate the correct delay.
> 
> Howver, the danger of using 3us instead of 5us is that you may measure
> 3us using the bus conditions at the time of measurement - which may be
> contributing to the delay.  What happens if these bus conditions change?
> For example, if you move to a different operating point and the bus speed
> increases ?
> 
> Note that the calibration approach will also suffer from this problem.
I was thinking of a pseudo clock maybe that we will make evolving depending of
the bus clock typically PM
but I'm still afraid that will also depend on the cpu load but it we take a
max boundry when the cpu load is low at least we will not increase the bus max
speed

Best Regards,
J.