| Message ID | 1371754675-12242-3-git-send-email-alexandre.belloni@free-electrons.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jun 20, 2013 at 3:57 PM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > From: Maxime Ripard <maxime.ripard@free-electrons.com> > > The ADCs connected to this bus have been experiencing some timeout > issues when using the iMX28 i2c controller. Switching back to bitbanging > solves this. Could you please investigate this timeout issue? The I2C timeouts I was having on mx28 when trying to access sgtl5000 codec, was due to the lack of codec clock. After I provided the codec clock I am able to use I2C without issues and just sent a patch for it.
Hello Alexandre, > The ADCs connected to this bus have been experiencing some timeout > issues when using the iMX28 i2c controller. Switching back to bitbanging > solves this. the chip errata for i.MX23(!) contains an issue (no 2727) with the I2C controller that is also applicable for the i.MX28: " 2727 I2C 9th Clock Pulse (ACK) not generated when RETAIN_CLOCK set. Description: When RETAIN_CLOCK is set, the ninth clock pulse (ACK) is not generated. However, the SDA line is read at the proper timing interval. If RETAIN_CLOCK is cleared, the ninth clock pulse is generated. Also, the HW_I2C_VERSION register incorrectly states the version is 1.2. It should be 1.3. Workaround: HW_I2C_CTRL1[ACK_MODE] has default value of 0. It should be set to 1 to enable the fix for this issue. " Regards Christoph Baumann
Hi Christoph, On Tue, Jul 2, 2013 at 10:29 AM, Christoph G. Baumann <cb@sgoc.de> wrote: > Hello Alexandre, > >> The ADCs connected to this bus have been experiencing some timeout >> issues when using the iMX28 i2c controller. Switching back to bitbanging >> solves this. > > the chip errata for i.MX23(!) contains an issue (no 2727) with the I2C > controller that is also applicable for the i.MX28: > > " > 2727 I2C 9th Clock Pulse (ACK) not generated when RETAIN_CLOCK set. > > Description: > When RETAIN_CLOCK is set, the ninth clock pulse (ACK) is not generated. However, > the SDA > line is read at the proper timing interval. If RETAIN_CLOCK is cleared, the > ninth clock pulse is > generated. > Also, the HW_I2C_VERSION register incorrectly states the version is 1.2. It > should be 1.3. > > Workaround: > HW_I2C_CTRL1[ACK_MODE] has default value of 0. It should be set to 1 to enable > the fix for > this issue. Differently than mx23, the mx28 reference manual states that ACK_MODE bit has a default value of 1. Thanks for pointing this out, as we need to take this into consideration for supporting mx23 in the mxs i2c driver. Regards, Fabio Estevam
Hi Fabio, > > Differently than mx23, the mx28 reference manual states that ACK_MODE > bit has a default value of 1. > > Thanks for pointing this out, as we need to take this into > consideration for supporting mx23 in the mxs i2c driver. > nevertheless the mx28 I2C controller seems to suffer from this error too, as SMbus doesn't work with it. Regards Christoph
On Tue, Jul 2, 2013 at 11:09 AM, Christoph G. Baumann <cb@sgoc.de> wrote: > Hi Fabio, > >> >> Differently than mx23, the mx28 reference manual states that ACK_MODE >> bit has a default value of 1. >> >> Thanks for pointing this out, as we need to take this into >> consideration for supporting mx23 in the mxs i2c driver. >> > > nevertheless the mx28 I2C controller seems to suffer from this error too, as > SMbus doesn't work with it. Understood. Just sent a patch for this. Please help testing it. Thanks, Fabio Estevam
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts index 05ae549..d3758c2 100644 --- a/arch/arm/boot/dts/imx28-cfa10049.dts +++ b/arch/arm/boot/dts/imx28-cfa10049.dts @@ -139,6 +139,17 @@ fsl,pull-up = <0>; /* 0 will enable the keeper */ }; + i2c1_pins_cfa10049: i2c1@0 { + reg = <0>; + fsl,pinmux-ids = < + 0x3103 /* MX28_PAD_PWM0__GPIO */ + 0x3113 /* MX28_PAD_PWM1__I2C1_SDA */ + >; + fsl,drive-strength = <1>; + fsl,voltage = <1>; + fsl,pull-up = <1>; + }; + fiq_pins_cfa10049: fiq@0 { reg = <0>; fsl,pinmux-ids = < @@ -199,49 +210,6 @@ status = "okay"; }; - i2c1: i2c@8005a000 { - pinctrl-names = "default"; - pinctrl-0 = <&i2c1_pins_a>; - status = "okay"; - }; - - i2cmux { - compatible = "i2c-mux-gpio"; - #address-cells = <1>; - #size-cells = <0>; - mux-gpios = <&gpio1 22 0 &gpio1 23 0>; - i2c-parent = <&i2c1>; - - i2c@0 { - reg = <0>; - }; - - i2c@1 { - reg = <1>; - }; - - i2c@2 { - reg = <2>; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - compatible = "nxp,pca9555"; - interrupt-parent = <&gpio2>; - interrupts = <19 0x2>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0x20>; - }; - }; - }; - usbphy1: usbphy@8007e000 { status = "okay"; }; @@ -366,6 +334,60 @@ rotary-encoder,relative-axis; }; + i2c1gpio: i2c@0 { + compatible = "i2c-gpio"; + pinctrl-0 = <&i2c1_pins_cfa10049>; + pinctrl-names = "default"; + gpios = < + &gpio3 17 0 /* sda */ + &gpio3 16 0 /* scl */ + >; + i2c-gpio,delay-us = <2>; /* ~100 kHz */ + }; + + i2cmux { + compatible = "i2c-mux-gpio"; + #address-cells = <1>; + #size-cells = <0>; + mux-gpios = <&gpio1 22 0 &gpio1 23 0>; + i2c-parent = <&i2c1gpio>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + compatible = "nxp,pca9555"; + interrupt-parent = <&gpio2>; + interrupts = <19 0x2>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x20>; + }; + }; + }; + backlight { compatible = "pwm-backlight"; pwms = <&pwm 3 5000000>;