Skip to contentSkip to conversation

i2c i.MX: Fix divider table

PATCH New Sascha Hauer 6 participants 15 messages Jul 5, 2012 – Jul 12, 2012

Subsystems (3)
Arm i.MX and Layerscape I2C subsystem host drivers Freescale i.MX I2C driver
lore
Share & tools
lore

Sascha Hauer

author maintainer
#0 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Signed-off-by Sascha Hauer <[email protected]>
---
 drivers/i2c/busses/i2c-imx.c |   31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)
drivers/i2c/busses/i2c-imx.c +18 -13
index 8d6b504..aabbe31 100644
@@ -98,22 +98,27 @@
  * Document Number: MC9328MXLRM, Rev. 5.1, 06/2007
  *
  * Duplicated divider values removed from list
+ *
+ * These values (mostly) do not match the ones in the datasheet because
+ * measurements have shown that the values are wrong. This was tested
+ * on i.MX1 and i.MX53, so it shoud be safe to assume that the SoCs in
+ * between behave the same.
  */
 
 static u16 __initdata i2c_clk_div[50][2] = {
-	{ 22,	0x20 }, { 24,	0x21 }, { 26,	0x22 }, { 28,	0x23 },
-	{ 30,	0x00 },	{ 32,	0x24 }, { 36,	0x25 }, { 40,	0x26 },
-	{ 42,	0x03 }, { 44,	0x27 },	{ 48,	0x28 }, { 52,	0x05 },
-	{ 56,	0x29 }, { 60,	0x06 }, { 64,	0x2A },	{ 72,	0x2B },
-	{ 80,	0x2C }, { 88,	0x09 }, { 96,	0x2D }, { 104,	0x0A },
-	{ 112,	0x2E }, { 128,	0x2F }, { 144,	0x0C }, { 160,	0x30 },
-	{ 192,	0x31 },	{ 224,	0x32 }, { 240,	0x0F }, { 256,	0x33 },
-	{ 288,	0x10 }, { 320,	0x34 },	{ 384,	0x35 }, { 448,	0x36 },
-	{ 480,	0x13 }, { 512,	0x37 }, { 576,	0x14 },	{ 640,	0x38 },
-	{ 768,	0x39 }, { 896,	0x3A }, { 960,	0x17 }, { 1024,	0x3B },
-	{ 1152,	0x18 }, { 1280,	0x3C }, { 1536,	0x3D }, { 1792,	0x3E },
-	{ 1920,	0x1B },	{ 2048,	0x3F }, { 2304,	0x1C }, { 2560,	0x1D },
-	{ 3072,	0x1E }, { 3840,	0x1F }
+	{ 30,	0x20 }, { 32,	0x21 }, { 34,	0x22 },	{ 36,	0x23 },
+	{ 38,	0x00 },	{ 40,	0x24 },	{ 44,	0x25 },	{ 48,	0x26 },
+	{ 50,	0x03 },	{ 52,	0x27 },	{ 56,	0x28 }, { 60,	0x05 },
+	{ 64,	0x29 }, { 68,	0x06 }, { 72,	0x2A },	{ 80,	0x2B },
+	{ 88,	0x2C }, { 96,	0x09 }, { 104,	0x2D }, { 112,	0x0A },
+	{ 120,	0x2E }, { 136,	0x2F }, { 152,	0x0C },	{ 168,	0x30 },
+	{ 200,	0x31 }, { 232,	0x32 }, { 248,	0x0F },	{ 264,	0x33 },
+	{ 288,	0x10 },	{ 328,	0x34 },	{ 392,	0x35 },	{ 456,	0x36 },
+	{ 480,	0x13 },	{ 520,	0x37 },	{ 576,	0x14 },	{ 648,	0x38 },
+	{ 776,	0x39 },	{ 904,	0x3A },	{ 960,	0x17 },	{ 1032,	0x3B },
+	{ 1152,	0x18 },	{ 1288,	0x3C },	{ 1544,	0x3D },	{ 1800,	0x3E },
+	{ 1920,	0x1B },	{ 2048,	0x3F },	{ 2304,	0x1C },	{ 2560,	0x1D },
+	{ 3072,	0x1E },	{ 3840,	0x1F }
 };
 
 struct imx_i2c_struct {
Signature · 1 line
1.7.10
#1 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Hi Sascha,

Quoted 3 lines · Sascha Hauer

+ * These values (mostly) do not match the ones in the datasheet because
+ * measurements have shown that the values are wrong. This was tested
+ * on i.MX1 and i.MX53, so it shoud be safe to assume that the SoCs in

s/shoud/should/

Quoted 2 lines

+ * between behave the same.
*/

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#2 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

In reply to Sascha Hauer
Quoted 5 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

We may need to check with IC guys? Or you've done?

Thanks
Richard

Quoted 59 lines
Signed-off-by Sascha Hauer <[email protected]>
---
 drivers/i2c/busses/i2c-imx.c |   31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)
