[U-Boot] [PATCH] drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW

Since we agreed on legacy implementation of "eeprom_{read|write}" (http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with anumber of "built-in" ICs with different chip addresses.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com
Cc: Tom Rini trini@ti.com cc: Armando Visconti armando.visconti@st.com Cc: Stefan Roese sr@denx.de Cc: Albert ARIBAUD albert.u.boot@aribaud.net Cc: Heiko Schocher hs@denx.de Cc: Vipin KUMAR vipin.kumar@st.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Mischa Jonker mjonker@synopsys.com Cc: Kuo-Jung Su dantesu@faraday-tech.com --- drivers/i2c/designware_i2c.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c index cb2ac04..9ed9295 100644 --- a/drivers/i2c/designware_i2c.c +++ b/drivers/i2c/designware_i2c.c @@ -266,6 +266,25 @@ int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len) { unsigned long start_time_rx;
+#ifdef CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW + /* + * EEPROM chips that implement "address overflow" are ones + * like Catalyst 24WC04/08/16 which has 9/10/11 bits of + * address and the extra bits end up in the "chip address" + * bit slots. This makes a 24WC08 (1Kbyte) chip look like + * four 256 byte chips. + * + * Note that we consider the length of the address field to + * still be one byte because the extra address bits are + * hidden in the chip address. + */ + chip |= ((addr >> (alen * 8)) & CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW); + addr &= ~(CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW << (alen * 8)); + + debug("%s: fix addr_overflow: chip %02x addr %02x\n", __func__, chip, + addr); +#endif + if (check_params(addr, alen, buffer, len)) return 1;
@@ -307,6 +326,25 @@ int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len) int nb = len; unsigned long start_time_tx;
+#ifdef CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW + /* + * EEPROM chips that implement "address overflow" are ones + * like Catalyst 24WC04/08/16 which has 9/10/11 bits of + * address and the extra bits end up in the "chip address" + * bit slots. This makes a 24WC08 (1Kbyte) chip look like + * four 256 byte chips. + * + * Note that we consider the length of the address field to + * still be one byte because the extra address bits are + * hidden in the chip address. + */ + chip |= ((addr >> (alen * 8)) & CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW); + addr &= ~(CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW << (alen * 8)); + + debug("%s: fix addr_overflow: chip %02x addr %02x\n", __func__, chip, + addr); +#endif + if (check_params(addr, alen, buffer, len)) return 1;

On Mon, 2013-12-16 at 15:30 +0400, Alexey Brodkin wrote:
Since we agreed on legacy implementation of "eeprom_{read|write}" (http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with anumber of "built-in" ICs with different chip addresses.
Hi Heiko,
any chance to get this one applied? Note this is not an enhancement - this is a required fix due to roll-back (http://patchwork.ozlabs.org/patch/295825/) of my previous fix in http://patchwork.ozlabs.org/patch/289346/
Regards, Alexey

Hello Alexey,
Am 15.01.2014 16:37, schrieb Alexey Brodkin:
On Mon, 2013-12-16 at 15:30 +0400, Alexey Brodkin wrote:
Since we agreed on legacy implementation of "eeprom_{read|write}" (http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with anumber of "built-in" ICs with different chip addresses.
Hi Heiko,
any chance to get this one applied?
I picked it up, see:
http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=summary http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=32d041e218c6a22e92d91...
Note this is not an enhancement - this is a required fix due to roll-back (http://patchwork.ozlabs.org/patch/295825/) of my previous fix in http://patchwork.ozlabs.org/patch/289346/
Waiting for a testreport for another patch ... If I get no response, I send a pull request for this patch tomorrow ...
bye, Heiko

On Fri, 2014-01-17 at 07:42 +0100, Heiko Schocher wrote:
Hello Alexey, I picked it up, see:
http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=summary http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=32d041e218c6a22e92d91...
Note this is not an enhancement - this is a required fix due to roll-back (http://patchwork.ozlabs.org/patch/295825/) of my previous fix in http://patchwork.ozlabs.org/patch/289346/
Waiting for a testreport for another patch ... If I get no response, I send a pull request for this patch tomorrow ...
Oops, sorry I didn't look at your tree before reminding. Thanks so much for your time.
-Alexey
participants (3)
-
Alexey Brodkin
-
Alexey Brodkin
-
Heiko Schocher