* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 13:10 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-05 13:10 UTC (permalink / raw) To: linux-i2c-u79uwXL29TY76Z2rM5mHXA Cc: Wolfram Sang, Ben Dooks, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, 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. Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> --- drivers/i2c/busses/i2c-imx.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 8d6b504..aabbe31 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -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 { -- 1.7.10 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 13:10 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-05 13:10 UTC (permalink / raw) To: linux-arm-kernel 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 <s.hauer@pengutronix.de> --- drivers/i2c/busses/i2c-imx.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 8d6b504..aabbe31 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -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 { -- 1.7.10 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 13:10 ` Sascha Hauer @ 2012-07-05 14:23 ` Baruch Siach -1 siblings, 0 replies; 29+ messages in thread From: Baruch Siach @ 2012-07-05 14:23 UTC (permalink / raw) To: Sascha Hauer; +Cc: linux-arm-kernel, Ben Dooks, linux-i2c, kernel, Wolfram Sang Hi Sascha, On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > + * 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/ > + * between behave the same. > */ baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 14:23 ` Baruch Siach 0 siblings, 0 replies; 29+ messages in thread From: Baruch Siach @ 2012-07-05 14:23 UTC (permalink / raw) To: linux-arm-kernel Hi Sascha, On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > + * 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/ > + * between behave the same. > */ baruch -- 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 - ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1341493826-13861-1-git-send-email-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 13:10 ` Sascha Hauer @ 2012-07-05 14:52 ` Richard Zhao -1 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-05 14:52 UTC (permalink / raw) To: Sascha Hauer Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang, Ben Dooks, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > 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 > > Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> > --- > drivers/i2c/busses/i2c-imx.c | 31 ++++++++++++++++++------------- > 1 file changed, 18 insertions(+), 13 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c > index 8d6b504..aabbe31 100644 > --- a/drivers/i2c/busses/i2c-imx.c > +++ b/drivers/i2c/busses/i2c-imx.c > @@ -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 { > -- > 1.7.10 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 14:52 ` Richard Zhao 0 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-05 14:52 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > 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 > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > drivers/i2c/busses/i2c-imx.c | 31 ++++++++++++++++++------------- > 1 file changed, 18 insertions(+), 13 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c > index 8d6b504..aabbe31 100644 > --- a/drivers/i2c/busses/i2c-imx.c > +++ b/drivers/i2c/busses/i2c-imx.c > @@ -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 { > -- > 1.7.10 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 14:52 ` Richard Zhao @ 2012-07-05 16:01 ` Sascha Hauer -1 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-05 16:01 UTC (permalink / raw) To: Richard Zhao Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang, Ben Dooks, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 16:01 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-05 16:01 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20120705160153.GT30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 16:01 ` Sascha Hauer @ 2012-07-06 0:52 ` Richard Zhao -1 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-06 0:52 UTC (permalink / raw) To: Sascha Hauer Cc: Richard Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ben Dooks, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > 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 > > 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 | > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-06 0:52 ` Richard Zhao 0 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-06 0:52 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > 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 > > 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 | > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20120706005249.GA26888-iWYTGMXpHj9ITqJhDdzsOjpauB2SiJktrE5yTffgRl4@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-06 0:52 ` Richard Zhao @ 2012-07-06 6:28 ` Sascha Hauer -1 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-06 6:28 UTC (permalink / raw) To: Richard Zhao Cc: Richard Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ben Dooks, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang On Fri, Jul 06, 2012 at 08:52:50AM +0800, Richard Zhao wrote: > On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > > 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. It can take longer, the resulting frequencies are all too low, so we are on the safe side. 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-06 6:28 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-06 6:28 UTC (permalink / raw) To: linux-arm-kernel On Fri, Jul 06, 2012 at 08:52:50AM +0800, Richard Zhao wrote: > On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > > 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. It can take longer, the resulting frequencies are all too low, so we are on the safe side. 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table 2012-07-06 6:28 ` Sascha Hauer (?) @ 2012-07-06 17:41 ` Troy Kisky -1 siblings, 0 replies; 29+ messages in thread From: Troy Kisky @ 2012-07-06 17:41 UTC (permalink / raw) To: linux-arm-kernel On 7/5/2012 11:28 PM, Sascha Hauer wrote: > On Fri, Jul 06, 2012 at 08:52:50AM +0800, Richard Zhao wrote: >> On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: >>> On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: >>>> On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: >>>>> 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. 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20120706062852.GZ30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-06 6:28 ` Sascha Hauer @ 2012-07-11 6:01 ` Richard Zhao -1 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-11 6:01 UTC (permalink / raw) To: Sascha Hauer Cc: Richard Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ben Dooks, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang, b35325-KZfg59tc24xl57MIdRCFDg, b38611-KZfg59tc24xl57MIdRCFDg On Fri, Jul 06, 2012 at 08:28:52AM +0200, Sascha Hauer wrote: > On Fri, Jul 06, 2012 at 08:52:50AM +0800, Richard Zhao wrote: > > On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > > > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > > > 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. 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 > > 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 | > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-11 6:01 ` Richard Zhao 0 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-11 6:01 UTC (permalink / raw) To: linux-arm-kernel On Fri, Jul 06, 2012 at 08:28:52AM +0200, Sascha Hauer wrote: > On Fri, Jul 06, 2012 at 08:52:50AM +0800, Richard Zhao wrote: > > On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > > > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > > > 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. 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 > > 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 | > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20120711060121.GB30055-iWYTGMXpHj9ITqJhDdzsOjpauB2SiJktrE5yTffgRl4@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-11 6:01 ` Richard Zhao @ 2012-07-11 18:38 ` Sascha Hauer -1 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-11 18:38 UTC (permalink / raw) To: Richard Zhao Cc: Richard Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ben Dooks, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang, b35325-KZfg59tc24xl57MIdRCFDg, b38611-KZfg59tc24xl57MIdRCFDg Hi Richard, On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: > > 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 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-11 18:38 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-11 18:38 UTC (permalink / raw) To: linux-arm-kernel Hi Richard, On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: > > 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 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20120711183838.GM30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-11 18:38 ` Sascha Hauer @ 2012-07-11 19:11 ` Troy Kisky -1 siblings, 0 replies; 29+ messages in thread From: Troy Kisky @ 2012-07-11 19:11 UTC (permalink / raw) To: Sascha Hauer Cc: Richard Zhao, b38611-KZfg59tc24xl57MIdRCFDg, Ben Dooks, b35325-KZfg59tc24xl57MIdRCFDg, Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Richard Zhao On 7/11/2012 11:38 AM, Sascha Hauer wrote: > Hi Richard, > > On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: >> 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 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-11 19:11 ` Troy Kisky 0 siblings, 0 replies; 29+ messages in thread From: Troy Kisky @ 2012-07-11 19:11 UTC (permalink / raw) To: linux-arm-kernel On 7/11/2012 11:38 AM, Sascha Hauer wrote: > Hi Richard, > > On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: >> 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 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4FFDCFDB.7020402-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-11 19:11 ` Troy Kisky @ 2012-07-11 19:44 ` Sascha Hauer -1 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-11 19:44 UTC (permalink / raw) To: Troy Kisky Cc: Richard Zhao, b38611-KZfg59tc24xl57MIdRCFDg, Ben Dooks, b35325-KZfg59tc24xl57MIdRCFDg, Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Richard Zhao On Wed, Jul 11, 2012 at 12:11:23PM -0700, Troy Kisky wrote: > On 7/11/2012 11:38 AM, Sascha Hauer wrote: > >Hi Richard, > > > >On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: > >>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 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. 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-11 19:44 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-11 19:44 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jul 11, 2012 at 12:11:23PM -0700, Troy Kisky wrote: > On 7/11/2012 11:38 AM, Sascha Hauer wrote: > >Hi Richard, > > > >On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: > >>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 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. 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-11 18:38 ` Sascha Hauer @ 2012-07-12 0:45 ` Richard Zhao -1 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-12 0:45 UTC (permalink / raw) To: Sascha Hauer Cc: Richard Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ben Dooks, linux-i2c-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Wolfram Sang, b35325-KZfg59tc24xl57MIdRCFDg, b38611-KZfg59tc24xl57MIdRCFDg On Wed, Jul 11, 2012 at 08:38:38PM +0200, Sascha Hauer wrote: > Hi Richard, > > On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: > > > > 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 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 > > I'll send a documentation patch for this next week to make this clear. > > 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 | > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-12 0:45 ` Richard Zhao 0 siblings, 0 replies; 29+ messages in thread From: Richard Zhao @ 2012-07-12 0:45 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jul 11, 2012 at 08:38:38PM +0200, Sascha Hauer wrote: > Hi Richard, > > On Wed, Jul 11, 2012 at 02:01:21PM +0800, Richard Zhao wrote: > > > > 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 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 > > I'll send a documentation patch for this next week to make this clear. > > 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 | > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 13:10 ` Sascha Hauer @ 2012-07-05 18:06 ` Shubhrajyoti Datta -1 siblings, 0 replies; 29+ messages in thread From: Shubhrajyoti Datta @ 2012-07-05 18:06 UTC (permalink / raw) To: Sascha Hauer Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Ben Dooks, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote: > Measurements on i.MX1 and i.MX53 have shown that the divider values > in the datasheets are wrong. How were the measurements made? > 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. > > Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> > --- ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 18:06 ` Shubhrajyoti Datta 0 siblings, 0 replies; 29+ messages in thread From: Shubhrajyoti Datta @ 2012-07-05 18:06 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > Measurements on i.MX1 and i.MX53 have shown that the divider values > in the datasheets are wrong. How were the measurements made? > 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. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <CAM=Q2csv3rEs-xseGd6NHxR3wRSZp82ZqNB1mn-_C4=5=nOc6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 18:06 ` Shubhrajyoti Datta @ 2012-07-05 18:47 ` Sascha Hauer -1 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-05 18:47 UTC (permalink / raw) To: Shubhrajyoti Datta Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Ben Dooks, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Jul 05, 2012 at 11:36:27PM +0530, Shubhrajyoti Datta wrote: > On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote: > > 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. > > > 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-05 18:47 ` Sascha Hauer 0 siblings, 0 replies; 29+ messages in thread From: Sascha Hauer @ 2012-07-05 18:47 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 05, 2012 at 11:36:27PM +0530, Shubhrajyoti Datta wrote: > On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > 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. > > > 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 -- 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20120705184736.GW30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]
* Re: [PATCH] i2c i.MX: Fix divider table 2012-07-05 18:47 ` Sascha Hauer @ 2012-07-08 9:14 ` Shubhrajyoti Datta -1 siblings, 0 replies; 29+ messages in thread From: Shubhrajyoti Datta @ 2012-07-08 9:14 UTC (permalink / raw) To: Sascha Hauer Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Ben Dooks, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, Jul 6, 2012 at 12:17 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote: > On Thu, Jul 05, 2012 at 11:36:27PM +0530, Shubhrajyoti Datta wrote: >> On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote: >> > 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. OK thanks for the explanation. > >> >> > 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. OK thanks. > > Let's see what the IC guys tell us. Sure. > > 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] i2c i.MX: Fix divider table @ 2012-07-08 9:14 ` Shubhrajyoti Datta 0 siblings, 0 replies; 29+ messages in thread From: Shubhrajyoti Datta @ 2012-07-08 9:14 UTC (permalink / raw) To: linux-arm-kernel On Fri, Jul 6, 2012 at 12:17 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Thu, Jul 05, 2012 at 11:36:27PM +0530, Shubhrajyoti Datta wrote: >> On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: >> > 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. OK thanks for the explanation. > >> >> > 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. OK thanks. > > Let's see what the IC guys tell us. Sure. > > 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 | ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2012-07-12 0:45 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-05 13:10 [PATCH] i2c i.MX: Fix divider table Sascha Hauer
2012-07-05 13:10 ` Sascha Hauer
2012-07-05 14:23 ` Baruch Siach
2012-07-05 14:23 ` Baruch Siach
[not found] ` <1341493826-13861-1-git-send-email-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-05 14:52 ` Richard Zhao
2012-07-05 14:52 ` Richard Zhao
2012-07-05 16:01 ` Sascha Hauer
2012-07-05 16:01 ` Sascha Hauer
[not found] ` <20120705160153.GT30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-06 0:52 ` Richard Zhao
2012-07-06 0:52 ` Richard Zhao
[not found] ` <20120706005249.GA26888-iWYTGMXpHj9ITqJhDdzsOjpauB2SiJktrE5yTffgRl4@public.gmane.org>
2012-07-06 6:28 ` Sascha Hauer
2012-07-06 6:28 ` Sascha Hauer
2012-07-06 17:41 ` Troy Kisky
[not found] ` <20120706062852.GZ30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-11 6:01 ` Richard Zhao
2012-07-11 6:01 ` Richard Zhao
[not found] ` <20120711060121.GB30055-iWYTGMXpHj9ITqJhDdzsOjpauB2SiJktrE5yTffgRl4@public.gmane.org>
2012-07-11 18:38 ` Sascha Hauer
2012-07-11 18:38 ` Sascha Hauer
[not found] ` <20120711183838.GM30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-11 19:11 ` Troy Kisky
2012-07-11 19:11 ` Troy Kisky
[not found] ` <4FFDCFDB.7020402-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2012-07-11 19:44 ` Sascha Hauer
2012-07-11 19:44 ` Sascha Hauer
2012-07-12 0:45 ` Richard Zhao
2012-07-12 0:45 ` Richard Zhao
2012-07-05 18:06 ` Shubhrajyoti Datta
2012-07-05 18:06 ` Shubhrajyoti Datta
[not found] ` <CAM=Q2csv3rEs-xseGd6NHxR3wRSZp82ZqNB1mn-_C4=5=nOc6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-05 18:47 ` Sascha Hauer
2012-07-05 18:47 ` Sascha Hauer
[not found] ` <20120705184736.GW30009-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-08 9:14 ` Shubhrajyoti Datta
2012-07-08 9:14 ` Shubhrajyoti Datta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.