drivers/i2c/busses/i2c-imx.c +18 -13
index 8d6b504..aabbe31 100644
@@ -98,22 +98,27 @@
  * Document Number: MC9328MXLRM, Rev. 5.1, 06/2007
  *
  * Duplicated divider values removed from list
+ *
+ * These values (mostly) do not match the ones in the datasheet because
+ * measurements have shown that the values are wrong. This was tested
+ * on i.MX1 and i.MX53, so it shoud be safe to assume that the SoCs in
+ * between behave the same.
  */
 
 static u16 __initdata i2c_clk_div[50][2] = {
-	{ 22,	0x20 }, { 24,	0x21 }, { 26,	0x22 }, { 28,	0x23 },
-	{ 30,	0x00 },	{ 32,	0x24 }, { 36,	0x25 }, { 40,	0x26 },
-	{ 42,	0x03 }, { 44,	0x27 },	{ 48,	0x28 }, { 52,	0x05 },
-	{ 56,	0x29 }, { 60,	0x06 }, { 64,	0x2A },	{ 72,	0x2B },
-	{ 80,	0x2C }, { 88,	0x09 }, { 96,	0x2D }, { 104,	0x0A },
-	{ 112,	0x2E }, { 128,	0x2F }, { 144,	0x0C }, { 160,	0x30 },
-	{ 192,	0x31 },	{ 224,	0x32 }, { 240,	0x0F }, { 256,	0x33 },
-	{ 288,	0x10 }, { 320,	0x34 },	{ 384,	0x35 }, { 448,	0x36 },
-	{ 480,	0x13 }, { 512,	0x37 }, { 576,	0x14 },	{ 640,	0x38 },
-	{ 768,	0x39 }, { 896,	0x3A }, { 960,	0x17 }, { 1024,	0x3B },
-	{ 1152,	0x18 }, { 1280,	0x3C }, { 1536,	0x3D }, { 1792,	0x3E },
-	{ 1920,	0x1B },	{ 2048,	0x3F }, { 2304,	0x1C }, { 2560,	0x1D },
-	{ 3072,	0x1E }, { 3840,	0x1F }
+	{ 30,	0x20 }, { 32,	0x21 }, { 34,	0x22 },	{ 36,	0x23 },
+	{ 38,	0x00 },	{ 40,	0x24 },	{ 44,	0x25 },	{ 48,	0x26 },
+	{ 50,	0x03 },	{ 52,	0x27 },	{ 56,	0x28 }, { 60,	0x05 },
+	{ 64,	0x29 }, { 68,	0x06 }, { 72,	0x2A },	{ 80,	0x2B },
+	{ 88,	0x2C }, { 96,	0x09 }, { 104,	0x2D }, { 112,	0x0A },
+	{ 120,	0x2E }, { 136,	0x2F }, { 152,	0x0C },	{ 168,	0x30 },
+	{ 200,	0x31 }, { 232,	0x32 }, { 248,	0x0F },	{ 264,	0x33 },
+	{ 288,	0x10 },	{ 328,	0x34 },	{ 392,	0x35 },	{ 456,	0x36 },
+	{ 480,	0x13 },	{ 520,	0x37 },	{ 576,	0x14 },	{ 648,	0x38 },
+	{ 776,	0x39 },	{ 904,	0x3A },	{ 960,	0x17 },	{ 1032,	0x3B },
+	{ 1152,	0x18 },	{ 1288,	0x3C },	{ 1544,	0x3D },	{ 1800,	0x3E },
+	{ 1920,	0x1B },	{ 2048,	0x3F },	{ 2304,	0x1C },	{ 2560,	0x1D },
+	{ 3072,	0x1E },	{ 3840,	0x1F }
 };
 
 struct imx_i2c_struct {
Signature · 7 lines
1.7.10


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
author maintainer
#3 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 7 lines · Richard Zhao
Quoted 5 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

We may need to check with IC guys? Or you've done?

I don't have contact to the IC guys. Could you do this? I'd be interested in the results.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#4 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 11 lines · Sascha Hauer
Quoted 7 lines · Richard Zhao
Quoted 5 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

We may need to check with IC guys? Or you've done?

I don't have contact to the IC guys. Could you do this? I'd be interested in the results.

Sure, but it may be slow, as you know, many people are in summer break.

Thanks
Richard

Quoted 15 lines

Sascha

Signature · 9 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
author maintainer
#5 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 8 lines · Richard Zhao
Quoted 7 lines · Sascha Hauer
Quoted 6 lines · Richard Zhao
Quoted 5 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Quoted 5 lines
Quoted 4 lines
Quoted 1 line

We may need to check with IC guys? Or you've done?

I don't have contact to the IC guys. Could you do this? I'd be interested in the results.

Sure, but it may be slow, as you know, many people are in summer break.

Thanks. It can take longer, the resulting frequencies are all too low, so we are on the safe side.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#6 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 9 lines · Sascha Hauer
Quoted 8 lines · Richard Zhao
Quoted 7 lines · Sascha Hauer
Quoted 6 lines · Richard Zhao
Quoted 5 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Quoted 9 lines
Quoted 4 lines
Quoted 3 lines
Quoted 1 line

We may need to check with IC guys? Or you've done?

I don't have contact to the IC guys. Could you do this? I'd be interested in the results.

Sure, but it may be slow, as you know, many people are in summer break.

Thanks. It can take longer, the resulting frequencies are all too low, so we are on the safe side.

Sascha

You mean safe before the patch is applied, not after. Right?

Troy

#7 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

In reply to Sascha Hauer
Quoted 9 lines · Sascha Hauer
Quoted 8 lines · Richard Zhao
Quoted 7 lines · Sascha Hauer
Quoted 6 lines · Richard Zhao
Quoted 5 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong. the values from first, third and fourth column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
Quoted 1 line

We may need to check with IC guys? Or you've done?

I don't have contact to the IC guys. Could you do this? I'd be interested in the results.

Sure, but it may be slow, as you know, many people are in summer break.

Thanks. It can take longer, the resulting frequencies are all too low, so we are on the safe side.

Sascha,

IC guys confirmed that the spec is right:

This an adaptive feature of our I2C module may apply to all IMX chips. No mistake in the table of RMs.

The divider is designed to guarantee SCL high level and low level last time. Divider will hold when SCL transition from 1 to 0 or 0 to 1, if the transition time is longer than 1 internal pre-divided clock cycle. The pre-divided clock is divided from I2C module clock, used for generating SCL. So you will see SCL clock cycle is some way longer than calculated value using IFDR.

Transition time will different from rising or falling edge, different pull-up resistors, and different SCL loading.

This feature make sure transition time won?t eat both level time of SCL.

Thanks
Richard

Quoted 9 lines

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
author maintainer
#8 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Hi Richard,

Quoted 13 lines · Richard Zhao

IC guys confirmed that the spec is right:

This an adaptive feature of our I2C module may apply to all IMX chips. No mistake in the table of RMs.

The divider is designed to guarantee SCL high level and low level last time. Divider will hold when SCL transition from 1 to 0 or 0 to 1, if the transition time is longer than 1 internal pre-divided clock cycle. The pre-divided clock is divided from I2C module clock, used for generating SCL. So you will see SCL clock cycle is some way longer than calculated value using IFDR.

Quoted 4 lines

Transition time will different from rising or falling edge, different pull-up resistors, and different SCL loading.

This feature make sure transition time won?t eat both level time of SCL.

Thanks for clarification. Does this mean that this feature is used to synchronize between the bus clock and and bitclock?

I'll send a documentation patch for this next week to make this clear.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#9 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 18 lines · Sascha Hauer

Hi Richard,

Quoted 15 lines · Richard Zhao

IC guys confirmed that the spec is right:

This an adaptive feature of our I2C module may apply to all IMX chips. No mistake in the table of RMs.

The divider is designed to guarantee SCL high level and low level last time. Divider will hold when SCL transition from 1 to 0 or 0 to 1, if the transition time is longer than 1 internal pre-divided clock cycle. The pre-divided clock is divided from I2C module clock, used for generating SCL. So you will see SCL clock cycle is some way longer than calculated value using IFDR.

Transition time will different from rising or falling edge, different pull-up resistors, and different SCL loading.

Quoted 8 lines
Quoted 1 line

This feature make sure transition time won?t eat both level time of SCL.

Thanks for clarification. Does this mean that this feature is used to synchronize between the bus clock and and bitclock?

I'll send a documentation patch for this next week to make this clear.

Sascha

How does this explain why column 2 matched your measurements, but 1, 3, and 4 didn't.
And you tested on 2 different boards.
Something doesn't smell right.

Just my 2cents
Troy

author maintainer
#10 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 23 lines · Troy Kisky
Quoted 22 lines · Sascha Hauer

Hi Richard,

Quoted 12 lines · Richard Zhao

IC guys confirmed that the spec is right:

This an adaptive feature of our I2C module may apply to all IMX chips. No mistake in the table of RMs.

The divider is designed to guarantee SCL high level and low level last time. Divider will hold when SCL transition from 1 to 0 or 0 to 1, if the transition time is longer than 1 internal pre-divided clock cycle. The pre-divided clock is divided from I2C module clock, used for generating SCL. So you will see SCL clock cycle is some way longer than calculated value using IFDR.

Quoted 4 lines

Transition time will different from rising or falling edge, different pull-up resistors, and different SCL loading.

This feature make sure transition time won?t eat both level time of SCL.

Thanks for clarification. Does this mean that this feature is used to synchronize between the bus clock and and bitclock?

Quoted 8 lines
Quoted 4 lines

I'll send a documentation patch for this next week to make this clear.

Sascha

How does this explain why column 2 matched your measurements, but 1, 3, and 4 didn't.
And you tested on 2 different boards.
Something doesn't smell right.

This reminds me that one divider value on i.MX53 crashed the whole I2C module (it was unusable until reset). The same value worked on i.MX1. Some divider values produced a terrible jitter on the clock output. So it really seems that there is something more going on than just a simple divider.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#11 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

In reply to Sascha Hauer
Quoted 16 lines · Sascha Hauer

Hi Richard,

Quoted 13 lines · Richard Zhao

IC guys confirmed that the spec is right:

This an adaptive feature of our I2C module may apply to all IMX chips. No mistake in the table of RMs.

The divider is designed to guarantee SCL high level and low level last time. Divider will hold when SCL transition from 1 to 0 or 0 to 1, if the transition time is longer than 1 internal pre-divided clock cycle. The pre-divided clock is divided from I2C module clock, used for generating SCL. So you will see SCL clock cycle is some way longer than calculated value using IFDR.

Quoted 7 lines
Quoted 4 lines

Transition time will different from rising or falling edge, different pull-up resistors, and different SCL loading.

This feature make sure transition time won?t eat both level time of SCL.

Thanks for clarification. Does this mean that this feature is used to synchronize between the bus clock and and bitclock?

Per my understanding,
Not exactly. Divided clock is only used for count time of SCL level hold. This means, even if the i2c bus loading is high (long level setup time), the i2c may still work.

Thanks
Richard

Quoted 11 lines

I'll send a documentation patch for this next week to make this clear.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#12 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

In reply to Sascha Hauer
Quoted 2 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong.

How were the measurements made?

Quoted 4 lines

the values from first, third and fourth
column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Also does it vary board to board or is fixed by the ip? What I mean is that the external cap etc.

Quoted 3 lines
Signed-off-by Sascha Hauer <[email protected]>

---

author maintainer
#13 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 4 lines · Shubhrajyoti Datta
Quoted 2 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong.

How were the measurements made?

With an oscilloscope measuring the period length. This is probably not very exact, but the current values are way off. We had 350KHz instead of 380KHz (best possible divider) on an i.MX53. Funny enough some divider values really match the ones in the datasheet.

BTW I'm pretty sure the input frequency to the core is calculated correctly as it's the same clock that also drives the timer.

Quoted 8 lines
Quoted 5 lines

the values from first, third and fourth
column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Also does it vary board to board or is fixed by the ip? What I mean is that the external cap etc.

The clock is derived from an internal SoC clock, I don't think this can be influenced that much by external components. I did not test different boards, but two board with different SoCs.

Let's see what the IC guys tell us.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#14 lore raw

PATCH 1/1 i2c i.MX: Fix divider table

Quoted 6 lines · Sascha Hauer
Quoted 4 lines · Shubhrajyoti Datta
Quoted 2 lines · Sascha Hauer

Measurements on i.MX1 and i.MX53 have shown that the divider values in the datasheets are wrong.

How were the measurements made?

Quoted 7 lines

With an oscilloscope measuring the period length. This is probably not very exact, but the current values are way off. We had 350KHz instead of 380KHz (best possible divider) on an i.MX53. Funny enough some divider values really match the ones in the datasheet.

BTW I'm pretty sure the input frequency to the core is calculated correctly as it's the same clock that also drives the timer.

OK thanks for the explanation.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

the values from first, third and fourth
column were all measured to be 8 higher than in the datasheet. It should be safe to assume that the SoCs between i.MX1 and i.MX53 behave the same as the i2c unit is unchanged since the i.MX1.

Quoted 6 lines
Quoted 2 lines

Also does it vary board to board or is fixed by the ip? What I mean is that the external cap etc.

The clock is derived from an internal SoC clock, I don't think this can be influenced that much by external components. I did not test different boards, but two board with different SoCs.

OK thanks.

Quoted 2 lines

Let's see what the IC guys tell us.

Sure.

Quoted 8 lines

Sascha

--

Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |