[U-Boot] Zoom hw reset
For arm/next
This patch enables hw resetting of zoom1 and zoom2. This is done through the twl4030 part. Since this part is not currently supported, start an twl4030_i2c device. In testing it was found that I2C was broken on Zoom1 and Zoom2. I2C was fixed by improving the initialization of its sampling clock.
The reset changes were run tested on zoom1 and zoom2.
The I2C changes were run tested on zoom1, zoom2, beagle and overo. The 400kHz case was run tested on a variant of the zoom1 configuration.
This problem is seen on Zoom1 and Zoom2 in the startup and when i2c probe is used
Before :
In: serial Out: serial Err: serial timed out in wait_for_bb: I2C_STAT=1000 timed out in wait_for_bb: I2C_STAT=1000 timed out in wait_for_bb: I2C_STAT=1000 timed out in wait_for_pin: I2C_STAT=1000 I2C read: I/O error timed out in wait_for_bb: I2C_STAT=1000 timed out in wait_for_bb: I2C_STAT=1000 Die ID #327c00020000000004013ddd05026013 Hit any key to stop autoboot: 0 OMAP3 Zoom1# i2c probe Valid chip addresses:timed out in wait_for_bb: I2C_STAT=1000 02 03 04 05 06 07 08 09 0A 0B 0C 0D <snip>
After :
In: serial Out: serial Err: serial Die ID #327c00020000000004013ddd05026013 Hit any key to stop autoboot: 0 OMAP3 Zoom1# i2c probe Valid chip addresses: 48 49 4A 4B
The addresses are for the twl4030.
The prescalar that converts the function clock to the sampling clock is hardcoded to 0. The reference manual recommends 7 if the function clock is 96MHz.
Instead of just changing the hardcoded values, the prescalar is calculated from the value I2C_IP_CLK.
The i2c #defines are in kHz. The speed passed into the i2c init routine is in Hz. To be consistent, change the defines to be in Hz.
This was runtime verified on Zoom1, Zoom2, Beagle and Overo. The 400kHz case was verifed on a test Zoom2 configuration.
Signed-off-by: Tom Rix Tom.Rix@windriver.com --- drivers/i2c/omap24xx_i2c.c | 54 +++++++++++++++++++++++++++++++++----- include/asm-arm/arch-omap3/i2c.h | 16 +++++----- 2 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c index 6784603..81947e6 100644 --- a/drivers/i2c/omap24xx_i2c.c +++ b/drivers/i2c/omap24xx_i2c.c @@ -31,7 +31,49 @@ static void flush_fifo(void);
void i2c_init (int speed, int slaveadd) { - u16 scl; + int psc, iclk, scll, sclh; + + /* Only handle standard and fast speeds */ + if ((speed != OMAP_I2C_STANDARD) && + (speed != OMAP_I2C_FAST_MODE)) { + printf("Error : I2C unsupported speed %d\n", speed); + return; + } + + /* + * Calculate the prescalar to go from from the function clock + * to the internal sampling clock, 12MHz. + */ + psc = I2C_PSC_MAX; + while (psc >= I2C_PSC_MIN) { + iclk = I2C_IP_CLK / (psc + 1); + if (12000000 <= iclk) + break; + psc--; + } + if (psc < I2C_PSC_MIN) { + printf("Error : I2C unsupported prescalar %d\n", psc); + return; + } + + /* + * How the low and high time periods are calculated + * See the OMAP3xxx Reference Manual for more details + * + * tlow + thigh = 1 / speed + * thigh = tlow, nice square wave.. + * + * tlow = 1 / (2 * speed) = (scll + 7) / iclk; + * scll + 7 = iclk / 2 * speed + * sclh + 5 = iclk / 2 * speed + */ + scll = sclh = iclk / (2 * speed); + scll -= 7; + sclh -= 5; + if ((scll < 0) || (sclh < 0)) { + printf("Error : I2C initializing clock\n"); + return; + }
writew(0x2, I2C_SYSC); /* for ES2 after soft reset */ udelay(1000); @@ -42,12 +84,10 @@ void i2c_init (int speed, int slaveadd) udelay (50000); }
- /* 12MHz I2C module clock */ - writew (0, I2C_PSC); - speed = speed/1000; /* 100 or 400 */ - scl = ((12000/(speed*2)) - 7); /* use 7 when PSC = 0 */ - writew (scl, I2C_SCLL); - writew (scl, I2C_SCLH); + writew(psc, I2C_PSC); + writew(scll, I2C_SCLL); + writew(sclh, I2C_SCLH); + /* own address */ writew (slaveadd, I2C_OA); writew (I2C_CON_EN, I2C_CON); diff --git a/include/asm-arm/arch-omap3/i2c.h b/include/asm-arm/arch-omap3/i2c.h index 3937f35..09afca0 100644 --- a/include/asm-arm/arch-omap3/i2c.h +++ b/include/asm-arm/arch-omap3/i2c.h @@ -112,14 +112,14 @@ #define I2C_SCLH_HSSCLH 8 #define I2C_SCLH_HSSCLH_M 0xFF
-#define OMAP_I2C_STANDARD 100 -#define OMAP_I2C_FAST_MODE 400 -#define OMAP_I2C_HIGH_SPEED 3400 - -#define SYSTEM_CLOCK_12 12000 -#define SYSTEM_CLOCK_13 13000 -#define SYSTEM_CLOCK_192 19200 -#define SYSTEM_CLOCK_96 96000 +#define OMAP_I2C_STANDARD 100000 +#define OMAP_I2C_FAST_MODE 400000 +#define OMAP_I2C_HIGH_SPEED 3400000 + +#define SYSTEM_CLOCK_12 12000000 +#define SYSTEM_CLOCK_13 13000000 +#define SYSTEM_CLOCK_192 19200000 +#define SYSTEM_CLOCK_96 96000000
#define I2C_IP_CLK SYSTEM_CLOCK_96 #define I2C_PSC_MAX 0x0f
The TWL4030 supplies many peripheral for OMAP3 boards. These include power management, usb and, keyboard.
The product description is found here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html
Product reference document, tps65950.pdf, is found here:
http://www.ti.com/lit/gpn/tps65950
Signed-off-by: Tom Rix Tom.Rix@windriver.com --- drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/twl4030_i2c.c create mode 100644 include/twl4030.h
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..97d9128 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -36,6 +36,7 @@ COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o COBJS-$(CONFIG_S3C44B0_I2C) += s3c44b0_i2c.o COBJS-$(CONFIG_SOFT_I2C) += soft_i2c.o COBJS-$(CONFIG_TSI108_I2C) += tsi108_i2c.o +COBJS-$(CONFIG_DRIVER_TWL4030_I2C) += twl4030_i2c.o
COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c new file mode 100644 index 0000000..774f813 --- /dev/null +++ b/drivers/i2c/twl4030_i2c.c @@ -0,0 +1,37 @@ +/* + * Copyright (c) 2009 Wind River Systems, Inc. + * Tom Rix Tom.Rix@windriver.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + * + * Derived from code on omapzoom, git://git.omapzoom.com/repo/u-boot.git + * + * Copyright (C) 2007-2009 Texas Instruments, Inc. + */ + +#include <twl4030.h> + +/* Functions to read and write from TWL4030 */ +static inline int twl4030_i2c_write_u8(u8 chip_no, u8 val, u8 reg) +{ + return i2c_write(chip_no, reg, 1, &val, 1); +} + +static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) +{ + return i2c_read(chip_no, reg, 1, val, 1); +} + diff --git a/include/twl4030.h b/include/twl4030.h new file mode 100644 index 0000000..d17fea5 --- /dev/null +++ b/include/twl4030.h @@ -0,0 +1,221 @@ +/* + * Copyright (c) 2009 Wind River Systems, Inc. + * Tom Rix Tom.Rix@windriver.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + * + * Derived from code on omapzoom, git://git.omapzoom.com/repo/u-boot.git + * + * Copyright (C) 2007-2009 Texas Instruments, Inc. + */ + +#ifndef TWL4030_H +#define TWL4030_H + +#include <common.h> +#include <i2c.h> + +/* I2C chip addresses */ + +/* USB */ +#define TWL4030_CHIP_USB 0x48 +/* AUD */ +#define TWL4030_CHIP_AUDIO_VOICE 0x49 +#define TWL4030_CHIP_GPIO 0x49 +#define TWL4030_CHIP_INTBR 0x49 +#define TWL4030_CHIP_PIH 0x49 +#define TWL4030_CHIP_TEST 0x49 +/* AUX */ +#define TWL4030_CHIP_KEYPAD 0x4a +#define TWL4030_CHIP_MADC 0x4a +#define TWL4030_CHIP_INTERRUPTS 0x4a +#define TWL4030_CHIP_LED 0x4a +#define TWL4030_CHIP_MAIN_CHARGE 0x4a +#define TWL4030_CHIP_PRECHARGE 0x4a +#define TWL4030_CHIP_PWM0 0x4a +#define TWL4030_CHIP_PWM1 0x4a +#define TWL4030_CHIP_PWMA 0x4a +#define TWL4030_CHIP_PWMB 0x4a +/* POWER */ +#define TWL4030_CHIP_BACKUP 0x4b +#define TWL4030_CHIP_INT 0x4b +#define TWL4030_CHIP_PM_MASTER 0x4b +#define TWL4030_CHIP_PM_RECEIVER 0x4b +#define TWL4030_CHIP_RTC 0x4b +#define TWL4030_CHIP_SECURED_REG 0x4b + +/* Register base addresses */ + +/* USB */ +#define TWL4030_BASEADD_USB 0x0000 +/* AUD */ +#define TWL4030_BASEADD_AUDIO_VOICE 0x0000 +#define TWL4030_BASEADD_GPIO 0x0098 +#define TWL4030_BASEADD_INTBR 0x0085 +#define TWL4030_BASEADD_PIH 0x0080 +#define TWL4030_BASEADD_TEST 0x004C +/* AUX */ +#define TWL4030_BASEADD_INTERRUPTS 0x00B9 +#define TWL4030_BASEADD_LED 0x00EE +#define TWL4030_BASEADD_MADC 0x0000 +#define TWL4030_BASEADD_MAIN_CHARGE 0x0074 +#define TWL4030_BASEADD_PRECHARGE 0x00AA +#define TWL4030_BASEADD_PWM0 0x00F8 +#define TWL4030_BASEADD_PWM1 0x00FB +#define TWL4030_BASEADD_PWMA 0x00EF +#define TWL4030_BASEADD_PWMB 0x00F1 +#define TWL4030_BASEADD_KEYPAD 0x00D2 +/* POWER */ +#define TWL4030_BASEADD_BACKUP 0x0014 +#define TWL4030_BASEADD_INT 0x002E +#define TWL4030_BASEADD_PM_MASTER 0x0036 +#define TWL4030_BASEADD_PM_RECIEVER 0x005B +#define TWL4030_BASEADD_RTC 0x001C +#define TWL4030_BASEADD_SECURED_REG 0x0000 + +/* + * Power Management Master + */ +#define TWL4030_PM_MASTER_CFG_P1_TRANSITION 0x36 +#define TWL4030_PM_MASTER_CFG_P2_TRANSITION 0x37 +#define TWL4030_PM_MASTER_CFG_P3_TRANSITION 0x38 +#define TWL4030_PM_MASTER_CFG_P123_TRANSITION 0x39 +#define TWL4030_PM_MASTER_STS_BOOT 0x3A +#define TWL4030_PM_MASTER_CFG_BOOT 0x3B +#define TWL4030_PM_MASTER_SHUNDAN 0x3C +#define TWL4030_PM_MASTER_BOOT_BCI 0x3D +#define TWL4030_PM_MASTER_CFG_PWRANA1 0x3E +#define TWL4030_PM_MASTER_CFG_PWRANA2 0x3F +#define TWL4030_PM_MASTER_BGAP_TRIM 0x40 +#define TWL4030_PM_MASTER_BACKUP_MISC_STS 0x41 +#define TWL4030_PM_MASTER_BACKUP_MISC_CFG 0x42 +#define TWL4030_PM_MASTER_BACKUP_MISC_TST 0x43 +#define TWL4030_PM_MASTER_PROTECT_KEY 0x44 +#define TWL4030_PM_MASTER_STS_HW_CONDITIONS 0x45 +#define TWL4030_PM_MASTER_P1_SW_EVENTS 0x46 +#define TWL4030_PM_MASTER_P2_SW_EVENTS 0x47 +#define TWL4030_PM_MASTER_P3_SW_EVENTS 0x48 +#define TWL4030_PM_MASTER_STS_P123_STATE 0x49 +#define TWL4030_PM_MASTER_PB_CFG 0x4A +#define TWL4030_PM_MASTER_PB_WORD_MSB 0x4B +#define TWL4030_PM_MASTER_PB_WORD_LSB 0x4C +#define TWL4030_PM_MASTER_SEQ_ADD_W2P 0x52 +#define TWL4030_PM_MASTER_SEQ_ADD_P2A 0x53 +#define TWL4030_PM_MASTER_SEQ_ADD_A2W 0x54 +#define TWL4030_PM_MASTER_SEQ_ADD_A2S 0x55 +#define TWL4030_PM_MASTER_SEQ_ADD_S2A12 0x56 +#define TWL4030_PM_MASTER_SEQ_ADD_S2A3 0x57 +#define TWL4030_PM_MASTER_SEQ_ADD_WARM 0x58 +#define TWL4030_PM_MASTER_MEMORY_ADDRESS 0x59 +#define TWL4030_PM_MASTER_MEMORY_DATA 0x5A +#define TWL4030_PM_MASTER_SC_CONFIG 0x5B +#define TWL4030_PM_MASTER_SC_DETECT1 0x5C +#define TWL4030_PM_MASTER_SC_DETECT2 0x5D +#define TWL4030_PM_MASTER_WATCHDOG_CFG 0x5E +#define TWL4030_PM_MASTER_IT_CHECK_CFG 0x5F +#define TWL4030_PM_MASTER_VIBRATOR_CFG 0x60 +#define TWL4030_PM_MASTER_DCDC_GLOBAL_CFG 0x61 +#define TWL4030_PM_MASTER_VDD1_TRIM1 0x62 +#define TWL4030_PM_MASTER_VDD1_TRIM2 0x63 +#define TWL4030_PM_MASTER_VDD2_TRIM1 0x64 +#define TWL4030_PM_MASTER_VDD2_TRIM2 0x65 +#define TWL4030_PM_MASTER_VIO_TRIM1 0x66 +#define TWL4030_PM_MASTER_VIO_TRIM2 0x67 +#define TWL4030_PM_MASTER_MISC_CFG 0x68 +#define TWL4030_PM_MASTER_LS_TST_A 0x69 +#define TWL4030_PM_MASTER_LS_TST_B 0x6A +#define TWL4030_PM_MASTER_LS_TST_C 0x6B +#define TWL4030_PM_MASTER_LS_TST_D 0x6C +#define TWL4030_PM_MASTER_BB_CFG 0x6D +#define TWL4030_PM_MASTER_MISC_TST 0x6E +#define TWL4030_PM_MASTER_TRIM1 0x6F +/* P[1-3]_SW_EVENTS */ +#define TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON (1 << 6) +#define TWL4030_PM_MASTER_SW_EVENTS_STOPON_SYSEN (1 << 5) +#define TWL4030_PM_MASTER_SW_EVENTS_ENABLE_WARMRESET (1 << 4) +#define TWL4030_PM_MASTER_SW_EVENTS_LVL_WAKEUP (1 << 3) +#define TWL4030_PM_MASTER_SW_EVENTS_DEVACT (1 << 2) +#define TWL4030_PM_MASTER_SW_EVENTS_DEVSLP (1 << 1) +#define TWL4030_PM_MASTER_SW_EVENTS_DEVOFF (1 << 0) + +/* Power Managment Receiver */ +#define TWL4030_PM_RECEIVER_VUSB1V5_DEV_GRP 0xCC +#define TWL4030_PM_RECEIVER_VUSB1V5_TYPE 0xCD +#define TWL4030_PM_RECEIVER_VUSB1V5_REMAP 0xCE +#define TWL4030_PM_RECEIVER_VUSB1V8_DEV_GRP 0xCF +#define TWL4030_PM_RECEIVER_VUSB1V8_TYPE 0xD0 +#define TWL4030_PM_RECEIVER_VUSB1V8_REMAP 0xD1 +#define TWL4030_PM_RECEIVER_VUSB3V1_DEV_GRP 0xD2 +#define TWL4030_PM_RECEIVER_VUSB3V1_TYPE 0xD3 +#define TWL4030_PM_RECEIVER_VUSB3V1_REMAP 0xD4 +#define TWL4030_PM_RECEIVER_VUSBCP_DEV_GRP 0xD5 +#define TWL4030_PM_RECEIVER_VUSBCP_DEV_TYPE 0xD6 +#define TWL4030_PM_RECEIVER_VUSBCP_DEV_REMAP 0xD7 +#define TWL4030_PM_RECEIVER_VUSB_DEDICATED1 0xD8 +#define TWL4030_PM_RECEIVER_VUSB_DEDICATED2 0xD9 + +/* Keypad */ +#define TWL4030_KEYPAD_KEYP_CTRL_REG 0xD2 +#define TWL4030_KEYPAD_KEY_DEB_REG 0xD3 +#define TWL4030_KEYPAD_LONG_KEY_REG1 0xD4 +#define TWL4030_KEYPAD_LK_PTV_REG 0xD5 +#define TWL4030_KEYPAD_TIME_OUT_REG1 0xD6 +#define TWL4030_KEYPAD_TIME_OUT_REG2 0xD7 +#define TWL4030_KEYPAD_KBC_REG 0xD8 +#define TWL4030_KEYPAD_KBR_REG 0xD9 +#define TWL4030_KEYPAD_KEYP_SMS 0xDA +#define TWL4030_KEYPAD_FULL_CODE_7_0 0xDB +#define TWL4030_KEYPAD_FULL_CODE_15_8 0xDC +#define TWL4030_KEYPAD_FULL_CODE_23_16 0xDD +#define TWL4030_KEYPAD_FULL_CODE_31_24 0xDE +#define TWL4030_KEYPAD_FULL_CODE_39_32 0xDF +#define TWL4030_KEYPAD_FULL_CODE_47_40 0xE0 +#define TWL4030_KEYPAD_FULL_CODE_55_48 0xE1 +#define TWL4030_KEYPAD_FULL_CODE_63_56 0xE2 +#define TWL4030_KEYPAD_KEYP_ISR1 0xE3 +#define TWL4030_KEYPAD_KEYP_IMR1 0xE4 +#define TWL4030_KEYPAD_KEYP_ISR2 0xE5 +#define TWL4030_KEYPAD_KEYP_IMR2 0xE6 +#define TWL4030_KEYPAD_KEYP_SIR 0xE7 +#define TWL4030_KEYPAD_KEYP_EDR 0xE8 +#define TWL4030_KEYPAD_KEYP_SIH_CTRL 0xE9 + +#define TWL4030_KEYPAD_CTRL_KBD_ON (1 << 6) +#define TWL4030_KEYPAD_CTRL_RP_EN (1 << 5) +#define TWL4030_KEYPAD_CTRL_TOLE_EN (1 << 4) +#define TWL4030_KEYPAD_CTRL_TOE_EN (1 << 3) +#define TWL4030_KEYPAD_CTRL_LK_EN (1 << 2) +#define TWL4030_KEYPAD_CTRL_SOFTMODEN (1 << 1) +#define TWL4030_KEYPAD_CTRL_SOFT_NRST (1 << 0) + +/* USB */ +#define TWL4030_USB_FUNC_CTRL (0x04) +#define TWL4030_USB_OPMODE_MASK (3 << 3) +#define TWL4030_USB_XCVRSELECT_MASK (3 << 0) +#define TWL4030_USB_IFC_CTRL (0x07) +#define TWL4030_USB_CARKITMODE (1 << 2) +#define TWL4030_USB_POWER_CTRL (0xAC) +#define TWL4030_USB_OTG_ENAB (1 << 5) +#define TWL4030_USB_PHY_PWR_CTRL (0xFD) +#define TWL4030_USB_PHYPWD (1 << 0) +#define TWL4030_USB_PHY_CLK_CTRL (0xFE) +#define TWL4030_USB_CLOCKGATING_EN (1 << 2) +#define TWL4030_USB_CLK32K_EN (1 << 1) +#define TWL4030_USB_REQ_PHY_DPLL_CLK (1 << 0) +#define TWL4030_USB_PHY_CLK_CTRL_STS (0xFF) +#define TWL4030_USB_PHY_DPLL_CLK (1 << 0) + +#endif /* TWL4030_H */
The power reset button is on the top right side of the main board. Press and hold for about to 8 seconds to completely reset the board.
Some of the beta boards have a hardware problem that prevents using this feature. If is difficult to further characterize the boards that fail. So disable resetting for all beta boards.
Signed-off-by: Tom Rix Tom.Rix@windriver.com --- board/omap3/zoom2/zoom2.c | 13 +++++++++++++ drivers/i2c/twl4030_i2c.c | 22 ++++++++++++++++++++++ include/configs/omap3_zoom2.h | 1 + include/twl4030.h | 10 ++++++++++ 4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/board/omap3/zoom2/zoom2.c b/board/omap3/zoom2/zoom2.c index 08fdafb..d5da920 100644 --- a/board/omap3/zoom2/zoom2.c +++ b/board/omap3/zoom2/zoom2.c @@ -32,6 +32,7 @@ #ifdef CONFIG_STATUS_LED #include <status_led.h> #endif +#include <twl4030.h> #include <asm/io.h> #include <asm/arch/gpio.h> #include <asm/arch/mem.h> @@ -141,6 +142,18 @@ int board_init (void) /* boot param addr */ gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+ /* + * Board Reset + * The board is reset by holding the the large button + * on the top right side of the main board for + * eight seconds. + * + * There are reported problems of some beta boards + * continously resetting. For those boards, disable resetting. + */ + if (ZOOM2_REVISION_PRODUCTION <= zoom2_get_revision()) + twl4030_power_reset_init(); + #if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT) status_led_set (STATUS_LED_BOOT, STATUS_LED_ON); #endif diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) return i2c_read(chip_no, reg, 1, val, 1); }
+/* + * Power Reset + */ +void twl4030_power_reset_init(void) +{ +#ifdef CONFIG_OMAP3_ZOOM2 + u8 val = 0; + if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val, + TWL4030_PM_MASTER_P1_SW_EVENTS)) { + printf("Error:TWL4030: failed to read the power register\n"); + printf("Could not initialize hardware reset\n"); + } else { + val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON; + if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val, + TWL4030_PM_MASTER_P1_SW_EVENTS)) { + printf("Error:TWL4030: failed to write the power register\n"); + printf("Could not initialize hardware reset\n"); + } + } +#endif +} + diff --git a/include/configs/omap3_zoom2.h b/include/configs/omap3_zoom2.h index c2ad5bf..e69c5f1 100644 --- a/include/configs/omap3_zoom2.h +++ b/include/configs/omap3_zoom2.h @@ -145,6 +145,7 @@ #define CONFIG_SYS_I2C_BUS 0 #define CONFIG_SYS_I2C_BUS_SELECT 1 #define CONFIG_DRIVER_OMAP34XX_I2C 1 +#define CONFIG_DRIVER_TWL4030_I2C 1
/* * Board NAND Info. diff --git a/include/twl4030.h b/include/twl4030.h index d17fea5..bb07036 100644 --- a/include/twl4030.h +++ b/include/twl4030.h @@ -218,4 +218,14 @@ #define TWL4030_USB_PHY_CLK_CTRL_STS (0xFF) #define TWL4030_USB_PHY_DPLL_CLK (1 << 0)
+#ifdef CONFIG_DRIVER_TWL4030_I2C + +/* Power Reset, use to initialize system wide resetting */ +void twl4030_power_reset_init(void); + +#else +/* stubs */ +#define twl4030_power_reset_init() + +#endif /* CONFIG_DRIVER_TWL4030_I2C */ #endif /* TWL4030_H */
The reset button is the red circle on the top right, front of the board. Press and hold the button for 8 seconds to completely reset the board.
Signed-off-by: Tom Rix Tom.Rix@windriver.com --- board/omap3/zoom1/zoom1.c | 8 ++++++++ drivers/i2c/twl4030_i2c.c | 2 +- include/configs/omap3_zoom1.h | 1 + 3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/board/omap3/zoom1/zoom1.c b/board/omap3/zoom1/zoom1.c index db4d087..8a3afaf 100644 --- a/board/omap3/zoom1/zoom1.c +++ b/board/omap3/zoom1/zoom1.c @@ -31,6 +31,7 @@ * MA 02111-1307 USA */ #include <common.h> +#include <twl4030.h> #include <asm/io.h> #include <asm/arch/mux.h> #include <asm/arch/sys_proto.h> @@ -51,6 +52,13 @@ int board_init(void) /* boot param addr */ gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+ /* + * Board Reset + * The board is reset by holding the red button on the + * top right front face for eight seconds. + */ + twl4030_power_reset_init(); + return 0; }
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 549f974..00146f8 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -40,7 +40,7 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) */ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1) u8 val = 0; if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val, TWL4030_PM_MASTER_P1_SW_EVENTS)) { diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h index 9e000ed..983808e 100644 --- a/include/configs/omap3_zoom1.h +++ b/include/configs/omap3_zoom1.h @@ -124,6 +124,7 @@ #define CONFIG_SYS_I2C_BUS 0 #define CONFIG_SYS_I2C_BUS_SELECT 1 #define CONFIG_DRIVER_OMAP34XX_I2C 1 +#define CONFIG_DRIVER_TWL4030_I2C 1
/* * Board NAND Info.
On 07:53 Wed 10 Jun , Tom Rix wrote:
The reset button is the red circle on the top right, front of the board. Press and hold the button for 8 seconds to completely reset the board.
Signed-off-by: Tom Rix Tom.Rix@windriver.com
board/omap3/zoom1/zoom1.c | 8 ++++++++ drivers/i2c/twl4030_i2c.c | 2 +- include/configs/omap3_zoom1.h | 1 + 3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/board/omap3/zoom1/zoom1.c b/board/omap3/zoom1/zoom1.c index db4d087..8a3afaf 100644 --- a/board/omap3/zoom1/zoom1.c +++ b/board/omap3/zoom1/zoom1.c @@ -31,6 +31,7 @@
- MA 02111-1307 USA
*/ #include <common.h> +#include <twl4030.h> #include <asm/io.h> #include <asm/arch/mux.h> #include <asm/arch/sys_proto.h> @@ -51,6 +52,13 @@ int board_init(void) /* boot param addr */ gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
- /*
* Board Reset* The board is reset by holding the red button on the* top right front face for eight seconds.*/- twl4030_power_reset_init();
- return 0;
}
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 549f974..00146f8 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -40,7 +40,7 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) */ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
I think it will be better to avoid board specifc code in the driver unless it's the only solution
Best Regards, J.
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 07:53 Wed 10 Jun , Tom Rix wrote:
The reset button is the red circle on the top right, front of the board. Press and hold the button for 8 seconds to completely reset the board.
Signed-off-by: Tom Rix Tom.Rix@windriver.com
board/omap3/zoom1/zoom1.c | 8 ++++++++ drivers/i2c/twl4030_i2c.c | 2 +- include/configs/omap3_zoom1.h | 1 + 3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/board/omap3/zoom1/zoom1.c b/board/omap3/zoom1/zoom1.c index db4d087..8a3afaf 100644 --- a/board/omap3/zoom1/zoom1.c +++ b/board/omap3/zoom1/zoom1.c @@ -31,6 +31,7 @@
- MA 02111-1307 USA
*/ #include <common.h> +#include <twl4030.h> #include <asm/io.h> #include <asm/arch/mux.h> #include <asm/arch/sys_proto.h> @@ -51,6 +52,13 @@ int board_init(void) /* boot param addr */ gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
- /*
* Board Reset* The board is reset by holding the red button on the* top right front face for eight seconds.*/- twl4030_power_reset_init();
- return 0;
}
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 549f974..00146f8 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -40,7 +40,7 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) */ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
I think it will be better to avoid board specifc code in the driver unless it's the only solution
I think this is zoom1 and zoom2 specific. I could add this function to each of their board files. I was trying to avoid that.
Tom
Best Regards, J.
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Friday, June 12, 2009 4:57 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Menon, Nishanth Subject: Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
*/ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
I think it will be better to avoid board specifc code in the driver unless it's the only solution
I think this is zoom1 and zoom2 specific. I could add this function to each of their board files. I was trying to avoid that.
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {
Why is this zoom1 and zoom2 specific? You are playing with PM Master registers causing a board reset right? It should in theory work for beagleboard also.. am I wrong?
Regards, Nishanth Menon
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Friday, June 12, 2009 4:57 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Menon, Nishanth Subject: Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
*/ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
I think it will be better to avoid board specifc code in the driver unless it's the only solution
I think this is zoom1 and zoom2 specific. I could add this function to each of their board files. I was trying to avoid that.
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {Why is this zoom1 and zoom2 specific? You are playing with PM Master registers causing a board reset right? It should in theory work for beagleboard also.. am I wrong?
Half right I think. The beagle, from the schematics, has a 'Reset' - 'S2' switch. This is tied to them omap's sys_nRespwon and to the t2_nRespwon. I think when the switch is pressed only the omap gets reset. I could try verifing this but it would take a while. Looking at theTWL4030_PM_MASTER_P1_SW_EVENTS using 'i2c md 4b 46' it is clear in both the factory and the current versions of u-boot.
I think that setting this bit in beagle will reset just the twl4030. Which I think is the right thing to do.
I will try removing the #if-defs and see what happens :|
Tom
Regards, Nishanth Menon
Tom wrote:
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Friday, June 12, 2009 4:57 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Menon, Nishanth Subject: Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
*/ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
I think it will be better to avoid board specifc code in the driver unless it's the only solution
I think this is zoom1 and zoom2 specific. I could add this function to each of their board files. I was trying to avoid that.
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
- TWL4030_PM_MASTER_P1_SW_EVENTS)) {
- printf("Error:TWL4030: failed to read the power register\n");
- printf("Could not initialize hardware reset\n");
- } else {
- val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;
- if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,
- TWL4030_PM_MASTER_P1_SW_EVENTS)) {
Why is this zoom1 and zoom2 specific? You are playing with PM Master registers causing a board reset right? It should in theory work for beagleboard also.. am I wrong?
Half right I think. The beagle, from the schematics, has a 'Reset' - 'S2' switch. This is tied to them omap's sys_nRespwon and to the t2_nRespwon. I think when the switch is pressed only the omap gets reset. I could try verifing this but it would take a while. Looking at theTWL4030_PM_MASTER_P1_SW_EVENTS using 'i2c md 4b 46' it is clear in both the factory and the current versions of u-boot.
I think that setting this bit in beagle will reset just the twl4030. Which I think is the right thing to do.
I will try removing the #if-defs and see what happens :|
I have taken a closer look. I think the 'Cold Reset' label for switch 2 should be relabeled 'Warm Reset' twl4030 registers are persistent on beagle and zoom1 when both the sw reset cmd is given and when the beagle reset or the zoom1 reset (pin hole in back + handy paperclip) is used. The easiest way to test this is to set the sw_events manually using inm 4b 46 then set to 40 Verify with imd 4b 46.
When the hw reset button is used on the zoom1, front face red button, the board resets and this is clear. On beagle you need to cycle power by unplugging / replugging power. Otherwise it does not get reset.
Looking at beagle schematics, the ic SN74LVC2G07 has nRESPWRON as an input. So the resetting of the omap is an or-ing of nRESPWRON and the switch. The switch has no effect on nRESPWRON. If the input & output of ic were reversed, you _may_ get the behaviour of resetting omap with a touch and resetting omap+twl4030 when held for 8+ seconds.
The moral of the story is do not depend on twl4030 to be reset.
For this patch for resetting, the reset logic is generic and should be in the driver layer and not in the board layer.
Tom
looping in beagleboard for comments.
Tom said the following on 06/13/2009 09:16 AM:
Tom wrote:
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Friday, June 12, 2009 4:57 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Menon, Nishanth Subject: Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
*/ void twl4030_power_reset_init(void) { -#ifdef CONFIG_OMAP3_ZOOM2 +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
I think it will be better to avoid board specifc code in the driver unless it's the only solution
I think this is zoom1 and zoom2 specific. I could add this function to each of their board files. I was trying to avoid that.
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
- TWL4030_PM_MASTER_P1_SW_EVENTS)) {
- printf("Error:TWL4030: failed to read the power register\n");
- printf("Could not initialize hardware reset\n");
- } else {
- val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;
- if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,
- TWL4030_PM_MASTER_P1_SW_EVENTS)) {
Why is this zoom1 and zoom2 specific? You are playing with PM Master registers causing a board reset right? It should in theory work for beagleboard also.. am I wrong?
Half right I think. The beagle, from the schematics, has a 'Reset' - 'S2' switch. This is tied to them omap's sys_nRespwon and to the t2_nRespwon. I think when the switch is pressed only the omap gets reset. I could try verifing this but it would take a while. Looking at theTWL4030_PM_MASTER_P1_SW_EVENTS using 'i2c md 4b 46' it is clear in both the factory and the current versions of u-boot.
I think that setting this bit in beagle will reset just the twl4030. Which I think is the right thing to do.
I will try removing the #if-defs and see what happens :|
I have taken a closer look. I think the 'Cold Reset' label for switch 2 should be relabeled 'Warm Reset' twl4030 registers are persistent on beagle and zoom1 when both the sw reset cmd is given and when the beagle reset or the zoom1 reset (pin hole in back + handy paperclip) is used. The easiest way to test this is to set the sw_events manually using inm 4b 46 then set to 40 Verify with imd 4b 46.
When the hw reset button is used on the zoom1, front face red button, the board resets and this is clear. On beagle you need to cycle power by unplugging / replugging power. Otherwise it does not get reset.
Looking at beagle schematics, the ic SN74LVC2G07 has nRESPWRON as an input. So the resetting of the omap is an or-ing of nRESPWRON and the switch. The switch has no effect on nRESPWRON. If the input & output of ic were reversed, you _may_ get the behaviour of resetting omap with a touch and resetting omap+twl4030 when held for 8+ seconds.
The moral of the story is do not depend on twl4030 to be reset.
For this patch for resetting, the reset logic is generic and should be in the driver layer and not in the board layer.
Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Tom,
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) return i2c_read(chip_no, reg, 1, val, 1); }
+/*
- Power Reset
- */
+void twl4030_power_reset_init(void) +{ +#ifdef CONFIG_OMAP3_ZOOM2
- u8 val = 0;
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to write the power register\n");printf("Could not initialize hardware reset\n");}- }
+#endif +}
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would be better placed in drivers/misc or a new drivers/power directory similar to Linux?
FWIW I had the same dilemma with the ds4510 i2c device which has support for GPIO, EEEPROM, etc and ended up putting it in drivers/misc.
Best, Peter
-----Original Message----- From: Peter Tyser [mailto:ptyser@xes-inc.com] Sent: Wednesday, June 10, 2009 9:27 AM
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8
*val, u8 reg)
return i2c_read(chip_no, reg, 1, val, 1); }
+/*
- Power Reset
- */
+void twl4030_power_reset_init(void) +{ +#ifdef CONFIG_OMAP3_ZOOM2
- u8 val = 0;
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to write the powerregister\n");
printf("Could not initialize hardware reset\n");}- }
+#endif +}
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would be better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even better to the board file itself? Regards, Nishanth Menon
Menon, Nishanth wrote:
-----Original Message----- From: Peter Tyser [mailto:ptyser@xes-inc.com] Sent: Wednesday, June 10, 2009 9:27 AM
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8
*val, u8 reg)
return i2c_read(chip_no, reg, 1, val, 1); }
+/*
- Power Reset
- */
+void twl4030_power_reset_init(void) +{ +#ifdef CONFIG_OMAP3_ZOOM2
- u8 val = 0;
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to write the powerregister\n");
printf("Could not initialize hardware reset\n");}- }
+#endif +}
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would be better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
Best regards
Dirk
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: Wednesday, June 10, 2009 10:44 AM
--- a/drivers/i2c/twl4030_i2c.c
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would
be
better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even
better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
This IMHO is the right approach -> but the real question is where in drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization?
Regards, Nishanth Menon
On Wed, 2009-06-10 at 11:16 -0500, Menon, Nishanth wrote:
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: Wednesday, June 10, 2009 10:44 AM
--- a/drivers/i2c/twl4030_i2c.c
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would
be
better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even
better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
This IMHO is the right approach -> but the real question is where in drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization?
I'd vote against creating a drivers/i2c/chips directory. I believe this directory is deprecated in the Linux kernel and they'd prefer drivers be put in the proper driver/<subsystem> directory. I'd vote to follow this convention in U-Boot too.
I'm not familiar with the device or what features you plan on supporting so I can't speak to whether it'd fit better in drivers/power, drivers/misc, somewhere omap3/board specific, etc.
Best. Peter
Hello Peter,
Peter Tyser wrote:
On Wed, 2009-06-10 at 11:16 -0500, Menon, Nishanth wrote:
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: Wednesday, June 10, 2009 10:44 AM
--- a/drivers/i2c/twl4030_i2c.c
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would
be
better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even
better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
This IMHO is the right approach -> but the real question is where in drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization?
I'd vote against creating a drivers/i2c/chips directory. I believe this
Full Ack.
directory is deprecated in the Linux kernel and they'd prefer drivers be put in the proper driver/<subsystem> directory. I'd vote to follow this convention in U-Boot too.
Yep. I vote for this too.
I'm not familiar with the device or what features you plan on supporting so I can't speak to whether it'd fit better in drivers/power, drivers/misc, somewhere omap3/board specific, etc.
I think "drivers/power" would be a good place for it.
bye Heiko
-----Original Message----- From: Peter Tyser [mailto:ptyser@xes-inc.com] Sent: Wednesday, June 10, 2009 11:26 AM
--- a/drivers/i2c/twl4030_i2c.c
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init().
The
twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it
would
be
better placed in drivers/misc or a new drivers/power directory
similar
to Linux?
This function probably belongs to board/omap3/common/power.c -> or
even
better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver
directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
This IMHO is the right approach -> but the real question is where in
drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization?
I'd vote against creating a drivers/i2c/chips directory. I believe this directory is deprecated in the Linux kernel and they'd prefer drivers be put in the proper driver/<subsystem> directory. I'd vote to follow this convention in U-Boot too.
I'm not familiar with the device or what features you plan on supporting so I can't speak to whether it'd fit better in drivers/power, drivers/misc, somewhere omap3/board specific, etc.
How about this:
Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c On patch [PATCH 2/4] I2C Add initial support for TWL4030: B) introduce a new header in include/twl4030.h from Tom's patch Remove drivers/i2c/twl4030_i2c.c from the patch instead add: #define TWLL4030_READ_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) to include/twl4030.h in the patch.
C) on [PATCH 3/4] ZOOM2 Add power reset button The change should go to corresponding board file -> for zoom1 or zoom2.
Regards, Nishanth Menon
Hello Menon,
Menon, Nishanth wrote:
-----Original Message----- From: Peter Tyser [mailto:ptyser@xes-inc.com] Sent: Wednesday, June 10, 2009 11:26 AM
> --- a/drivers/i2c/twl4030_i2c.c All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init().
The
twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it
would
be
better placed in drivers/misc or a new drivers/power directory
similar
to Linux?
This function probably belongs to board/omap3/common/power.c -> or
even
better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver
directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
This IMHO is the right approach -> but the real question is where in
drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization?
I'd vote against creating a drivers/i2c/chips directory. I believe this directory is deprecated in the Linux kernel and they'd prefer drivers be put in the proper driver/<subsystem> directory. I'd vote to follow this convention in U-Boot too.
I'm not familiar with the device or what features you plan on supporting so I can't speak to whether it'd fit better in drivers/power, drivers/misc, somewhere omap3/board specific, etc.
How about this:
Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c
I don;t know, if this "board/omap3/common/power.c" is identical with twl4030 ... ?
On patch C: B) introduce a new header in include/twl4030.h from Tom's patch Remove drivers/i2c/twl4030_i2c.c from the patch instead add: #define TWLL4030_READ_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) to include/twl4030.h in the patch.
Maybe an option ... thats why I think it is no i2c driver ...
C) on [PATCH 3/4] ZOOM2 Add power reset button The change should go to corresponding board file -> for zoom1 or zoom2.
or in "drivers/power/twl4030.c", if it is for all zoom* boards identical.
bye Heiko
-----Original Message----- From: Heiko Schocher [mailto:hs@denx.de] Sent: Wednesday, June 10, 2009 1:22 PM
Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c
I don;t know, if this "board/omap3/common/power.c" is identical with twl4030 ... ?
The objective of power.c was to have only to have power related code for all omap3 platforms -> but currently there is only power_init_r function which is twl4030 compatible chips -> hence makes sense to break it out.
On patch C: B) introduce a new header in include/twl4030.h from Tom's patch Remove drivers/i2c/twl4030_i2c.c from the patch instead add: #define TWLL4030_READ_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) to include/twl4030.h in the patch.
Maybe an option ... thats why I think it is no i2c driver ...
C) on [PATCH 3/4] ZOOM2 Add power reset button The change should go to corresponding board file -> for zoom1 or zoom2.
or in "drivers/power/twl4030.c", if it is for all zoom* boards identical.
Yes - it can belong there I agree.
Regards, Nishanth Menon
How about this:
Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c
Ack but I've a patch for Dirk in my queued that I need to process about it so we have 2 choice 1) apply Dirk's patch first and the move the code to drivers/power 2) rewrite a patch against the next
I've in mind to do the 1) to mention in the changelog Dirk's work
On patch [PATCH 2/4] I2C Add initial support for TWL4030: B) introduce a new header in include/twl4030.h from Tom's patch Remove drivers/i2c/twl4030_i2c.c from the patch instead add: #define TWLL4030_READ_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) to include/twl4030.h in the patch.
please use inline function for this
Best Regards, J.
Jean-Christophe PLAGNIOL-VILLARD wrote:
How about this:
Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c
Ack but I've a patch for Dirk in my queued that I need to process about it so we have 2 choice
- apply Dirk's patch first and the move the code to drivers/power
- rewrite a patch against the next
Please forward me the patch, I will merge it into the drivers/power/twl4030.c I am creating.
I've in mind to do the 1) to mention in the changelog Dirk's work
On patch [PATCH 2/4] I2C Add initial support for TWL4030: B) introduce a new header in include/twl4030.h from Tom's patch Remove drivers/i2c/twl4030_i2c.c from the patch instead add: #define TWLL4030_READ_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) to include/twl4030.h in the patch.
please use inline function for this
Yes. I am doing adding this to twl4030.h
static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) {}
Best Regards, J.
On 08:02 Fri 12 Jun , Tom wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
How about this:
Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c
Ack but I've a patch for Dirk in my queued that I need to process about it so we have 2 choice
- apply Dirk's patch first and the move the code to drivers/power
- rewrite a patch against the next
Please forward me the patch, I will merge it into the drivers/power/twl4030.c I am creating.
http://www.mail-archive.com/u-boot@lists.denx.de/msg14133.html
Best Regards, J.
Hello Menon,
Menon, Nishanth wrote:
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: Wednesday, June 10, 2009 10:44 AM
--- a/drivers/i2c/twl4030_i2c.c
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would
be
better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even
better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
This IMHO is the right approach -> but the real question is where in drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization?
No, I vote for moving this driver in a "drivers/power" directory.
BTW: Can you please use a linelength <80 characters? Thanks.
bye Heiko
Hello Dirk,
Dirk Behme wrote:
Menon, Nishanth wrote:
-----Original Message----- From: Peter Tyser [mailto:ptyser@xes-inc.com] Sent: Wednesday, June 10, 2009 9:27 AM
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8
*val, u8 reg)
return i2c_read(chip_no, reg, 1, val, 1); }
+/*
- Power Reset
- */
+void twl4030_power_reset_init(void) +{ +#ifdef CONFIG_OMAP3_ZOOM2
- u8 val = 0;
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to write the powerregister\n");
printf("Could not initialize hardware reset\n");}- }
+#endif +}
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would be better placed in drivers/misc or a new drivers/power directory similar to Linux?
This function probably belongs to board/omap3/common/power.c -> or even better to the board file itself?
I was about to mention the opposite ;)
Jean-Christophe asked to move the code from power.c to driver directory
http://lists.denx.de/pipermail/u-boot/2009-May/052400.html
If you follow above discussion, I was fine with power.c. If we get now a twl4030_i2c.c, we should merge the code from power.c into it, too (where ever it will be located and named, then).
Hmm.. why not in a "drivers/power" directory? This twl4030_i2c.c is no i2c driver in my opinion. And I won;t to avoid creating subdirs in drivers/i2c.
I think an drivers/power directory would be a good solution.
bye Heiko
Hello Peter,
Peter Tyser wrote:
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) return i2c_read(chip_no, reg, 1, val, 1); }
+/*
- Power Reset
- */
+void twl4030_power_reset_init(void) +{ +#ifdef CONFIG_OMAP3_ZOOM2
- u8 val = 0;
- if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to read the power register\n");printf("Could not initialize hardware reset\n");- } else {
val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,TWL4030_PM_MASTER_P1_SW_EVENTS)) {printf("Error:TWL4030: failed to write the power register\n");printf("Could not initialize hardware reset\n");}- }
+#endif +}
All other drivers in drivers/i2c are host adapter drivers. Ie they implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would be better placed in drivers/misc or a new drivers/power directory similar to Linux?
Ack. Ah, I see, maybe drivers/power would be a better place for it.
FWIW I had the same dilemma with the ds4510 i2c device which has support for GPIO, EEEPROM, etc and ended up putting it in drivers/misc.
Yes, I want to see in drivers/i2c only drivers, which implement the i2c_* functions ... This twl4030 and the ds4510 drivers, use an i2c driver from hopefully in "drivers/i2c", and should go in an "drivers/"subsystem"" directory ...
bye Heiko
Hello Tom,
Tom Rix wrote:
The power reset button is on the top right side of the main board. Press and hold for about to 8 seconds to completely reset the board.
Some of the beta boards have a hardware problem that prevents using this feature. If is difficult to further characterize the boards that fail. So disable resetting for all beta boards.
Signed-off-by: Tom Rix Tom.Rix@windriver.com
board/omap3/zoom2/zoom2.c | 13 +++++++++++++ drivers/i2c/twl4030_i2c.c | 22 ++++++++++++++++++++++ include/configs/omap3_zoom2.h | 1 + include/twl4030.h | 10 ++++++++++ 4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/board/omap3/zoom2/zoom2.c b/board/omap3/zoom2/zoom2.c index 08fdafb..d5da920 100644 --- a/board/omap3/zoom2/zoom2.c +++ b/board/omap3/zoom2/zoom2.c
[...]
diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c index 774f813..549f974 100644 --- a/drivers/i2c/twl4030_i2c.c +++ b/drivers/i2c/twl4030_i2c.c @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) return i2c_read(chip_no, reg, 1, val, 1); }
+/*
- Power Reset
- */
+void twl4030_power_reset_init(void) +{
What has this to do with an i2c driver? No, I don;t want to see such a function in an i2c driver. I tend to put this "driver" in an another dir, like I said in my previous mail maybe in drivers/misc ...
bye Heiko
-----Original Message----- From: Tom Rix [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 7:54 AM To: u-boot@lists.denx.de Cc: dirk.behme@googlemail.com; Menon, Nishanth; Tom Rix Subject: [PATCH 2/4] I2C Add initial support for TWL4030
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221
This is an interesting area -> in kernel we used to have i2c/busses and i2c/chips -> u-boot has drivers/i2c which probably is equivalent to i2c/busses -> should we create subdirectories there? In the current form, this driver does not fit into drivers/i2c if I am not wrong..
Regards, Nishanth Menon
Hello Menon,
Menon, Nishanth wrote:
-----Original Message----- From: Tom Rix [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 7:54 AM To: u-boot@lists.denx.de Cc: dirk.behme@googlemail.com; Menon, Nishanth; Tom Rix Subject: [PATCH 2/4] I2C Add initial support for TWL4030
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221
This is an interesting area -> in kernel we used to have i2c/busses and i2c/chips -> u-boot has drivers/i2c which probably is equivalent to i2c/busses -> should we create subdirectories there? In the current form, this driver does not fit into drivers/i2c if I am not wrong..
No, I think it is not necessary here to create subdirs in "drivers/i2c". This driver should go in "drivers/power" ...
bye Heiko
Hello Tom,
Tom Rix wrote:
The TWL4030 supplies many peripheral for OMAP3 boards. These include power management, usb and, keyboard.
The product description is found here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html
Product reference document, tps65950.pdf, is found here:
http://www.ti.com/lit/gpn/tps65950
Signed-off-by: Tom Rix Tom.Rix@windriver.com
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/twl4030_i2c.c create mode 100644 include/twl4030.h
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..97d9128 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -36,6 +36,7 @@ COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o COBJS-$(CONFIG_S3C44B0_I2C) += s3c44b0_i2c.o COBJS-$(CONFIG_SOFT_I2C) += soft_i2c.o COBJS-$(CONFIG_TSI108_I2C) += tsi108_i2c.o +COBJS-$(CONFIG_DRIVER_TWL4030_I2C) += twl4030_i2c.o
COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c new file mode 100644 index 0000000..774f813 --- /dev/null +++ b/drivers/i2c/twl4030_i2c.c @@ -0,0 +1,37 @@ +/*
- Copyright (c) 2009 Wind River Systems, Inc.
- Tom Rix Tom.Rix@windriver.com
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of
- the License, or (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- Derived from code on omapzoom, git://git.omapzoom.com/repo/u-boot.git
- Copyright (C) 2007-2009 Texas Instruments, Inc.
- */
+#include <twl4030.h>
+/* Functions to read and write from TWL4030 */ +static inline int twl4030_i2c_write_u8(u8 chip_no, u8 val, u8 reg) +{
- return i2c_write(chip_no, reg, 1, &val, 1);
+}
+static inline int twl4030_i2c_read_u8(u8 chip_no, u8 *val, u8 reg) +{
- return i2c_read(chip_no, reg, 1, val, 1);
+}
? Is your patch complete?
Where are i2c_read(), i2c_write(),... functions, like in the other i2c drivers in u-boot? This seems no i2c driver to me, more than some board specific code, which you can add in your board.c ... or something like drivers/misc, if this is code is used in more than one plattform ... ?
diff --git a/include/twl4030.h b/include/twl4030.h new file mode 100644 index 0000000..d17fea5 --- /dev/null +++ b/include/twl4030.h @@ -0,0 +1,221 @@ +/*
[...]
bye Heiko
Dear Heiko,
In message 1244638432-30893-3-git-send-email-Tom.Rix@windriver.com Tom Rix wrote:
The TWL4030 supplies many peripheral for OMAP3 boards. These include power management, usb and, keyboard.
The product description is found here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html
Product reference document, tps65950.pdf, is found here:
http://www.ti.com/lit/gpn/tps65950
Signed-off-by: Tom Rix Tom.Rix@windriver.com
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/twl4030_i2c.c create mode 100644 include/twl4030.h
I think this is supposed to go through the i2c repo, but I haven't seen any comments yet.
Can you please check the state of this patch? Thanks in advance.
Best regards,
Wolfgang Denk
Hello Wolfgang,
Wolfgang Denk wrote:
In message 1244638432-30893-3-git-send-email-Tom.Rix@windriver.com Tom Rix wrote:
The TWL4030 supplies many peripheral for OMAP3 boards. These include power management, usb and, keyboard.
The product description is found here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html
Product reference document, tps65950.pdf, is found here:
http://www.ti.com/lit/gpn/tps65950
Signed-off-by: Tom Rix Tom.Rix@windriver.com
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/twl4030_i2c.c create mode 100644 include/twl4030.h
I think this is supposed to go through the i2c repo, but I haven't seen any comments yet.
Hmm.. there are responses, see for example:
http://lists.denx.de/pipermail/u-boot/2009-June/054086.html
Can you please check the state of this patch? Thanks in advance.
Hmm.. it is a little long to follow this ... it ended first here:
http://lists.denx.de/pipermail/u-boot/2009-June/054654.html
waiting for an Ack that it works on omap2 ...
(I Acked the resulting 3 patches, see: http://lists.denx.de/pipermail/u-boot/2009-June/054585.html )
Ah, found one more answer from Tom:
http://lists.denx.de/pipermail/u-boot/2009-June/054801.html
ended in:
http://lists.denx.de/pipermail/u-boot/2009-June/055071.html
with a new patchset of 6 patches, starting with: http://lists.denx.de/pipermail/u-boot/2009-June/055072.html
but state of omap2 is still pending ... see:
http://lists.denx.de/pipermail/u-boot/2009-June/055087.html
then Tom wrote, he has setup a git repo, see: http://lists.denx.de/pipermail/u-boot/2009-July/055328.html
but I think, the state of the omap2 is pending ... so I (and I think Jean-Christophe also) wait for, that this pending state is going away ...
Tom, do you have an update?
(added Jean-Christophe to cc:) bye Heiko
Omap2 is still pending. I was hoping to help Richard out with this last week but he was on travel.
There is not much more I think I can do wrt omap2. All my targets are omap3. The nearest I can find online is the nokia n8xx which uses a another bootloader.
The options as I see them are.
1. Get a pass on omap2 testing 2. Rewrite i2c init to have a omap3 specific init 3. Hack n8xx and try to convience you the results are reasonable 4. Wait for omap2 testing.
I vote for #1.
Tom
Heiko Schocher wrote:
Hello Wolfgang,
Wolfgang Denk wrote:
In message 1244638432-30893-3-git-send-email-Tom.Rix@windriver.com Tom Rix wrote:
The TWL4030 supplies many peripheral for OMAP3 boards. These include power management, usb and, keyboard.
The product description is found here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html
Product reference document, tps65950.pdf, is found here:
http://www.ti.com/lit/gpn/tps65950
Signed-off-by: Tom Rix Tom.Rix@windriver.com
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/twl4030_i2c.c create mode 100644 include/twl4030.h
I think this is supposed to go through the i2c repo, but I haven't seen any comments yet.
Hmm.. there are responses, see for example:
http://lists.denx.de/pipermail/u-boot/2009-June/054086.html
Can you please check the state of this patch? Thanks in advance.
Hmm.. it is a little long to follow this ... it ended first here:
http://lists.denx.de/pipermail/u-boot/2009-June/054654.html
waiting for an Ack that it works on omap2 ...
(I Acked the resulting 3 patches, see: http://lists.denx.de/pipermail/u-boot/2009-June/054585.html )
Ah, found one more answer from Tom:
http://lists.denx.de/pipermail/u-boot/2009-June/054801.html
ended in:
http://lists.denx.de/pipermail/u-boot/2009-June/055071.html
with a new patchset of 6 patches, starting with: http://lists.denx.de/pipermail/u-boot/2009-June/055072.html
but state of omap2 is still pending ... see:
http://lists.denx.de/pipermail/u-boot/2009-June/055087.html
then Tom wrote, he has setup a git repo, see: http://lists.denx.de/pipermail/u-boot/2009-July/055328.html
but I think, the state of the omap2 is pending ... so I (and I think Jean-Christophe also) wait for, that this pending state is going away ...
Tom, do you have an update?
(added Jean-Christophe to cc:) bye Heiko
Hello Tom,
Tom wrote:
Omap2 is still pending. I was hoping to help Richard out with this last week but he was on travel.
There is not much more I think I can do wrt omap2. All my targets are omap3. The nearest I can find online is the nokia n8xx which uses a another bootloader.
The options as I see them are.
- Get a pass on omap2 testing
- Rewrite i2c init to have a omap3 specific init
- Hack n8xx and try to convience you the results are reasonable
- Wait for omap2 testing.
I vote for #1.
Hmm.. because I think this patches go through Jean-Christophe he has to decide if this is acceptable.
bye Heiko
On 11:12 Mon 20 Jul , Heiko Schocher wrote:
Hello Tom,
Tom wrote:
Omap2 is still pending. I was hoping to help Richard out with this last week but he was on travel.
There is not much more I think I can do wrt omap2. All my targets are omap3. The nearest I can find online is the nokia n8xx which uses a another bootloader.
The options as I see them are.
- Get a pass on omap2 testing
- Rewrite i2c init to have a omap3 specific init
- Hack n8xx and try to convience you the results are reasonable
- Wait for omap2 testing.
I vote for #1.
Hmm.. because I think this patches go through Jean-Christophe he has to decide if this is acceptable.
we will not get a pass on the omap2 but we will do this in a second step as agree with Nishanth
Best Regards, J.
Tom wrote:
Omap2 is still pending. I was hoping to help Richard out with this last week but he was on travel.
There is not much more I think I can do wrt omap2. All my targets are omap3. The nearest I can find online is the nokia n8xx which uses a another bootloader.
The options as I see them are.
- Get a pass on omap2 testing
- Rewrite i2c init to have a omap3 specific init
- Hack n8xx and try to convience you the results are reasonable
- Wait for omap2 testing.
I vote for #1.
Me too.
Dirk
Heiko Schocher wrote:
Hello Wolfgang,
Wolfgang Denk wrote:
In message 1244638432-30893-3-git-send-email-Tom.Rix@windriver.com Tom Rix wrote:
The TWL4030 supplies many peripheral for OMAP3 boards. These include power management, usb and, keyboard.
The product description is found here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html
Product reference document, tps65950.pdf, is found here:
http://www.ti.com/lit/gpn/tps65950
Signed-off-by: Tom Rix Tom.Rix@windriver.com
drivers/i2c/Makefile | 1 + drivers/i2c/twl4030_i2c.c | 37 ++++++++ include/twl4030.h | 221 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/twl4030_i2c.c create mode 100644 include/twl4030.h
I think this is supposed to go through the i2c repo, but I haven't seen any comments yet.
Hmm.. there are responses, see for example:
http://lists.denx.de/pipermail/u-boot/2009-June/054086.html
Can you please check the state of this patch? Thanks in advance.
Hmm.. it is a little long to follow this ... it ended first here:
http://lists.denx.de/pipermail/u-boot/2009-June/054654.html
waiting for an Ack that it works on omap2 ...
(I Acked the resulting 3 patches, see: http://lists.denx.de/pipermail/u-boot/2009-June/054585.html )
Ah, found one more answer from Tom:
http://lists.denx.de/pipermail/u-boot/2009-June/054801.html
ended in:
http://lists.denx.de/pipermail/u-boot/2009-June/055071.html
with a new patchset of 6 patches, starting with: http://lists.denx.de/pipermail/u-boot/2009-June/055072.html
but state of omap2 is still pending ... see:
http://lists.denx.de/pipermail/u-boot/2009-June/055087.html
then Tom wrote, he has setup a git repo, see: http://lists.denx.de/pipermail/u-boot/2009-July/055328.html
but I think, the state of the omap2 is pending ... so I (and I think Jean-Christophe also) wait for, that this pending state is going away ...
Tom, do you have an update?
(added Jean-Christophe to cc:) bye Heiko
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-----Original Message----- From: Tom Rix [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 7:54 AM
void i2c_init (int speed, int slaveadd) {
- u16 scl;
int psc, iclk, scll, sclh;
/* Only handle standard and fast speeds */
if ((speed != OMAP_I2C_STANDARD) &&
(speed != OMAP_I2C_FAST_MODE)) {printf("Error : I2C unsupported speed %d\n", speed);return;}
/*
* Calculate the prescalar to go from from the function clock* to the internal sampling clock, 12MHz.*/psc = I2C_PSC_MAX;
while (psc >= I2C_PSC_MIN) {
iclk = I2C_IP_CLK / (psc + 1);if (12000000 <= iclk)break;psc--;}
if (psc < I2C_PSC_MIN) {
printf("Error : I2C unsupported prescalar %d\n", psc);return;}
/*
* How the low and high time periods are calculated* See the OMAP3xxx Reference Manual for more details** tlow + thigh = 1 / speed* thigh = tlow, nice square wave..** tlow = 1 / (2 * speed) = (scll + 7) / iclk;* scll + 7 = iclk / 2 * speed* sclh + 5 = iclk / 2 * speed*/scll = sclh = iclk / (2 * speed);
scll -= 7;
sclh -= 5;
if ((scll < 0) || (sclh < 0)) {
printf("Error : I2C initializing clock\n");return;}
writew(0x2, I2C_SYSC); /* for ES2 after soft reset */ udelay(1000);
@@ -42,12 +84,10 @@ void i2c_init (int speed, int slaveadd) udelay (50000);
This is a repeat story of what happened in linux-omap and kernel. We had a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch: a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Menon, Nishanth wrote:
This is a repeat story of what happened in linux-omap and kernel. We had a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch: a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ? Tom
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 9:44 PM
This is a repeat story of what happened in linux-omap and kernel. We had
a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch:
a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ?
#defines in config header file might be a viable option.. Though the gd might be cleaner I think..
Regards, Nishanth Menon
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 9:44 PM
This is a repeat story of what happened in linux-omap and kernel. We had
a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch:
a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ?
#defines in config header file might be a viable option.. Though the gd might be cleaner I think..
Regards, Nishanth Menon
How about something like this? The timing calculation is moved to a separate function that is weakly aliased to a function that the boards can define? This is similar to led initializing in lib_arm. I have put a stub omap_i2c_timing in zoom1.c to show how the board would do the define.
Tom
On 09:02 Thu 11 Jun , Tom wrote:
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 9:44 PM
This is a repeat story of what happened in linux-omap and kernel. We had
a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch:
a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ?
#defines in config header file might be a viable option.. Though the gd might be cleaner I think..
Regards, Nishanth Menon
How about something like this? The timing calculation is moved to a separate function that is weakly aliased to a function that the boards can define? This is similar to led initializing in lib_arm. I have put a stub omap_i2c_timing in zoom1.c to show how the board would do the define.
use weak function will increase the size of u-boot I'll prefer to avoid it when it's possible if no board mainline need it I'll prefer to avoid it also
Best Regards, J.
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:02 Thu 11 Jun , Tom wrote:
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 9:44 PM
This is a repeat story of what happened in linux-omap and kernel. We had
a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch:
a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ?
#defines in config header file might be a viable option.. Though the gd might be cleaner I think..
Regards, Nishanth Menon
How about something like this? The timing calculation is moved to a separate function that is weakly aliased to a function that the boards can define? This is similar to led initializing in lib_arm. I have put a stub omap_i2c_timing in zoom1.c to show how the board would do the define.
use weak function will increase the size of u-boot I'll prefer to avoid it when it's possible if no board mainline need it I'll prefer to avoid it also
I do not know of an example of a board that needs to be handled specially. The current code breaks the Zooms. The original fix works on the Zooms and beagle and overo. Can the original fix go in and be changed when we know which board needs special handling ?
Tom
Best Regards, J.
How about something like this ? It is all done in #define's and follows what the kernel does.
The clocks are I2C_IP_CLK I2C_INTERNAL_SAMPLING_CLK
The scll and sclh can be modifed by I2C_SCLL_TRIM I2C_SCLH_TRIM
Tom
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:02 Thu 11 Jun , Tom wrote:
Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 9:44 PM
This is a repeat story of what happened in linux-omap and kernel. We had
a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch:
a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ?
#defines in config header file might be a viable option.. Though the gd might be cleaner I think..
Regards, Nishanth Menon
How about something like this? The timing calculation is moved to a separate function that is weakly aliased to a function that the boards can define? This is similar to led initializing in lib_arm. I have put a stub omap_i2c_timing in zoom1.c to show how the board would do the define.
use weak function will increase the size of u-boot I'll prefer to avoid it when it's possible if no board mainline need it I'll prefer to avoid it also
Best Regards, J.
On 23:12 Wed 10 Jun , Menon, Nishanth wrote:
-----Original Message----- From: Tom [mailto:Tom.Rix@windriver.com] Sent: Wednesday, June 10, 2009 9:44 PM
This is a repeat story of what happened in linux-omap and kernel. We had
a similar discussion in [1] and related patch [2] to change equations. I have the same reservations with this patch:
a) using speed as default does not scale for all board combinations. b) need flexible option to provide scll and sclh on a platform basis. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=123540865900002&r=1&w=2 [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
Do you think this could be handled with just config files? Or maybe like fsl_i2c does by passing clk data through the global_data ?
#defines in config header file might be a viable option.. Though the gd might be cleaner I think..
please a config and then create a inline function like this
Best Regards, J.
participants (9)
-
Dirk Behme -
Heiko Schocher -
Jean-Christophe PLAGNIOL-VILLARD -
Menon, Nishanth -
Nishanth Menon -
Peter Tyser -
Tom -
Tom Rix
-
Wolfgang Denk