[U-Boot-Users] [PATCH] I2C register access functions for omap1510_i2c driver
drivers/i2c/omap1510_i2c.c does not implement i2c_reg_read and i2c_reg_write which leads to unresolved symbols when using ds1307 driver. While there, enable CONFIG_CMD_DATE for Voiceblue board to have nice test case :-)
Signed-off-by: Ladislav Michl ladis@linux-mips.org
diff --git a/drivers/i2c/omap1510_i2c.c b/drivers/i2c/omap1510_i2c.c index 04400fb..f0fc15e 100644 --- a/drivers/i2c/omap1510_i2c.c +++ b/drivers/i2c/omap1510_i2c.c @@ -240,6 +240,19 @@ int i2c_write (uchar chip, uint addr, int alen, uchar * buffer, int len) return 0; }
+uchar i2c_reg_read (uchar chip, uchar reg) +{ + uchar val; + + i2c_read_byte(chip, reg, &val); + return val; +} + +void i2c_reg_write(uchar chip, uchar reg, uchar val) +{ + i2c_write_byte(chip, reg, val); +} + static void wait_for_bb (void) { int timeout = 10; diff --git a/include/configs/voiceblue.h b/include/configs/voiceblue.h index 8c827af..63e3530 100644 --- a/include/configs/voiceblue.h +++ b/include/configs/voiceblue.h @@ -126,6 +126,7 @@
#define CONFIG_CMD_BDI #define CONFIG_CMD_BOOTD +#define CONFIG_CMD_DATE #define CONFIG_CMD_DHCP #define CONFIG_CMD_ENV #define CONFIG_CMD_FLASH diff --git a/board/voiceblue/voiceblue.c b/board/voiceblue/voiceblue.c index c8dde36..fbbbe9d 100644 --- a/board/voiceblue/voiceblue.c +++ b/board/voiceblue/voiceblue.c @@ -56,6 +56,7 @@ int dram_init(void) int misc_init_r(void) { *((volatile unsigned short *) VOICEBLUE_LED_REG) = 0x55; + i2c_reg_write(CFG_I2C_RTC_ADDR, 0x10, 0xaa); /* Trickle charge */
return 0; }
On Feb 8, 2008 6:25 PM, Ladislav Michl ladis@linux-mips.org wrote:
drivers/i2c/omap1510_i2c.c does not implement i2c_reg_read and i2c_reg_write which leads to unresolved symbols when using ds1307 driver. While there, enable CONFIG_CMD_DATE for Voiceblue board to have nice test case :-)
Signed-off-by: Ladislav Michl ladis@linux-mips.org
diff --git a/drivers/i2c/omap1510_i2c.c b/drivers/i2c/omap1510_i2c.c index 04400fb..f0fc15e 100644 --- a/drivers/i2c/omap1510_i2c.c +++ b/drivers/i2c/omap1510_i2c.c @@ -240,6 +240,19 @@ int i2c_write (uchar chip, uint addr, int alen, uchar * buffer, int len) return 0; }
+uchar i2c_reg_read (uchar chip, uchar reg) +{
uchar val;i2c_read_byte(chip, reg, &val);return val;+}
+void i2c_reg_write(uchar chip, uchar reg, uchar val) +{
i2c_write_byte(chip, reg, val);+}
While your fix is technically correct, I looked into this last week and found that this exact code is duplicated in EVERY I2C controller, except one (MPC8xx), where there are calls to i2c_init() in each of the functions. I posted a request for information about why the i2c_init() call is necessary in MPC8xx and nobody has responded yet. Maybe somebody has an MPC8xx-based board and could experiment a bit to make it the same???
I'd prefer to see these functions as static inlines in i2c.h in order to cut down on duplication.
Just my $0.02
regards, Ben
On Fri, Feb 08, 2008 at 07:17:30PM -0500, Ben Warren wrote:
While your fix is technically correct, I looked into this last week and found that this exact code is duplicated in EVERY I2C controller, except one (MPC8xx), where there are calls to i2c_init() in each of the functions.
Yup, that's why I give up fixing all that stuff, not mentioning my patch doesn't containg the same code which reads:
void i2c_reg_write(uchar chip, uchar reg, uchar val) { i2c_write(chip, reg, 1, &val, 1); }
as omap has separate function to read and write single byte and I used it.
I posted a request for information about why the i2c_init() call is necessary in MPC8xx and nobody has responded yet. Maybe somebody has an MPC8xx-based board and could experiment a bit to make it the same???
I'd prefer to see these functions as static inlines in i2c.h in order to cut down on duplication.
Agree here, except it would be nice to use something like this:
void __i2c_reg_write(uchar chip, uchar reg, uchar val) { i2c_write(chip, reg, 1, &val, 1); } void void i2c_reg_write(uchar chip, uchar reg, uchar val) __attribute__((weak, alias("__i2c_reg_write")));
So anyone may still use his own i2c_reg_write implementation and you do not need to wait for answer to your question about MPC8xx.
Best regards, ladis
participants (2)
-
Ben Warren -
Ladislav Michl