[U-Boot] [PATCH 1/2] S5P: support generic watchdog timer
This patch adds support the generic watchdog timer for s5pc1xx and exynos4
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: HeungJun, Kim riverful@samsung.com
---
arch/arm/cpu/armv7/s5p-common/Makefile |1 +
arch/arm/cpu/armv7/s5p-common/wdt.c | 59 ++
arch/arm/include/asm/arch-exynos/watchdog.h |6 ++-
arch/arm/include/asm/arch-s5pc1xx/cpu.h |1 +
arch/arm/include/asm/arch-s5pc1xx/watchdog.h | 58 +
5 files changed, 124 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/armv7/s5p-common/wdt.c
create mode 100644 arch/arm/include/asm/arch-s5pc1xx/watchdog.h
diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile
b/arch/arm/cpu/armv7/s5p-common/Makefile
index 1705399..f975f3f 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -28,6 +28,7 @@ LIB = $(obj)libs5p-common.o
COBJS-y+= cpu_info.o
COBJS-y+= timer.o
COBJS-y+= sromc.o
+COBJS-y+= wdt.o
COBJS-$(CONFIG_PWM)+= pwm.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/s5p-common/wdt.c
b/arch/arm/cpu/armv7/s5p-common/wdt.c
new file mode 100644
index 000..94acc1e
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/wdt.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Minkyu Kang mk7.k...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/watchdog.h
+
+#define PRESCALER_VAL 255
+
+void wdt_stop(void)
+{
+ struct s5p_watchdog *wdt =
+ (struct s5p_watchdog *)samsung_get_base_watchdog();
+ unsigned int wtcon;
+
+ wtcon = readl(wdt-wtcon);
+ wtcon = ~(WTCON_EN | WTCON_INT | WTCON_RESET);
+
+ writel(wtcon, wdt-wtcon);
+}
+
+void wdt_start(unsigned int timeout)
+{
+ struct s5p_watchdog *wdt =
+ (struct s5p_watchdog *)samsung_get_base_watchdog();
+ unsigned int wtcon;
+
+ wdt_stop();
+
+ wtcon = readl(wdt-wtcon);
+ wtcon |= (WTCON_EN | WTCON_CLK(WTCON_CLK_128));
+ wtcon = ~WTCON_INT;
+ wtcon |= WTCON_RESET;
+ wtcon |= WTCON_PRESCALER(PRESCALER_VAL);
+
+ writel(timeout, wdt-wtdat);
+ writel(timeout, wdt-wtcnt);
+ writel(wtcon, wdt-wtcon);
+}
diff --git a/arch/arm/include/asm/arch-exynos/watchdog.h
b/arch/arm/include/asm/arch-exynos/watchdog.h
index 3015875..ee0c9c9 100644
--- a/arch/arm/include/asm/arch-exynos/watchdog.h
+++ b/arch/arm/include/asm/arch-exynos/watchdog.h
@@ -42,12 +42,16 @@
#define WTCON_INT (0x1 WTCON_INTEN_OFFSET)
#ifndef __ASSEMBLY__
-struct exynos4_watchdog {
+struct s5p_watchdog {
unsigned int wtcon;
unsigned int wtdat;
unsigned int wtcnt;
unsigned int wtclrint;
};
+
+/* functions */
+void wdt_stop(void);
+void wdt_start(unsigned int timeout);
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
b/arch/arm/include/asm/arch-s5pc1xx/cpu.h
index e699fc4..510ead4 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/cpu.h
@@ -98,6 +98,7 @@ SAMSUNG_BASE(mmc, MMC_BASE)
SAMSUNG_BASE(sromc, SROMC_BASE)
SAMSUNG_BASE(timer, PWMTIMER_BASE)
SAMSUNG_BASE(uart, UART_BASE)
+SAMSUNG_BASE(watchdog, WATCHDOG_BASE)
#endif
#endif /* _S5PC1XX_CPU_H */
diff --git a/arch/arm/include/asm/arch-s5pc1xx/watchdog.h
b/arch/arm/include/asm/arch-s5pc1xx/watchdog.h
new file mode 100644
index 000..0f80ca5
--- /dev/null
+++ b/arch/arm/include/asm/arch-s5pc1xx/watchdog.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Heungjun Kim riverful@samsung.com
+ * Minkyu Kang mk7.k...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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
[U-Boot] [PATCH 2/2] TRATS: use the generic watchdog timer
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: HeungJun, Kim riverful@samsung.com
---
board/samsung/trats/trats.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 2925cff..f795ff0 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -310,14 +310,6 @@ static void board_clock_init(void)
writel(CLK_GATE_BLOCK_VAL, (unsigned int)clk-gate_block);
}
-static void board_watchdog_disable(void)
-{
- struct exynos4_watchdog *wd =
- (struct exynos4_watchdog *)samsung_get_base_watchdog();
-
- writel(~(WTCON_EN | WTCON_INT), (unsigned int)wd-wtcon);
-}
-
static void board_power_init(void)
{
struct exynos4_power *pwr =
@@ -368,8 +360,7 @@ static void board_uart_init(void)
int board_early_init_f(void)
{
- board_watchdog_disable();
-
+ wdt_stop();
pmic_reset();
board_clock_init();
board_uart_init();
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx6: mx6qarm2: updated board_mmc_getcd() to the new prototype
On 18/01/2012 04:08, Jason Hui wrote:
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret;
if (cfg-esdhc_base == USDHC3_BASE_ADDR) {
gpio_direction_input(171); /*GPIO6_11*/
- *cd = gpio_get_value(171);
+ ret = !gpio_get_value(171);
} else /* Don't have the CD GPIO pin on board */
- *cd = 0;
+ ret = 0;
^^1
Apparently, this is wrong for the else statement, since there is no CD
for the SD4 on the board,
so, we have to tell MMC system that the card is always there,
otherwise, we can't use the MMC
Ok - so we have to invert the logic for the else clause.
plug-in that slot. After change to new prototype, we also need convert
the ret value for the SD4,
and return 1 not 0 to MMC.
Thanks - I send V3 with the required change.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 18/01/2012 02:44, Eric Nelson wrote:
On 01/17/2012 06:27 PM, Marek Vasut wrote:
On 01/17/2012 04:19 PM, Marek Vasut wrote:
Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com
+/* ECSPI registers */
+struct cspi_regs {
+u32 rxdata;
+u32 txdata;
+u32 ctrl;
+u32 cfg;
+u32 intr;
+u32 dma;
+u32 stat;
+u32 period;
+};
Sigh ... it's no fun I can have only one remark :-)
Is this part common for all imx-es ?
All i.MX6's
This is a cut paste from MX51.
I was tempted to introduce an 'mxc_ecspi.h' to merge the declaration
for i.MX5x and i.MX6 which share the ECSPI peripheral and 'mxc_cspi.h'
for i.MX31 and i.MX35 that share the CSPI peripheral.
But you don't even need this outside of the spi driver so just put it
into the
spi driver and be done with it. That'll solve your duplication issue.
M
I'll defer to Stefano on this one, since I did this in response
to his request:
Yes, I admit I am guilty about this !
The layout of the CSPI registers is not exactly the same for all SOCs.
For example, the MXC_CSPICTRL_TC has a different position, as well as
the BITCOUNT (because the MX31 can send less bits in one shot) and
MXC_CSPICTRL_CHIPSELECT.
So they are similar, but not exactly the same.
Then we have the MX5 registers. Even if we check the CSPI (not eCSPI)
controller, the layout of the registers is different compared to the MX3
SOCs.
The struct cspi_regs is already present in mx31, mx35, and mx51 headers,
so I'm not breaking new ground here, only in the bitfield declarations.
Right, I see the same. The cspi_regs structure is already defined into
the imx_regs.h, only the bit layout was moved. And as the bit layout is
SOC dependent, I think the right place for it is inside the imx-regs.h
registers.
My interpretation of Stefano's intent is to clean up the driver at the
expense
of extra defines in the arch-specific headers.
Yes, you're right - of course, I am open also to other solutions if they
are proofed to be better ;-).
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] imx6: mx6qarm2: updated board_mmc_getcd() to the new prototype
Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has
changed board_mmc_getcd() function prototype, while
mx6qarm2 has still the old one.
Signed-off-by: Stefano Babic sba...@denx.de
CC: Jason Liu jason@linaro.org
Acked-by: Dirk Behme dirk.be...@de.bosch.com
---
Changes since V1:
- update subject (Fabio Estevam)
Changes since V2:
- board_mmc_getcd() must return 1 in the else clause (Jason Liu)
Note: not tested on real board, the patch fixes building.
board/freescale/mx6qarm2/mx6qarm2.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
b/board/freescale/mx6qarm2/mx6qarm2.c
index 9894245..1367b88 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -120,17 +120,18 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC4_BASE_ADDR, 1},
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret;
if (cfg-esdhc_base == USDHC3_BASE_ADDR) {
gpio_direction_input(171); /*GPIO6_11*/
- *cd = gpio_get_value(171);
+ ret = !gpio_get_value(171);
} else /* Don't have the CD GPIO pin on board */
- *cd = 0;
+ ret = 1;
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ARM: I2C: I2C Multi byte address support
Existing OMAP I2C driver does not support address
length greater than one. Hence this patch is to
add support for 2 byte address read/write.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes for v2:
Fixed review comments from Heiko Schocher
drivers/i2c/omap24xx_i2c.c | 468
drivers/i2c/omap24xx_i2c.h |2 +
2 files changed, 298 insertions(+), 172 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 4ae237a..8116f86 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -29,10 +29,11 @@
DECLARE_GLOBAL_DATA_PTR;
-#define I2C_TIMEOUT1000
+#define I2C_STAT_TIMEO (1 31)
+#define I2C_TIMEOUT10
-static void wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u32 wait_for_bb(void);
+static u32 wait_for_status_mask(u16 mask);
static void flush_fifo(void);
static struct i2c *i2c_base = (struct i2c *)I2C_DEFAULT_BASE;
@@ -45,7 +46,6 @@ void i2c_init(int speed, int slaveadd)
int psc, fsscll, fssclh;
int hsscll = 0, hssclh = 0;
u32 scll, sclh;
- int timeout = I2C_TIMEOUT;
/* Only handle standard, fast and high speeds */
if ((speed != OMAP_I2C_STANDARD)
@@ -107,24 +107,14 @@ void i2c_init(int speed, int slaveadd)
sclh = (unsigned int)fssclh;
}
+ if (gd-flags GD_FLG_RELOC)
+ bus_initialized[current_bus] = 1;
+
if (readw(i2c_base-con) I2C_CON_EN) {
writew(0, i2c_base-con);
udelay(5);
}
- writew(0x2, i2c_base-sysc); /* for ES2 after soft reset */
- udelay(1000);
-
- writew(I2C_CON_EN, i2c_base-con);
- while (!(readw(i2c_base-syss) I2C_SYSS_RDONE) timeout--) {
- if (timeout = 0) {
- printf(ERROR: Timeout in soft-reset\n);
- return;
- }
- udelay(1000);
- }
-
- writew(0, i2c_base-con);
writew(psc, i2c_base-psc);
writew(scll, i2c_base-scll);
writew(sclh, i2c_base-sclh);
@@ -140,81 +130,6 @@ void i2c_init(int speed, int slaveadd)
flush_fifo();
writew(0x, i2c_base-stat);
writew(0, i2c_base-cnt);
-
- if (gd-flags GD_FLG_RELOC)
- bus_initialized[current_bus] = 1;
-}
-
-static int i2c_read_byte(u8 devaddr, u8 regoffset, u8 *value)
-{
- int i2c_error = 0;
- u16 status;
-
- /* wait until bus not busy */
- wait_for_bb();
-
- /* one byte only */
- writew(1, i2c_base-cnt);
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* no stop bit needed here */
- writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, i2c_base-con);
-
- /* send register offset */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_XRDY) {
- /* Important: have to use byte access */
- writeb(regoffset, i2c_base-data);
- writew(I2C_STAT_XRDY, i2c_base-stat);
- }
- if (status I2C_STAT_ARDY) {
- writew(I2C_STAT_ARDY, i2c_base-stat);
- break;
- }
- }
-
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* read one byte from slave */
- writew(1, i2c_base-cnt);
- /* need stop bit here */
- writew(I2C_CON_EN | I2C_CON_MST |
- I2C_CON_STT | I2C_CON_STP,
- i2c_base-con);
-
- /* receive data */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_RRDY) {
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
- defined(CONFIG_OMAP44XX)
- *value = readb(i2c_base-data);
-#else
- *value = readw(i2c_base-data);
-#endif
- writew(I2C_STAT_RRDY, i2c_base-stat);
- }
- if (status I2C_STAT_ARDY) {
- writew(I2C_STAT_ARDY, i2c_base-stat);
- break;
- }
- }
-
-read_exit:
- flush_fifo();
- writew(0x, i2c_base-stat);
- writew(0, i2c_base-cnt);
- return i2c_error;
}
static void flush_fifo(void)
@@ -241,32 +156,42 @@ static void flush_fifo(void)
int i2c_probe(uchar chip)
{
- u16 status;
+ u32 status;
int res = 1; /* default = fail */
if (chip ==
[U-Boot] [PATCH v2 2/3] ARM: AM33XX: Add AM33XX I2C driver support
1. Compliant with Philips I2C specification version 2.1
2. Supports upto 100Kbps in standard mode.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes for v2:
No change
drivers/i2c/omap24xx_i2c.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 8116f86..995a727 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -142,7 +142,7 @@ static void flush_fifo(void)
stat = readw(i2c_base-stat);
if (stat == I2C_STAT_RRDY) {
#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
- defined(CONFIG_OMAP44XX)
+ defined(CONFIG_OMAP44XX) || defined(CONFIG_AM33XX)
readb(i2c_base-data);
#else
readw(i2c_base-data);
@@ -243,7 +243,8 @@ int i2c_read(uchar chip, uint addr, int alen, uchar
*buffer, int len)
switch (alen) {
case 2:
/* Send address MSByte */
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+ defined(CONFIG_AM33XX)
writew(((addr 8) 0xFF), i2c_base-data);
/* Clearing XRDY event */
@@ -260,7 +261,8 @@ int i2c_read(uchar chip, uint addr, int alen, uchar
*buffer, int len)
}
#endif
case 1:
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+ defined(CONFIG_AM33XX)
/* Send address LSByte */
writew((addr 0xFF), i2c_base-data);
#else
@@ -310,7 +312,8 @@ int i2c_read(uchar chip, uint addr, int alen, uchar
*buffer, int len)
}
if (status I2C_STAT_RRDY) {
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+ defined(CONFIG_AM33XX)
buffer[i] = readb(i2c_base-data);
#else
*((u16 *)buffer[i]) =
@@ -397,7 +400,8 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
if (!i2c_error) {
if (status I2C_STAT_XRDY) {
switch (alen) {
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+ defined(CONFIG_AM33XX)
case 2:
/* send out MSB byte */
writeb(((addr 8) 0xFF), i2c_base-data);
@@ -417,7 +421,8 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
break;
}
case 1:
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+ defined(CONFIG_AM33XX)
/* send out MSB byte */
writeb((addr 0xFF), i2c_base-data);
#else
@@ -439,7 +444,8 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
if (!i2c_error) {
for (i = ((alen 1) ? 0 : 1); i len; i++) {
if (status I2C_STAT_XRDY) {
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+ defined(CONFIG_AM33XX)
writeb((buffer[i] 0xFF),
i2c_base-data);
#else
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] ARM: AM33XX: Add i2c support
Add i2c driver board hookup for AM335X EVM.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes for v2:
Fixed review comments from Chandan
arch/arm/cpu/armv7/am33xx/clock.c |5 ++
arch/arm/include/asm/arch-am33xx/common_def.h |1 +
arch/arm/include/asm/arch-am33xx/cpu.h|3 +-
arch/arm/include/asm/arch-am33xx/i2c.h| 81 +
board/ti/am335x/evm.c |7 ++
board/ti/am335x/mux.c | 13
include/configs/am335x_evm.h |9 +++
7 files changed, 118 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/include/asm/arch-am33xx/i2c.h
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 98cfd93..bbb9c13 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -113,6 +113,11 @@ static void enable_per_clocks(void)
writel(PRCM_MOD_EN, cmper-mmc0clkctrl);
while (readl(cmper-mmc0clkctrl) != PRCM_MOD_EN)
;
+
+ /* i2c0 */
+ writel(PRCM_MOD_EN, cmwkup-wkup_i2c0ctrl);
+ while (readl(cmwkup-wkup_i2c0ctrl) != PRCM_MOD_EN)
+ ;
}
static void mpu_pll_config(void)
diff --git a/arch/arm/include/asm/arch-am33xx/common_def.h
b/arch/arm/include/asm/arch-am33xx/common_def.h
index 767932d..aa3b554 100644
--- a/arch/arm/include/asm/arch-am33xx/common_def.h
+++ b/arch/arm/include/asm/arch-am33xx/common_def.h
@@ -18,5 +18,6 @@
extern void enable_uart0_pin_mux(void);
extern void enable_mmc0_pin_mux(void);
+extern void enable_i2c0_pin_mux(void);
#endif/*__COMMON_DEF_H__ */
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 25558a2..cd002e6 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -95,7 +95,8 @@ struct cm_wkuppll {
unsigned int divm2dpllper; /* offset 0xAC */
unsigned int resv11[1];
unsigned int wkup_uart0ctrl;/* offset 0xB4 */
- unsigned int resv12[8];
+ unsigned int wkup_i2c0ctrl; /* offset 0xB8 */
+ unsigned int resv12[7];
unsigned int divm6dpllcore; /* offset 0xD8 */
};
diff --git a/arch/arm/include/asm/arch-am33xx/i2c.h
b/arch/arm/include/asm/arch-am33xx/i2c.h
new file mode 100644
index 000..366e2bb
--- /dev/null
+++ b/arch/arm/include/asm/arch-am33xx/i2c.h
@@ -0,0 +1,81 @@
+/*
+ * (C) Copyright 2012
+ * Texas Instruments, www.ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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
+ */
+#ifndef _I2C_H_
+#define _I2C_H_
+
+#define I2C_BASE1 0x44E0B000
+#define I2C_BASE2 0x4802A000
+#define I2C_BASE3 0x4819C000
+#define I2C_BUS_MAX3
+
+#define I2C_DEFAULT_BASE I2C_BASE1
+
+struct i2c {
+ unsigned short revnb_lo;/* 0x00 */
+ unsigned short res1;
+ unsigned short revnb_hi;/* 0x04 */
+ unsigned short res2[13];
+ unsigned short sysc;/* 0x20 */
+ unsigned short res3;
+ unsigned short irqstatus_raw; /* 0x24 */
+ unsigned short res4;
+ unsigned short stat;/* 0x28 */
+ unsigned short res5;
+ unsigned short ie; /* 0x2C */
+ unsigned short res6;
+ unsigned short irqenable_clr; /* 0x30 */
+ unsigned short res7;
+ unsigned short iv; /* 0x34 */
+ unsigned short res8[45];
+ unsigned short syss;/* 0x90 */
+ unsigned short res9;
+ unsigned short buf; /* 0x94 */
+ unsigned short res10;
+ unsigned short cnt; /* 0x98 */
+ unsigned short res11;
+ unsigned short data;/* 0x9C */
+ unsigned short res13;
+ unsigned short res14; /* 0xA0 */
+ unsigned short res15;
+ unsigned short con; /* 0xA4 */
+ unsigned short res16;
+ unsigned short oa; /* 0xA8 */
+ unsigned short res17;
+ unsigned short sa; /* 0xAC */
+ unsigned short res18;
+ unsigned short psc; /*
Re: [U-Boot] [PATCH V3] imx6: mx6qarm2: updated board_mmc_getcd() to the new prototype
On Wed, Jan 18, 2012 at 5:41 PM, Stefano Babic sba...@denx.de wrote:
Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has
changed board_mmc_getcd() function prototype, while
mx6qarm2 has still the old one.
Signed-off-by: Stefano Babic sba...@denx.de
CC: Jason Liu jason@linaro.org
Acked-by: Dirk Behme dirk.be...@de.bosch.com
Acked-by: Jason Liu jason@linaro.org
---
Changes since V1:
- update subject (Fabio Estevam)
Changes since V2:
- board_mmc_getcd() must return 1 in the else clause (Jason Liu)
Note: not tested on real board, the patch fixes building.
I have tested it on the real board, it works fine:)
Tested-by: Jason Liu jason@linaro.org
board/freescale/mx6qarm2/mx6qarm2.c | 9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
b/board/freescale/mx6qarm2/mx6qarm2.c
index 9894245..1367b88 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -120,17 +120,18 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC4_BASE_ADDR, 1},
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret;
if (cfg-esdhc_base == USDHC3_BASE_ADDR) {
gpio_direction_input(171); /*GPIO6_11*/
- *cd = gpio_get_value(171);
+ ret = !gpio_get_value(171);
} else /* Don't have the CD GPIO pin on board */
- *cd = 0;
+ ret = 1;
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/2] mc13783.h: create and add regulator mode 0 and 1
Add bit definitions for register 32 and 33 of Freescale MC13783. Signed-off-by: Helmut Raiger helmut.rai...@hale.at --- V3: moved change from fsl_pmic.h to mc13783.h (mc13892 differs!) V2: pmic_reg_(read|write) use constants from fsl_pmic.h now include/mc13783.h | 80 + 1 files changed, 80 insertions(+), 0 deletions(-) create mode 100644 include/mc13783.h diff --git a/include/mc13783.h b/include/mc13783.h new file mode 100644 index 000..5e41c3e --- /dev/null +++ b/include/mc13783.h @@ -0,0 +1,80 @@ +/* + * (C) Copyright 2011 + * Helmut Raiger, HALE electronic GmbH, helmut.rai...@hale.at + * + * See file CREDITS for list of people who contributed to this + * project. + * + * 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 + */ + + +#ifndef __MC13783_H__ +#define __MC13783_H__ + +/* REG_MODE_0 */ +#define VAUDIOEN (1 0) +#define VAUDIOSTBY (1 1) +#define VAUDIOMODE (1 2) +#define VIOHIEN(1 3) +#define VIOHISTBY (1 4) +#define VIOHIMODE (1 5) +#define VIOLOEN(1 6) +#define VIOLOSTBY (1 7) +#define VIOLOMODE (1 8) +#define VDIGEN (1 9) +#define VDIGSTBY (1 10) +#define VDIGMODE (1 11) +#define VGENEN (1 12) +#define VGENSTBY (1 13) +#define VGENMODE (1 14) +#define VRFDIGEN (1 15) +#define VRFDIGSTBY (1 16) +#define VRFDIGMODE (1 17) +#define VRFREFEN (1 18) +#define VRFREFSTBY (1 19) +#define VRFREFMODE (1 20) +#define VRFCPEN(1 21) +#define VRFCPSTBY (1 22) +#define VRFCPMODE (1 23) + +/* REG_MODE_1 */ +#define VSIMEN (1 0) +#define VSIMSTBY (1 1) +#define VSIMMODE (1 2) +#define VESIMEN(1 3) +#define VESIMSTBY (1 4) +#define VESIMMODE (1 5) +#define VCAMEN (1 6) +#define VCAMSTBY (1 7) +#define VCAMMODE (1 8) +#define VRFBGEN(1 9) +#define VRFBGSTBY (1 10) +#define VVIBEN (1 11) +#define VRF1EN (1 12) +#define VRF1STBY (1 13) +#define VRF1MODE (1 14) +#define VRF2EN (1 15) +#define VRF2STBY (1 16) +#define VRF2MODE (1 17) +#define VMMC1EN(1 18) +#define VMMC1STBY (1 19) +#define VMMC1MODE (1 20) +#define VMMC2EN(1 21) +#define VMMC2STBY (1 22) +#define VMMC2MODE (1 23) + +#endif -- 1.7.4.4 -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/2] tt01: add MMC support
board_mmc_init() initializes the pins of SDHC1 and
turns on V_MMC1 of the PMIC. Config adds support for EXT2
and FAT.
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
V3: moved change from fsl_pmic.h to mc13783.h (mc13892 differs!)
V2: pmic_reg_(read|write) use constants from fsl_pmic.h now
board/hale/tt01/tt01.c | 55 ++-
include/configs/tt01.h | 12 ++
2 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/board/hale/tt01/tt01.c b/board/hale/tt01/tt01.c
index 2995c8f..bcbe5ec 100644
--- a/board/hale/tt01/tt01.c
+++ b/board/hale/tt01/tt01.c
@@ -26,6 +26,8 @@
#include netdev.h
#include command.h
#include pmic.h
+#include fsl_pmic.h
+#include mc13783.h
#include asm/arch/clock.h
#include asm/arch/sys_proto.h
#include asm/io.h
@@ -175,8 +177,6 @@ int board_init(void)
int board_late_init(void)
{
- pmic_init();
-
#ifdef CONFIG_HW_WATCHDOG
mxc_hw_watchdog_enable();
#endif
@@ -190,6 +190,36 @@ int checkboard(void)
return 0;
}
+#ifdef CONFIG_MXC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ u32 val;
+ struct pmic *p;
+
+ /*
+ * this is the first driver to use the pmic, so call
+ * pmic_init() here. board_late_init() is too late for
+ * the MMC driver.
+ */
+ pmic_init();
+ p = get_pmic();
+
+ /* configure pins for SDHC1 only */
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_CLK, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_CMD, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA0, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA1, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA2, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA3, MUX_CTL_FUNC));
+
+ /* turn on power V_MMC1 */
+ if (pmic_reg_read(p, REG_MODE_1, val) 0)
+ pmic_reg_write(p, REG_MODE_1, val | VMMC1EN);
+
+ return mxc_mmc_init(bis);
+}
+#endif
+
int board_eth_init(bd_t *bis)
{
int rc = 0;
@@ -198,3 +228,24 @@ int board_eth_init(bd_t *bis)
#endif
return rc;
}
+
+#ifdef CONFIG_CONSOLE_EXTRA_INFO
+void video_get_info_str(int line_number, char *info)
+{
+ u32 srev = get_cpu_rev();
+
+ switch (line_number) {
+ case 2:
+ sprintf(info, CPU : Freescale i.MX31 rev %d.%d%s at %d MHz,
+ (srev 0xF0) 4, (srev 0x0F),
+ ((srev 0x8000) ? unknown : ),
+ mxc_get_clock(MXC_ARM_CLK) / 100);
+ break;
+ case 3:
+ strcpy(info, BOARD_STRING);
+ break;
+ default:
+ info[0] = 0;
+ }
+}
+#endif
diff --git a/include/configs/tt01.h b/include/configs/tt01.h
index a553712..6846816 100644
--- a/include/configs/tt01.h
+++ b/include/configs/tt01.h
@@ -180,6 +180,11 @@
#define CONFIG_SMC911X_BASE(CS4_BASE+0x20)
#define CONFIG_SMC911X_16_BIT
+/* mmc driver */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MXC_MMC
+#define CONFIG_MXC_MCI_REGS_BASE SDHC1_BASE_ADDR
/*
* Command definition
*/
@@ -229,6 +234,13 @@
#define CONFIG_CMDLINE_EDITING
+/* MMC boot support */
+#define CONFIG_CMD_MMC
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+
#define CONFIG_NAND_MXC
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_MAX_CHIPS 1
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mx28evk: add SPI support
This patch adds SPI support for the MX28EVK. Support for
an optionally installed SPI flash is also added. An example
configuration for redundant envrionment from SPI flash is also
added but disabled by default.
This patch has been tested on a MX28EVK Rev. D with an installed
SST25VF032B 32Mbit SPI flash.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
board/freescale/mx28evk/iomux.c |8 +++
include/configs/mx28evk.h | 44 --
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/board/freescale/mx28evk/iomux.c b/board/freescale/mx28evk/iomux.c
index 904e3f3..396761b 100644
--- a/board/freescale/mx28evk/iomux.c
+++ b/board/freescale/mx28evk/iomux.c
@@ -28,6 +28,7 @@
#defineMUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+#defineMUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -130,6 +131,13 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_EMI_CE0N__EMI_CE0N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CE1N__EMI_CE1N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CKE__EMI_CKE | MUX_CONFIG_EMI,
+
+ /* SPI2 (for SPI flash) */
+ MX28_PAD_SSP2_SCK__SSP2_SCK | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_MOSI__SSP2_CMD | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_MISO__SSP2_D0 | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_SS0__SSP2_D3 |
+ (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP),
};
void board_init_ll(void)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 8f791aa..04967d7 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -64,6 +64,8 @@
#define CONFIG_CMD_NET
#define CONFIG_CMD_NFS
#define CONFIG_CMD_PING
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
#define CONFIG_CMD_USB
/*
@@ -127,9 +129,11 @@
* MMC Driver
*/
#define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET (256 * 1024)
-#define CONFIG_ENV_SIZE(16 * 1024)
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#ifdef CONFIG_ENV_IS_IN_MMC
+ #define CONFIG_ENV_OFFSET (256 * 1024)
+ #define CONFIG_ENV_SIZE (16 * 1024)
+ #define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
#define CONFIG_CMD_SAVEENV
#ifdef CONFIG_CMD_MMC
#define CONFIG_MMC
@@ -170,6 +174,40 @@
#endif
/*
+ * SPI
+ */
+#ifdef CONFIG_CMD_SPI
+#define CONFIG_HARD_SPI
+#define CONFIG_MXS_SPI
+#define CONFIG_SPI_HALF_DUPLEX
+#define CONFIG_DEFAULT_SPI_BUS 2
+#define CONFIG_DEFAULT_SPI_MODESPI_MODE_0
+
+/* SPI Flash */
+#ifdef CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+/* this may vary and depends on the installed chip */
+#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+#define CONFIG_SF_DEFAULT_SPEED2400
+
+/* (redundant) environemnt in SPI flash */
+#undef CONFIG_ENV_IS_IN_SPI_FLASH
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#define CONFIG_ENV_SIZE0x1000 /* 4KB */
+#define CONFIG_ENV_OFFSET 0x4 /* 256K */
+#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#define CONFIG_ENV_SECT_SIZE 0x1000
+#define CONFIG_ENV_SPI_CS 0
+#define CONFIG_ENV_SPI_BUS 2
+#define CONFIG_ENV_SPI_MAX_HZ 2400
+#define CONFIG_ENV_SPI_MODESPI_MODE_0
+#endif
+#endif
+#endif
+
+/*
* Boot Linux
*/
#define CONFIG_CMDLINE_TAG
--
1.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx28evk: add USB support
This patch enables USB host support on the MX28EVK board. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- board/freescale/mx28evk/mx28evk.c |7 +++ include/configs/mx28evk.h | 12 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/board/freescale/mx28evk/mx28evk.c b/board/freescale/mx28evk/mx28evk.c index 0d04d44..1bc83e9 100644 --- a/board/freescale/mx28evk/mx28evk.c +++ b/board/freescale/mx28evk/mx28evk.c @@ -52,6 +52,13 @@ int board_early_init_f(void) /* SSP2 clock at 96MHz */ mx28_set_sspclk(MXC_SSPCLK2, 96000, 0); +#ifdef CONFIG_CMD_USB + mxs_iomux_setup_pad(MX28_PAD_SSP2_SS1__USB1_OVERCURRENT); + mxs_iomux_setup_pad(MX28_PAD_AUART2_RX__GPIO_3_8 | + MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL); + gpio_direction_output(MX28_PAD_AUART2_RX__GPIO_3_8, 1); +#endif + return 0; } diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 8a752aa..8f791aa 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -64,6 +64,7 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_NFS #define CONFIG_CMD_PING +#define CONFIG_CMD_USB /* * Memory configurations @@ -158,6 +159,17 @@ #endif /* + * USB + */ +#ifdef CONFIG_CMD_USB +#defineCONFIG_USB_EHCI +#defineCONFIG_USB_EHCI_MXS +#defineCONFIG_EHCI_MXS_PORT 1 +#defineCONFIG_EHCI_IS_TDI +#defineCONFIG_USB_STORAGE +#endif + +/* * Boot Linux */ #define CONFIG_CMDLINE_TAG -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mx28evk: add RTC support
This patch adds support for the MX28 internal RTC and enables u-boot's date command. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- include/configs/mx28evk.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index bea46e7..8a752aa 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -56,6 +56,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_CACHE +#define CONFIG_CMD_DATE #define CONFIG_CMD_DHCP #define CONFIG_CMD_GPIO #define CONFIG_CMD_MII @@ -150,6 +151,13 @@ #endif /* + * RTC + */ +#ifdef CONFIG_CMD_DATE +#defineCONFIG_RTC_MXS +#endif + +/* * Boot Linux */ #define CONFIG_CMDLINE_TAG -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/RFC] mx28: print bootmode with cpuinfo
Hi,
while playing around with the mx28evk and differnet bootmedia
I found it helpful to see the current bootmode without
running to the board and checking it's switches. Also
some other CPU (e.g. 440 PowerPCs) print some kind of bootstrap
configuration during startup.
The patch probably needs some little cleanup. But the main issue might
be the way how it passes the information from SPL to 2nd stage.
I am note sure if those scratch registers are somehow holy :-)
BTW, I still did not figure out why current mx28evk u-boot
cannot be bootet via USB download while MMC and SPI are working ...
Matthias
So here comes V1:
This patch add support for printing the currently selected bootmode
within print_cpuinfo() for MX28 boards.
The bootmode is read from the CPU's strapping balls before they are
setup for thier later function (e.g. become an output or are
used by the LCD controller).
Reading the pins is done from SPL stage and the information is passed
in the SCRATCH1+2 registers together with the memory size.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
arch/arm/cpu/arm926ejs/mx28/mx28.c | 43 +--
arch/arm/cpu/arm926ejs/mx28/spl_boot.c |7
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |4 +-
3 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index da90360..15a7c5b 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -43,6 +43,9 @@ DECLARE_GLOBAL_DATA_PTR;
#defineMX28_BLOCK_SFTRST (1 31)
#defineMX28_BLOCK_CLKGATE (1 30)
+#defineHW_DIGCTRL_SCRATCH0 0x8001c280
+#defineHW_DIGCTRL_SCRATCH1 0x8001c290
+
/* Lowlevel init isn't used on i.MX28, so just have a dummy here */
inline void lowlevel_init(void) {}
@@ -169,7 +172,41 @@ int arch_cpu_init(void)
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
- printf(Freescale i.MX28 family\n);
+ uint32_t bm = readl(HW_DIGCTRL_SCRATCH0) 0xf;
+ char *bm_s;
+
+ switch (bm 0xf) {
+ case 0x0:
+ bm_s = USB;
+ break;
+ case 0x1:
+ bm_s = I2C0;
+ break;
+ case 0x2:
+ bm_s = SPI2/flash;
+ break;
+ case 0x3:
+ bm_s = SPI3/flash;
+ break;
+ case 0x4:
+ bm_s = NAND;
+ break;
+ case 0x8:
+ bm_s = SPI3/eeprom;
+ break;
+ case 0x9:
+ bm_s = SSP0/MMC;
+ break;
+ case 0xa:
+ bm_s = SSP1/MMC;
+ break;
+ case 0xf:
+ bm_s = Test;
+ break;
+ default:
+ bm_s = Unknown;
+ }
+ printf(Freescale i.MX28 family (bootmode:%s)\n, bm_s);
return 0;
}
#endif
@@ -260,8 +297,6 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
}
#endif
-#defineHW_DIGCTRL_SCRATCH0 0x8001c280
-#defineHW_DIGCTRL_SCRATCH1 0x8001c290
int mx28_dram_init(void)
{
uint32_t sz[2];
@@ -277,7 +312,7 @@ int mx28_dram_init(void)
hang();
}
- gd-ram_size = sz[0];
+ gd-ram_size = sz[0] ~0xf;
return 0;
}
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
index dfb8309..edb8ff7 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
@@ -46,9 +46,16 @@ void early_delay(int delay)
;
}
+#defineHW_DIGCTRL_SCRATCH0 0x8001c280
+#defineHW_DIGCTRL_SCRATCH1 0x8001c290
+
void mx28_common_spl_init(const iomux_cfg_t *iomux_setup,
const unsigned int iomux_size)
{
+ uint32_t bm = readl(0x80018910) 0xf;
+ writel(bm, HW_DIGCTRL_SCRATCH0);
+ writel(bm, HW_DIGCTRL_SCRATCH1);
+
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
mx28_power_init();
mx28_mem_init();
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 00493b8..15f094e 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -183,8 +183,8 @@ void mx28_mem_get_size(void)
vt[4] = (uint32_t)data_abort_memdetect_handler;
sz = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
- writel(sz, HW_DIGCTRL_SCRATCH0);
- writel(sz, HW_DIGCTRL_SCRATCH1);
+ writel(sz | readl(HW_DIGCTRL_SCRATCH0), HW_DIGCTRL_SCRATCH0);
+ writel(sz | readl(HW_DIGCTRL_SCRATCH1), HW_DIGCTRL_SCRATCH1);
/* Restore the old DABT handler. */
vt[4] = da;
--
1.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/RFC] mx28: print bootmode with cpuinfo
Hi,
while playing around with the mx28evk and differnet bootmedia
I found it helpful to see the current bootmode without
running to the board and checking it's switches. Also
some other CPU (e.g. 440 PowerPCs) print some kind of bootstrap
configuration during startup.
The patch probably needs some little cleanup. But the main issue might
be the way how it passes the information from SPL to 2nd stage.
I am note sure if those scratch registers are somehow holy :-)
BTW, I still did not figure out why current mx28evk u-boot
cannot be bootet via USB download while MMC and SPI are working ...
Matthias
So here comes V1:
This patch add support for printing the currently selected bootmode
within print_cpuinfo() for MX28 boards.
The bootmode is read from the CPU's strapping balls before they are
setup for thier later function (e.g. become an output or are
used by the LCD controller).
Reading the pins is done from SPL stage and the information is passed
in the SCRATCH1+2 registers together with the memory size.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
arch/arm/cpu/arm926ejs/mx28/mx28.c | 43 +--
arch/arm/cpu/arm926ejs/mx28/spl_boot.c |7
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |4 +-
3 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index da90360..15a7c5b 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -43,6 +43,9 @@ DECLARE_GLOBAL_DATA_PTR;
#defineMX28_BLOCK_SFTRST (1 31)
#defineMX28_BLOCK_CLKGATE (1 30)
+#defineHW_DIGCTRL_SCRATCH0 0x8001c280
+#defineHW_DIGCTRL_SCRATCH1 0x8001c290
+
/* Lowlevel init isn't used on i.MX28, so just have a dummy here */
inline void lowlevel_init(void) {}
@@ -169,7 +172,41 @@ int arch_cpu_init(void)
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
- printf(Freescale i.MX28 family\n);
+ uint32_t bm = readl(HW_DIGCTRL_SCRATCH0) 0xf;
+ char *bm_s;
+
+ switch (bm 0xf) {
+ case 0x0:
+ bm_s = USB;
+ break;
+ case 0x1:
+ bm_s = I2C0;
+ break;
+ case 0x2:
+ bm_s = SPI2/flash;
+ break;
+ case 0x3:
+ bm_s = SPI3/flash;
+ break;
+ case 0x4:
+ bm_s = NAND;
+ break;
+ case 0x8:
+ bm_s = SPI3/eeprom;
+ break;
+ case 0x9:
+ bm_s = SSP0/MMC;
+ break;
+ case 0xa:
+ bm_s = SSP1/MMC;
+ break;
+ case 0xf:
+ bm_s = Test;
+ break;
+ default:
+ bm_s = Unknown;
+ }
+ printf(Freescale i.MX28 family (bootmode:%s)\n, bm_s);
return 0;
}
#endif
@@ -260,8 +297,6 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
}
#endif
-#defineHW_DIGCTRL_SCRATCH0 0x8001c280
-#defineHW_DIGCTRL_SCRATCH1 0x8001c290
int mx28_dram_init(void)
{
uint32_t sz[2];
@@ -277,7 +312,7 @@ int mx28_dram_init(void)
hang();
}
- gd-ram_size = sz[0];
+ gd-ram_size = sz[0] ~0xf;
return 0;
}
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
index dfb8309..edb8ff7 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c
@@ -46,9 +46,16 @@ void early_delay(int delay)
;
}
+#defineHW_DIGCTRL_SCRATCH0 0x8001c280
+#defineHW_DIGCTRL_SCRATCH1 0x8001c290
+
void mx28_common_spl_init(const iomux_cfg_t *iomux_setup,
const unsigned int iomux_size)
{
+ uint32_t bm = readl(0x80018910) 0xf;
+ writel(bm, HW_DIGCTRL_SCRATCH0);
+ writel(bm, HW_DIGCTRL_SCRATCH1);
+
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
mx28_power_init();
mx28_mem_init();
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 00493b8..15f094e 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -183,8 +183,8 @@ void mx28_mem_get_size(void)
vt[4] = (uint32_t)data_abort_memdetect_handler;
sz = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
- writel(sz, HW_DIGCTRL_SCRATCH0);
- writel(sz, HW_DIGCTRL_SCRATCH1);
+ writel(sz | readl(HW_DIGCTRL_SCRATCH0), HW_DIGCTRL_SCRATCH0);
+ writel(sz | readl(HW_DIGCTRL_SCRATCH1), HW_DIGCTRL_SCRATCH1);
/* Restore the old DABT handler. */
vt[4] = da;
--
1.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mxc_spi refactoring (for mx6q)
On 17.01.2012 23:09, Eric Nelson wrote: This patch set refactors mxc_spi as described in http://lists.denx.de/pipermail/u-boot/2010-March/068791.html and requested in http://lists.denx.de/pipermail/u-boot/2012-January/116023.html in order to add support for the MX6Q in general and the mx6qsabrelite specifically. Whole patch series Acked-by: Dirk Behme dirk.be...@de.bosch.com Many thanks! Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] tt01: add MMC support
On 18/01/2012 11:41, Helmut Raiger wrote:
board_mmc_init() initializes the pins of SDHC1 and
turns on V_MMC1 of the PMIC. Config adds support for EXT2
and FAT.
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
Hi Helmut,
+#ifdef CONFIG_CONSOLE_EXTRA_INFO
+void video_get_info_str(int line_number, char *info)
This has nothing with MCC. Please extend your commit message to explain
you are also adding this feature.
+{
+ u32 srev = get_cpu_rev();
+
+ switch (line_number) {
+ case 2:
+ sprintf(info, CPU : Freescale i.MX31 rev %d.%d%s at %d MHz,
+ (srev 0xF0) 4, (srev 0x0F),
+ ((srev 0x8000) ? unknown : ),
+ mxc_get_clock(MXC_ARM_CLK) / 100);
I know it is only one line, but it is not related to your board because
it is really print_cpuinfo() into a buffer. So this cpu part should be
moved into the SOC place (arch/arm/cpu/arm1136/mx31/generic.c).
However, which is the real reason to do that ? I have supposed that
setting video as stdout it is enough to redirect all output to the LCD,
and then the usual print_cpuinfo() works, without adding / duplicating
function that already use printf() for the output.
I do not see a lot of boards implementing video_get_info_str(), and I
understand that it is a way to customize the output. However, is it the
correct way ? Does print_cpuinfo() not work if redirect to the video ? I
have added Anatolji (video maintainer in CC) to get his opinion.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mx28evk: add SPI support
This patch adds SPI support for the MX28EVK. Support for
an optionally installed SPI flash is also added. An example
configuration for redundant envrionment from SPI flash is also
added but disabled by default.
This patch has been tested on a MX28EVK Rev. D with an installed
SST25VF032B 32Mbit SPI flash.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
board/freescale/mx28evk/iomux.c |8 +++
include/configs/mx28evk.h | 44
-- 2 files changed, 49 insertions(+),
3 deletions(-)
diff --git a/board/freescale/mx28evk/iomux.c
b/board/freescale/mx28evk/iomux.c index 904e3f3..396761b 100644
--- a/board/freescale/mx28evk/iomux.c
+++ b/board/freescale/mx28evk/iomux.c
@@ -28,6 +28,7 @@
#define MUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#define MUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+#define MUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -130,6 +131,13 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_EMI_CE0N__EMI_CE0N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CE1N__EMI_CE1N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CKE__EMI_CKE | MUX_CONFIG_EMI,
+
+ /* SPI2 (for SPI flash) */
+ MX28_PAD_SSP2_SCK__SSP2_SCK | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_MOSI__SSP2_CMD | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_MISO__SSP2_D0 | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_SS0__SSP2_D3 |
+ (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP),
};
void board_init_ll(void)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 8f791aa..04967d7 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -64,6 +64,8 @@
#define CONFIG_CMD_NET
#define CONFIG_CMD_NFS
#define CONFIG_CMD_PING
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
#define CONFIG_CMD_USB
/*
@@ -127,9 +129,11 @@
* MMC Driver
*/
#define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET(256 * 1024)
-#define CONFIG_ENV_SIZE (16 * 1024)
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#ifdef CONFIG_ENV_IS_IN_MMC
+ #define CONFIG_ENV_OFFSET (256 * 1024)
+ #define CONFIG_ENV_SIZE (16 * 1024)
+ #define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
#define CONFIG_CMD_SAVEENV
#ifdef CONFIG_CMD_MMC
#define CONFIG_MMC
@@ -170,6 +174,40 @@
#endif
/*
+ * SPI
+ */
+#ifdef CONFIG_CMD_SPI
+#define CONFIG_HARD_SPI
+#define CONFIG_MXS_SPI
+#define CONFIG_SPI_HALF_DUPLEX
+#define CONFIG_DEFAULT_SPI_BUS 2
+#define CONFIG_DEFAULT_SPI_MODE SPI_MODE_0
+
+/* SPI Flash */
+#ifdef CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+/* this may vary and depends on the installed chip */
+#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+#define CONFIG_SF_DEFAULT_SPEED 2400
+
+/* (redundant) environemnt in SPI flash */
+#undef CONFIG_ENV_IS_IN_SPI_FLASH
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#define CONFIG_ENV_SIZE 0x1000 /* 4KB */
+#define CONFIG_ENV_OFFSET0x4 /* 256K */
+#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#define CONFIG_ENV_SECT_SIZE 0x1000
+#define CONFIG_ENV_SPI_CS0
+#define CONFIG_ENV_SPI_BUS 2
+#define CONFIG_ENV_SPI_MAX_HZ2400
+#define CONFIG_ENV_SPI_MODE SPI_MODE_0
+#endif
+#endif
+#endif
+
+/*
* Boot Linux
*/
#define CONFIG_CMDLINE_TAG
Hm, good ... so the SPI flash works now with no modifications ?
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 18/01/2012 02:44, Eric Nelson wrote:
On 01/17/2012 06:27 PM, Marek Vasut wrote:
On 01/17/2012 04:19 PM, Marek Vasut wrote:
Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com
+/* ECSPI registers */
+struct cspi_regs {
+u32 rxdata;
+u32 txdata;
+u32 ctrl;
+u32 cfg;
+u32 intr;
+u32 dma;
+u32 stat;
+u32 period;
+};
Sigh ... it's no fun I can have only one remark :-)
Is this part common for all imx-es ?
All i.MX6's
This is a cut paste from MX51.
I was tempted to introduce an 'mxc_ecspi.h' to merge the declaration
for i.MX5x and i.MX6 which share the ECSPI peripheral and 'mxc_cspi.h'
for i.MX31 and i.MX35 that share the CSPI peripheral.
But you don't even need this outside of the spi driver so just put it
into the
spi driver and be done with it. That'll solve your duplication issue.
M
I'll defer to Stefano on this one, since I did this in response
to his request:
Yes, I admit I am guilty about this !
The layout of the CSPI registers is not exactly the same for all SOCs.
For example, the MXC_CSPICTRL_TC has a different position, as well as
the BITCOUNT (because the MX31 can send less bits in one shot) and
MXC_CSPICTRL_CHIPSELECT.
So they are similar, but not exactly the same.
Then we have the MX5 registers. Even if we check the CSPI (not eCSPI)
controller, the layout of the registers is different compared to the MX3
SOCs.
The struct cspi_regs is already present in mx31, mx35, and mx51 headers,
so I'm not breaking new ground here, only in the bitfield declarations.
Right, I see the same. The cspi_regs structure is already defined into
the imx_regs.h, only the bit layout was moved. And as the bit layout is
SOC dependent, I think the right place for it is inside the imx-regs.h
registers.
My interpretation of Stefano's intent is to clean up the driver at the
expense
of extra defines in the arch-specific headers.
Yes, you're right - of course, I am open also to other solutions if they
are proofed to be better ;-).
Best regards,
Stefano
Ok guys, I see ... Stefano, you're ok with putting the reg structures into
these
header files?
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] mx28evk: add RTC support
This patch adds support for the MX28 internal RTC and enables u-boot's date command. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- include/configs/mx28evk.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index bea46e7..8a752aa 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -56,6 +56,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_CACHE +#define CONFIG_CMD_DATE #define CONFIG_CMD_DHCP #define CONFIG_CMD_GPIO #define CONFIG_CMD_MII @@ -150,6 +151,13 @@ #endif /* + * RTC + */ +#ifdef CONFIG_CMD_DATE +#define CONFIG_RTC_MXS +#endif + +/* * Boot Linux */ #define CONFIG_CMDLINE_TAG Fabio, can you please test this and 2/3 ? TIA M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 18/01/2012 17:08, Marek Vasut wrote: Ok guys, I see ... Stefano, you're ok with putting the reg structures into these header files? The reg structures are already into these header files - the patch moves only the bit meaning inside the imx-regs.h files. We can discuss if we should move them again into the driver, making the decision on which structure to be used not on a SOC level (#ifdef CONFIG_MXxx), but on basis of the controller type (CSPI or ECSPI). This makes sense if we run (we had until now no use case with the currently supported boards) a MX5 board using a CSPI instead of a ECSPI. In this case, we should also transform MXC_CSPI / MXC_ECSPI in a CONFIG_ define to be put in the board configuration file. However, as usual in u-boot, dead code or code that has no use case and cannot be tested is not allowed. Until we have not such a board (MX5 board requiring CSPI instead of ECSPI), we should avoid to introduce not tested code and let those changes for a next patch. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ORIGEN: remove duplicated MACH_TYPE define
Since MACH_TYPE_ORIGEN is updated on mach-types, remove the MACH_TYPE_ORIGEN on config file. Signed-off-by: Minkyu Kang mk7.k...@samsung.com Cc: Chander Kashyap chander.kash...@linaro.org --- include/configs/origen.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/configs/origen.h b/include/configs/origen.h index cd502d1..8ede825 100644 --- a/include/configs/origen.h +++ b/include/configs/origen.h @@ -52,8 +52,6 @@ #define CONFIG_INITRD_TAG #define CONFIG_CMDLINE_EDITING -/* MACH_TYPE_ORIGEN macro will be removed once added to mach-types */ -#define MACH_TYPE_ORIGEN 3455 #define CONFIG_MACH_TYPE MACH_TYPE_ORIGEN /* Power Down Modes */ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot]: Uboot for MPC8641D uboot getting hanged just before relocating to ram
Hi , I am trying to run u-boot from flash and the u-boot gets hanged at relocate_code function below is the log U-Boot 2010.03 (May 04 2011 - 16:44:35) Unicore software on multiprocessor system!! To enable mutlticore build define CONFIG_MP CPU: 8641D, Version: 3.0, (0x80900130) Core: E600 Core 0, Version: 2.2, (0x80040202) Clock Configuration: CPU:1056 MHz, MPX:528 MHz DDR:264 MHz (528 MT/s data rate), LBC:33 MHz L1:D-cache 32 KB enabled I-cache 32 KB enabled L2:512 KB enabled Board: Springbok I2C: ready BIT: DRAM: DDR: 512 MB Top of RAM usable for U-Boot at: 2000 Reserving 258k for U-Boot at: 1ffbf000 Reserving 256k for malloc() at: 1ff7f000 Reserving 68 Bytes for Board Info at: 1ff7efbc Reserving 72 Bytes for Global Data at: 1ff7ef74 Stack Pointer at: 1ff7ef58 your help appreciated. Thanks in advance Thanks, purva ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Govindraj, On 01/17/12 08:10, Govindraj wrote: And just to clarify further there is no code duplication for ulpi read writes in ehci-omap.c done with this patch. This is not just about code duplication, this is also about using the ULPI framework instead of direct writes to the ULPI PHYs. Patch intends only in configuring ehci to right modes as specified by board file. Modes possible are hsic_mode, tll_mode, ulpi_phy mode. This patch is derived with reference to linux kernel and even there we can see that no ulpi_reg map registers are used and only ehci is configured is respective mode as passed by board data. This is not correct. They are used, see: drivers/usb/host/ehci-omap.c file, omap_ehci_soft_phy_reset() function. It does exactly the same, but yes it does not use the ULPI framework, because in Linux currently, there is no generic enough ULPI framework, so drivers can use it. There were discussions about it and decided that until there is such a framework, things can be done the way they are. Here [1] is the patch fixing Marek Vasut marek.va...@gmail.com comments. This corrected patch along with dependent patch from Ilya Yanok ya...@emcraft.com [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3 Is available here: git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap -- Thanks, Govindraj.R [1]: From 56b1b94128495ed4bf83e2f20f3884833e2aa082 Mon Sep 17 00:00:00 2001 From: Govindraj.R govindraj.r...@ti.com Date: Tue, 27 Dec 2011 14:53:12 +0530 Subject: [PATCH 2/6] ehci-omap: Clean up added ehci-omap.c Clean up added ehci-omap.c and make it generic for re-use across soc having same ehci ip block. Also pass the modes to be configured and configure the ports accordingly. All usb layers are not cache aligned till then keep cache off for usb ops as ehci will use internally dma for all usb ops. * Add a generic common header ehci-omap.h having common ip block data and reg shifts. * Rename and modify ehci-omap3 to ehci.h retain only conflicting sysc reg shifts remove others and move to common header file. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/include/asm/arch-omap3/ehci.h | 55 ++ arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 --- arch/arm/include/asm/arch-omap4/ehci.h | 49 ++ arch/arm/include/asm/ehci-omap.h | 147 + drivers/usb/host/ehci-omap.c | 228 +++--- 5 files changed, 423 insertions(+), 114 deletions(-) create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h create mode 100644 arch/arm/include/asm/ehci-omap.h diff --git a/arch/arm/include/asm/arch-omap3/ehci.h b/arch/arm/include/asm/arch-omap3/ehci.h new file mode 100644 index 000..d622363 --- /dev/null +++ b/arch/arm/include/asm/arch-omap3/ehci.h @@ -0,0 +1,55 @@ +/* + * (C) Copyright 2011 + * Alexander Holler hol...@ahsoftware.de + * + * Based on drivers/usb/host/ehci-omap.c from Linux 2.6.37 + * + * See there for additional Copyrights. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ +#ifndef _EHCI_H_ +#define _EHCI_H_ hmmm... isn't it too generic? I think you should have included a part of the path to the file, so no namespace collision will occure. something like _OMAP3_EHCI_H_? + +/* USB/EHCI registers */ +#define OMAP_USBTLL_BASE 0x48062000UL +#define OMAP_UHH_BASE0x48064000UL +#define OMAP_EHCI_BASE 0x48064800UL + +/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2) +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1 + +/* UHH Register Set */ +#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 1) +#define
[U-Boot] [PATCH] OMAP3: Correct get_sdr_cs_offset mask
The function get_sdr_cs_offset reads the CS_CFG register in the SDRC to determine where CS1 is mapped to. make_cs1_contiguous() will set CS1 to follow after CS0. The CS_CFG register has values in bits 9:8 and 3:0 but we had erroneously been testing 5:4 and 3:0 resulting in incorrect offsets on platforms with less than 128MB as 3:0 describe 128MB hunks and 9:8 describe 32MB offsets after the 128MB hunk. Tested-by: Grant Erickson maratho...@gmail.com Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/omap3/sdrc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c index a27b4b1..91f42c0 100644 --- a/arch/arm/cpu/armv7/omap3/sdrc.c +++ b/arch/arm/cpu/armv7/omap3/sdrc.c @@ -102,7 +102,7 @@ u32 get_sdr_cs_offset(u32 cs) return 0; offset = readl(sdrc_base-cs_cfg); - offset = (offset 15) 27 | (offset 0x30) 17; + offset = (offset 15) 27 | (offset 0x300) 17; return offset; } -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mx28evk: add SPI support
On 01/18/2012 05:07 PM, Marek Vasut wrote:
This patch adds SPI support for the MX28EVK. Support for
an optionally installed SPI flash is also added. An example
configuration for redundant envrionment from SPI flash is also
added but disabled by default.
This patch has been tested on a MX28EVK Rev. D with an installed
SST25VF032B 32Mbit SPI flash.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
board/freescale/mx28evk/iomux.c |8 +++
include/configs/mx28evk.h | 44
-- 2 files changed, 49 insertions(+),
3 deletions(-)
diff --git a/board/freescale/mx28evk/iomux.c
b/board/freescale/mx28evk/iomux.c index 904e3f3..396761b 100644
--- a/board/freescale/mx28evk/iomux.c
+++ b/board/freescale/mx28evk/iomux.c
@@ -28,6 +28,7 @@
#define MUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#define MUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+#define MUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -130,6 +131,13 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_EMI_CE0N__EMI_CE0N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CE1N__EMI_CE1N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CKE__EMI_CKE | MUX_CONFIG_EMI,
+
+/* SPI2 (for SPI flash) */
+MX28_PAD_SSP2_SCK__SSP2_SCK | MUX_CONFIG_SSP2,
+MX28_PAD_SSP2_MOSI__SSP2_CMD | MUX_CONFIG_SSP2,
+MX28_PAD_SSP2_MISO__SSP2_D0 | MUX_CONFIG_SSP2,
+MX28_PAD_SSP2_SS0__SSP2_D3 |
+(MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP),
};
void board_init_ll(void)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 8f791aa..04967d7 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -64,6 +64,8 @@
#define CONFIG_CMD_NET
#define CONFIG_CMD_NFS
#define CONFIG_CMD_PING
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
#define CONFIG_CMD_USB
/*
@@ -127,9 +129,11 @@
* MMC Driver
*/
#define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET (256 * 1024)
-#define CONFIG_ENV_SIZE (16 * 1024)
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#ifdef CONFIG_ENV_IS_IN_MMC
+ #define CONFIG_ENV_OFFSET (256 * 1024)
+ #define CONFIG_ENV_SIZE(16 * 1024)
+ #define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
#define CONFIG_CMD_SAVEENV
#ifdef CONFIG_CMD_MMC
#define CONFIG_MMC
@@ -170,6 +174,40 @@
#endif
/*
+ * SPI
+ */
+#ifdef CONFIG_CMD_SPI
+#define CONFIG_HARD_SPI
+#define CONFIG_MXS_SPI
+#define CONFIG_SPI_HALF_DUPLEX
+#define CONFIG_DEFAULT_SPI_BUS 2
+#define CONFIG_DEFAULT_SPI_MODE SPI_MODE_0
+
+/* SPI Flash */
+#ifdef CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+/* this may vary and depends on the installed chip */
+#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+#define CONFIG_SF_DEFAULT_SPEED 2400
+
+/* (redundant) environemnt in SPI flash */
+#undef CONFIG_ENV_IS_IN_SPI_FLASH
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#define CONFIG_ENV_SIZE 0x1000 /* 4KB */
+#define CONFIG_ENV_OFFSET 0x4 /* 256K */
+#define CONFIG_ENV_OFFSET_REDUND(CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#define CONFIG_ENV_SECT_SIZE0x1000
+#define CONFIG_ENV_SPI_CS 0
+#define CONFIG_ENV_SPI_BUS 2
+#define CONFIG_ENV_SPI_MAX_HZ 2400
+#define CONFIG_ENV_SPI_MODE SPI_MODE_0
+#endif
+#endif
+#endif
+
+/*
* Boot Linux
*/
#define CONFIG_CMDLINE_TAG
Hm, good ... so the SPI flash works now with no modifications ?
Of course not! The SPI driver needs to be fixed. Either by my previously
posted patch or by god's hands :-)
Fabio asked for this patch in order to test my SPI driver fix.
But I think this is independant from each other.
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mx28evk: add SPI support
On 01/18/2012 05:07 PM, Marek Vasut wrote:
This patch adds SPI support for the MX28EVK. Support for
an optionally installed SPI flash is also added. An example
configuration for redundant envrionment from SPI flash is also
added but disabled by default.
This patch has been tested on a MX28EVK Rev. D with an installed
SST25VF032B 32Mbit SPI flash.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
board/freescale/mx28evk/iomux.c |8 +++
include/configs/mx28evk.h | 44
-- 2 files changed, 49
insertions(+), 3 deletions(-)
diff --git a/board/freescale/mx28evk/iomux.c
b/board/freescale/mx28evk/iomux.c index 904e3f3..396761b 100644
--- a/board/freescale/mx28evk/iomux.c
+++ b/board/freescale/mx28evk/iomux.c
@@ -28,6 +28,7 @@
#define MUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#define MUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+#define MUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -130,6 +131,13 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_EMI_CE0N__EMI_CE0N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CE1N__EMI_CE1N | MUX_CONFIG_EMI,
MX28_PAD_EMI_CKE__EMI_CKE | MUX_CONFIG_EMI,
+
+ /* SPI2 (for SPI flash) */
+ MX28_PAD_SSP2_SCK__SSP2_SCK | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_MOSI__SSP2_CMD | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_MISO__SSP2_D0 | MUX_CONFIG_SSP2,
+ MX28_PAD_SSP2_SS0__SSP2_D3 |
+ (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP),
};
void board_init_ll(void)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 8f791aa..04967d7 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -64,6 +64,8 @@
#define CONFIG_CMD_NET
#define CONFIG_CMD_NFS
#define CONFIG_CMD_PING
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
#define CONFIG_CMD_USB
/*
@@ -127,9 +129,11 @@
* MMC Driver
*/
#define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET (256 * 1024)
-#define CONFIG_ENV_SIZE (16 * 1024)
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#ifdef CONFIG_ENV_IS_IN_MMC
+ #define CONFIG_ENV_OFFSET(256 * 1024)
+ #define CONFIG_ENV_SIZE (16 * 1024)
+ #define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
#define CONFIG_CMD_SAVEENV
#ifdefCONFIG_CMD_MMC
#define CONFIG_MMC
@@ -170,6 +174,40 @@
#endif
/*
+ * SPI
+ */
+#ifdef CONFIG_CMD_SPI
+#define CONFIG_HARD_SPI
+#define CONFIG_MXS_SPI
+#define CONFIG_SPI_HALF_DUPLEX
+#define CONFIG_DEFAULT_SPI_BUS2
+#define CONFIG_DEFAULT_SPI_MODE SPI_MODE_0
+
+/* SPI Flash */
+#ifdef CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+/* this may vary and depends on the installed chip */
+#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SF_DEFAULT_MODESPI_MODE_0
+#define CONFIG_SF_DEFAULT_SPEED 2400
+
+/* (redundant) environemnt in SPI flash */
+#undef CONFIG_ENV_IS_IN_SPI_FLASH
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#define CONFIG_ENV_SIZE 0x1000 /* 4KB */
+#define CONFIG_ENV_OFFSET 0x4 /* 256K */
+#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#define CONFIG_ENV_SECT_SIZE 0x1000
+#define CONFIG_ENV_SPI_CS 0
+#define CONFIG_ENV_SPI_BUS2
+#define CONFIG_ENV_SPI_MAX_HZ 2400
+#define CONFIG_ENV_SPI_MODE SPI_MODE_0
+#endif
+#endif
+#endif
+
+/*
* Boot Linux
*/
#define CONFIG_CMDLINE_TAG
Hm, good ... so the SPI flash works now with no modifications ?
Of course not! The SPI driver needs to be fixed. Either by my previously
posted patch or by god's hands :-)
Fabio asked for this patch in order to test my SPI driver fix.
But I think this is independant from each other.
Matthias
Ok, I see ... sigh, can you please do such negotiations on the mailing list so
people are informed about such?
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] Introduce generic relocation feature
[+TI maintainers, tx25 board maintainer] Hi Albert, On Tue, Jan 17, 2012 at 11:28 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Simon, Le 26/12/2011 19:24, Simon Glass a écrit : (I am resending this rebased so I can continue with this board-unification work and allow people to review patches. There were some comments on the v2 series but my questions have been sitting on the list for 2 weeks so it is probably time for a new series.) This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series implements a generic relocation feature, which is the bridge between board_init_f() and board_init_r(). It then moves ARM over to use this framework, as an example. On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. This is a static inline function to reduce code size overhead. Agreed. OK, that is the first three patches. For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later. It may be useful for other architectures with a lot of different CPUs to have a similar file. NAK for several reasons: I think you are NAKing the 'arm: Add processor function library' patch out of the series: Create reloc.h and include it where needed define CONFIG_SYS_SKIP_RELOC for all archs Add generic relocation feature arm: Add processor function library arm: Move over to generic relocation arm: Remove unused code in start.S Q1: Should I remove that patch and just repeat the code from there in each start.S file? The impact would be to remove most of the code in the relocate_code() function in each start.S except for the last few instructions (reproduced below). 1. The code that goes on proc.S is already in start.S, which already contains things which cannot be written in C and are common functions used by all ARM CPUs. Granted, right now start.S is duplicated in multiple CPU directories; so the thing to do is to merge all ARM start.S files into a single one, rather than merging only one of its parts. Q2: What should this merged file be called and what directory should it be in? This is the question I asked last time, and the lack of an answer is the reason why I have been unable to make progress here. Please advise your preference and I will sort it out. Note I don't think I can do this in one series - there is far too much variation between the files for me to take on that way. I need a new file than I can bit I bit move things over into, allowing affected parties to comment on each as I go. 2. There is no interest in moving this segment of code from all start.S files into a new proc.S file: there is no gain is code size obviously, and there is an increase in source file count. Just checking that you see that the code is removed from start.S, not moved. The code in proc.S is: .globl proc_call_board_init_r proc_call_board_init_r: #ifndef CONFIG_SYS_ICACHE_OFF mcr p15, 0, r0, c7, c5, 0 @ invalidate icache mcr p15, 0, r0, c7, c10, 4 @ DSB mcr p15, 0, r0, c7, c5, 4 @ ISB #endif mov sp, r3 /* jump to it ... */ mov pc, r2 which is taken from the end of each relocate_code() copy. Assuming we are on the page, then ok. 3. I consider that files should contain 'things' based on their common /functionality/, not on their similar /nature/, and going about starting up U-Boot is a functionality. The code here sets the stack pointer and calls a function. However I agree this unlikely to be useful outside starting up. See Q2. Note that eventually, having a single start.S will achieve the same effect as this 'proc.S' patch. At present start.S runs for a bit and then jumps to board_init_f(). At the end of board_init_f() we jump back to start.S (relocate_code() function) and from there to board_init_r(). Also start.S has exception handling code. I think start.S should be thought of as in three parts: - early CPU init (hardest to make common) - relocation code (last 3 patches of this series) - exception code The first one clearly belongs in start.S. I don't think the other two do. They are not related to CPU start-up. The relocation code is only there because of the need to call a function with a new stack pointer. Other than that it can be written in C. Apart from reset the exception code isn't related to starting up the CPU - it is only there because the it is a
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 01/18/2012 01:39 AM, Stefano Babic wrote: On 18/01/2012 02:44, Eric Nelson wrote: I'll defer to Stefano on this one, since I did this in response to his request: Yes, I admit I am guilty about this ! The layout of the CSPI registers is not exactly the same for all SOCs. For example, the MXC_CSPICTRL_TC has a different position, as well as the BITCOUNT (because the MX31 can send less bits in one shot) and MXC_CSPICTRL_CHIPSELECT. So they are similar, but not exactly the same. Then we have the MX5 registers. Even if we check the CSPI (not eCSPI) controller, the layout of the registers is different compared to the MX3 SOCs. The struct cspi_regs is already present in mx31, mx35, and mx51 headers, so I'm not breaking new ground here, only in the bitfield declarations. Right, I see the same. The cspi_regs structure is already defined into the imx_regs.h, only the bit layout was moved. And as the bit layout is SOC dependent, I think the right place for it is inside the imx-regs.h registers. My interpretation of Stefano's intent is to clean up the driver at the expense of extra defines in the arch-specific headers. Yes, you're right - of course, I am open also to other solutions if they are proofed to be better ;-). I think this is about as good as things get with the current code base. I would argue that the driver would be better if it explicitly supported ECSPI and CSPI at the same time since the mx5x CPUs support it. Implememting that would likely require a de-structuring (removing the use of structs to represent the register set). IOW, a re-write. That's probably not worth the effort unless someone's built hardware that needs it (I'm not aware of any). On our boards that use more than one channel of SPI (for PMIC and SF), we're using ECSPI on both. I think the same was true on the MX51 EVK. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
On Tue, Jan 17, 2012 at 1:12 AM, Simon Glass s...@chromium.org wrote:
From: Heiko Schocher h...@denx.de
This Patch introduce the new i2c_core file, which holds
the I2C core functions, for the rework of the multibus/
multiadapter support.
Also adds changes in i2c.h for the new I2C multibus/multiadapter
support. This new support can be activated with the
CONFIG_SYS_I2C define.
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/global_data.h | 3 +
arch/avr32/include/asm/global_data.h | 3 +
arch/blackfin/include/asm/global_data.h | 4 +-
arch/m68k/include/asm/global_data.h | 3 +
arch/microblaze/include/asm/global_data.h | 3 +
arch/mips/include/asm/global_data.h | 3 +
arch/nios2/include/asm/global_data.h | 3 +
arch/powerpc/include/asm/global_data.h | 3 +
arch/sh/include/asm/global_data.h | 3 +
arch/sparc/include/asm/global_data.h | 3 +
arch/x86/include/asm/global_data.h | 3 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c_core.c | 360
+
include/i2c.h | 199 +++-
14 files changed, 584 insertions(+), 10 deletions(-)
create mode 100644 drivers/i2c/i2c_core.c
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 23a6077..924cea2 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -87,6 +87,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#if defined(CONFIG_SYS_I2C)
+ void *cur_adap; /* current used i2c adapter */
+#endif
I was really hoping we could get rid of the concept of a current i2c
adapter, and just force all drivers to specify the I2C adapter they
want to use for a given I2C operation. That's how Linux operates, and
it will prevent stuff like this:
void *old;
void *new;
old = get_current_i2c_adapter();
set_i2c_adapter(new);
// do I2C stuff
set_i2c_adapter(old);
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
On Wednesday 18 January 2012 15:11:56 Tabi Timur-B04825 wrote:
On Tue, Jan 17, 2012 at 1:12 AM, Simon Glass wrote:
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -87,6 +87,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#if defined(CONFIG_SYS_I2C)
+ void*cur_adap; /* current used i2c adapter */
+#endif
I was really hoping we could get rid of the concept of a current i2c
adapter, and just force all drivers to specify the I2C adapter they
want to use for a given I2C operation. That's how Linux operates, and
it will prevent stuff like this:
void *old;
void *new;
old = get_current_i2c_adapter();
set_i2c_adapter(new);
// do I2C stuff
set_i2c_adapter(old);
that's only needed if you expect the pointer to stay valid across calls. i
don't think it does for most (all?) drivers.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Mike Frysinger wrote: that's only needed if you expect the pointer to stay valid across calls. i don't think it does for most (all?) drivers. True, but it's hard to know sometimes when it's needed. I do it in my code just to be sure. Regardless, I still think the idea of a current i2c bus is flawed. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Hi Tabi,
On Wed, Jan 18, 2012 at 12:11 PM, Tabi Timur-B04825
b04...@freescale.com wrote:
On Tue, Jan 17, 2012 at 1:12 AM, Simon Glass s...@chromium.org wrote:
From: Heiko Schocher h...@denx.de
This Patch introduce the new i2c_core file, which holds
the I2C core functions, for the rework of the multibus/
multiadapter support.
Also adds changes in i2c.h for the new I2C multibus/multiadapter
support. This new support can be activated with the
CONFIG_SYS_I2C define.
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/global_data.h | 3 +
arch/avr32/include/asm/global_data.h | 3 +
arch/blackfin/include/asm/global_data.h | 4 +-
arch/m68k/include/asm/global_data.h | 3 +
arch/microblaze/include/asm/global_data.h | 3 +
arch/mips/include/asm/global_data.h | 3 +
arch/nios2/include/asm/global_data.h | 3 +
arch/powerpc/include/asm/global_data.h | 3 +
arch/sh/include/asm/global_data.h | 3 +
arch/sparc/include/asm/global_data.h | 3 +
arch/x86/include/asm/global_data.h | 3 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c_core.c | 360
+
include/i2c.h | 199 +++-
14 files changed, 584 insertions(+), 10 deletions(-)
create mode 100644 drivers/i2c/i2c_core.c
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 23a6077..924cea2 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -87,6 +87,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#if defined(CONFIG_SYS_I2C)
+ void *cur_adap; /* current used i2c adapter */
+#endif
I was really hoping we could get rid of the concept of a current i2c
adapter, and just force all drivers to specify the I2C adapter they
want to use for a given I2C operation. That's how Linux operates, and
it will prevent stuff like this:
I agree completely, it was one of the things I was going to ask for.
We should add a new parameter to calls instead IMO.
void *old;
void *new;
old = get_current_i2c_adapter();
set_i2c_adapter(new);
// do I2C stuff
set_i2c_adapter(old);
--
Timur Tabi
Linux kernel developer at Freescale
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Simon Glass wrote: I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO. I would be in favor of a patch that replaces all of the I2C calls. It would be a massive patch, but it solve a lot of problems in one shot. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/20] fdt: Tidy up a few fdtdec problems
On 01/11/2012 09:32 PM, Simon Glass wrote: This fixes five trivial issues in fdtdec.c: 1. fdtdec_get_is_enabled() doesn't really need a default value 2. The fdt must be word-aligned, since otherwise it will fail on ARM 3. The compat_names[] array is missing its first element. This is needed only because the first fdt_compat_id is defined to be invalid. 4. Added a header prototype for fdtdec_next_compatible() 5. Change fdtdec_next_alias() to only increment its 'upto' parameter on success, to make the display error messages in the caller easier. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Stephen Warren swar...@nvidia.com (only because I commented on this before; I'm not an FDT maintainer here) -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 02/20] fdt: Add functions to access phandles, arrays and bools
On 01/11/2012 09:32 PM, Simon Glass wrote: Add a function to look up a property which is a phandle in a node, and another to read a fixed-length integer array from an fdt property. Also add a function to read boolean properties, although there is no actual boolean type in U-Boot. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Stephen Warren swar...@nvidia.com (only because I commented on this before; I'm not an FDT maintainer here) -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions
On 01/11/2012 09:32 PM, Simon Glass wrote:
This adds some support into fdtdec for reading GPIO definitions from
the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
is of the form:
gpio-function-name = phandle gpio_num flags;
That's not true in general.
The binding definition for the GPIO controller that provides the GPIO in
question defines the number and meaning of all cells after the phandle
cell. In practice, this usually does mean two cells with the meanings
above, but there's no need for this to be true in general.
For reference, the correct way to parse such a property is:
* Read the first cell.
* Find the node referenced by the phandle.
* Ensure property gpio-controller is present in the controller node.
* Read property #gpio-cells from the controller node.
* Extract #gpio-cells from the original property.
* Keep processing more cells from the original property; there may be
multiple GPIOs listed.
Still, I'll review this patch under the assumption that it's understood
that its applicability is limited to the subset of controllers that use
the same GPIO specifier as Tegra, i.e. that which you documented.
where:
phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags is a flag, as follows:
bitmeaning
0 0=polarity normal, 1=active low (inverted)
For reference, according to the binding documentation in the Linux
kernel, Samsung Exynos4 doesn't use this format, and while all other
chips do have a flags cell, about 50% of the controllers indicate the
cell is unused.
An example is:
gpio-enable-propounder = gpio 43 0;
It appears to be idiomatic to name GPIO-related properties as plural
even when only one GPIO is expected, so e.g. wp-gpios for an SDHCI
controller's write-proptect GPIO, rather than simply wp-gpio.
...
diff --git a/include/fdtdec.h b/include/fdtdec.h
...
+/* GPIOs are numbered from 0 */
+enum {
+ FDT_GPIO_NONE = -1U,/* an invalid GPIO used to end our list */
Is this due to the way U-Boot works right now, or something defined by
this patch? It's been pointed out that the kernel's choice to use -1 as
invalid GPIO rather than 0 was a mistake, since that prevents GPIO
fields being easily added to platform data structures, since you then
have to go and initialize every new instance to -1, rather than relying
on BSS initializing it to 0. I assume this is just the way U-Boot works,
so solving this is outside the scope of this patch.
Ignoring all the above, the code looks correct to perform as documented.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Hi Timur, On Wed, Jan 18, 2012 at 1:39 PM, Timur Tabi ti...@freescale.com wrote: Simon Glass wrote: I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO. I would be in favor of a patch that replaces all of the I2C calls. It would be a massive patch, but it solve a lot of problems in one shot. I agree. Do you know of such a patch? :-) Regards, Simon -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/20] tegra: fdt: Add Tegra2x device tree file from kernel
On 01/11/2012 09:32 PM, Simon Glass wrote:
This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
config.mk is updated to provide this file to boards through the
built-in mechanism:
/include/ ARCH_CPU_DTS
Signed-off-by: Simon Glass s...@chromium.org
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
...
+ i2c@7000d000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = nvidia,tegra20-i2c;
+ reg = 0x7000D000 0x200;
+ interrupts = 85 ;
+ };
This is slightly out-of-date now; in next-20120118, that node's
compatible flag is nvidia,tegra20-i2c-dvc. The HW register layout is
somewhat different for this I2C controller, and the different compatible
flag is how the driver this.
Still, you can always apply that fix in a later patch before you add I2C
support.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/20] tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel
On 01/11/2012 09:32 PM, Simon Glass wrote: This was taken from commit b48c54e2 at: git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git Signed-off-by: Simon Glass s...@chromium.org diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts This is also somewhat out-of-date w.r.t. the latest in kernel tag next-20120118. It's probably not too much of an issue, so this is probably fine to apply as-is. U-Boot may benefit from the addition of many status=disable properties, and clock-frequency properties for the I2C nodes. It'd be good to keep U-Boot up-to-date with the kernel as much as possible. Of course, there are ongoing changes being queued for the kernel as work is done too... -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 08/20] fdt: Add staging area for device tree binding documentation
On 01/11/2012 09:32 PM, Simon Glass wrote: Add a directory to hold device tree binding files, to permit easy review of this material in U-Boot patches. Signed-off-by: Simon Glass s...@chromium.org diff --git a/doc/device-tree-bindings/README b/doc/device-tree-bindings/README +The intent is not to commit these files to U-Boot, or at least only +temporarily, Rather we hope that the files will be stored in another +repo (shared with Linux) which is brought in as needed. Failing that, +changes here will be commited to the Linux +Documentation/devicetree/bindings/ directory. Given there is no shared repo right now, I'd assert we should be specific and explicitly state that the intent /is/ to check in the binding documentation here, and mirror the kernel tree. But, the patch is fine to me as-is if you wish. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Simon Glass wrote: I agree. Do you know of such a patch? :-) No, but it wouldn't be heard to create -- mostly a global search-and-replace. I wouldn't even attempt it without getting pre-approved by Wolfgang first, though. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request: u-boot-tegra/master
Albert, Please pull u-boot-tegra/master into arm master. Thanks. The following changes since commit 137703b811502dfea364650fb3e17f20b4c21333: overo: add SPL support (2012-01-16 08:40:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-tegra master Simon Glass (9): tegra: Adjust funcmux config test to permit expansion tegra: Add enum to select from available funcmux configs tegra: Add I2C support to funcmux tegra: Add SDMMC support to funcmux tegra: Use funcmux for MMC on tamonten tegra: Use funcmux for MMC on harmony tegra: Use funcmux for MMC on seaboard tegra: mmc: Support operation with dcache enabled tegra2: Enable data cache Stephen Warren (3): tegra2: Fix conflicting pinmux for UARTA tegra2: Fix default RAM size selection in odmdata tegra2: Add support for Compal Paz00 (Toshiba AC100) MAINTAINERS|1 + arch/arm/cpu/armv7/tegra2/board.c | 12 ++- arch/arm/cpu/armv7/tegra2/funcmux.c| 152 +--- arch/arm/include/asm/arch-tegra2/funcmux.h | 30 ++- board/avionic-design/common/tamonten.c | 10 +-- board/compal/paz00/Makefile| 41 board/compal/paz00/paz00.c | 81 +++ board/nvidia/harmony/harmony.c | 19 +--- board/nvidia/seaboard/seaboard.c | 21 +--- boards.cfg |1 + drivers/mmc/tegra2_mmc.c | 16 +++ include/configs/paz00.h| 51 + 12 files changed, 379 insertions(+), 56 deletions(-) create mode 100644 board/compal/paz00/Makefile create mode 100644 board/compal/paz00/paz00.c create mode 100644 include/configs/paz00.h --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 12/20] tegra: usb: fdt: Add additional device tree definitions for USB ports
On 01/11/2012 09:33 PM, Simon Glass wrote: This adds clock references to the USB part of the device tree for U-Boot. The USB timing information may vary between boards sometimes, but for now we hard-code it in C. This is because all current T2x boards use the same values, we will deal with T3x later and we first need to agree on the format for this timing information in the fdt and may in fact decide that it has no place there. diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi + clocks = periph_clk 22; // PERIPH_ID_USBD Typically /* */ rather than // I think -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 17/20] tegra: usb: Add USB support to nvidia boards
On 01/11/2012 09:33 PM, Simon Glass wrote: This adds basic USB support for port 0. The other port is not supported yet. diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c +#ifdef CONFIG_USB_EHCI_TEGRA + /* For USB GPIO PD0. for now, since we have no pinmux in fdt */ + pinmux_tristate_disable(PINGRP_SLXK); Can we ifdef this so it only happens on Seaboard? Who knows what other boards use that pin group for. Unfortunately, I checked and this really does appear required for Seaboard, since there's no pull on the USB1_VBUS_EN GPIO, so Tegra must drive it. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 16/20] tegra: usb: Add support for Tegra USB peripheral
On 01/11/2012 09:33 PM, Simon Glass wrote:
This adds basic support for the Tegra2 USB controller. Board files should
call board_usb_init() to set things up.
diff --git a/arch/arm/cpu/armv7/tegra2/usb.c b/arch/arm/cpu/armv7/tegra2/usb.c
+/* Record which controller can switch from host to device mode */
+static struct fdt_usb *host_dev_ctlr;
As you'll note from my comments on the DT bindings, it doesn't make
sense to have a single global variable for that; both USB1 and USB3 can
switch at run-time apparently, and USB2 at initialization time.
+void usbf_reset_controller(enum periph_id id, struct usb_ctlr *usbctlr)
...
+ /*
+* Set USB1_NO_LEGACY_MODE to 1, Registers are accessible under
+* base address
+*/
+ if (id == PERIPH_ID_USBD)
+ setbits_le32(usbctlr-usb1_legacy_ctrl, USB1_NO_LEGACY_MODE);
...
+ /* Set USB3 to use UTMIP PHY */
+ if (id == PERIPH_ID_USB3)
+ setbits_le32(usbctlr-susp_ctrl, UTMIP_PHY_ENB);
...
+static void init_usb_controller(enum periph_id id, struct usb_ctlr *usbctlr,
+ const u32 timing[])
...
+ /*
+* To Use the A Session Valid for cable detection logic, VBUS_WAKEUP
+* mux must be switched to actually use a_sess_vld threshold.
+*/
+ if (id == PERIPH_ID_USBD) {
+ clrsetbits_le32(usbctlr-usb1_legacy_ctrl,
+ VBUS_SENSE_CTL_MASK, VBUS_SENSE_CTL_A_SESS_VLD);
+ }
Uggh. The driver shouldn't really be altering its behaviour based on
knowledge of the instance number. Can those conditions be modified to
test something else instead?
For the first (USBD) condition, it seems like if the registers are
different, we should really have either different compatible values, or
a flag in the DT to indicate this.
For the second (USB3) condition, shouldn't this be testing the phy type
field, not the instance ID?
For the third (USBD) condition, can it test whether there's a VBUS GPIO
defined, or whether an appropriate combination of my proposed
enable-host-mode/enable-device-mode properties are present?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Hi,
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
.../bindings/clock/nvidia,tegra20-car.txt | 156
arch/arm/boot/dts/tegra-seaboard.dts | 18 +++
arch/arm/boot/dts/tegra20.dtsi |7 +
3 files changed, 181 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 000..71cfdd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -0,0 +1,156 @@
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
Hmm. I'd prefer to just ditch the notion of clock-names in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+ For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the clocks
+ that the CAR provides. The list of names and clock IDs is below. The IDs
+ may be used in clock specifiers. The names should be listed in this clock-
+ output-names property, sorted in ID order, if this property is present.
+
+ The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+ registers. Later, subsequent IDs will be assigned to all other clocks the
+ CAR controls.
Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.
If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.
[...]
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 32768;
+ };
+
+ osc: oscillator@1 {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1200;
+ };
+};
+
+tegar_car: clock@60006000 {
typo? tegra_car?
+ compatible = tegra,periphclk;
+ reg = 0x60006000 1000;
+ clocks = clk_32k osc;
+ clock-names = 32k_in, osc;
+ #clock-cells = 1;
+};
+
+usb@c5004000 {
+ ...
+ clocks = tegra_car 58; /* usb2 */
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 10/20] tegra: fdt: Add additional USB binding
On Wed, Jan 18, 2012 at 03:48:30PM -0700, Stephen Warren wrote: On 01/11/2012 09:32 PM, Simon Glass wrote: This adds a property to indicate a port which can switch between host and device mode. Signed-off-by: Simon Glass s...@chromium.org --- doc/device-tree-bindings/usb/tegra-usb.txt |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt index 035d63d..96fd022 100644 --- a/doc/device-tree-bindings/usb/tegra-usb.txt +++ b/doc/device-tree-bindings/usb/tegra-usb.txt @@ -11,3 +11,7 @@ Required properties : - phy_type : Should be one of ulpi or utmi. - nvidia,vbus-gpio : If present, specifies a gpio that needs to be activated for the bus to be powered. + +Optional properties: + - support-host-mode : If present then this peripheral can switch between + host and device mode All of Tegra's USB ports support host mode, and it's the typical mode of operation. The TRM also indicates that all USB ports support device mode (possibly depending on the PHY type that's been selected for or attached to port). Port 2 explicitly doesn't support run-time switching, but by omission, ports 1 and 3 do. Hence, support-host-mode is not an accurate name, and doesn't match the description given either. I think that it'd be better to: * Add properties to explicitly specify whether the port is intended/allowed to operate (per board design) in each of host or device mode. * Default to static host mode if no properties are present. i.e.: +Optional properties: + - enable-host-mode : Indicate that the port is intended to operate in + host mode. + - enable-device-mode : Indicate that the port is intended to operate + in device mode. fsl-usb.txt uses dr_mode here, which might make sense to reuse given some of the shared IP in question for device mode: - dr_mode : indicates the working mode for fsl-usb2-dr compatible controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Dear Simon Glass, In message capnjgz2klpfmzzwghkdj4el+wixqlv89+cvdvp7pccy+xfa...@mail.gmail.com you wrote: I was really hoping we could get rid of the concept of a current i2c adapter, and just force all drivers to specify the I2C adapter they want to use for a given I2C operation. =A0That's how Linux operates, and it will prevent stuff like this: I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO. Let's do one step at a time. Now we go for multi-bus support. Implementing a new, better device interface is one of the next steps, then. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Free markets select for winning solutions.- Eric S. Raymond ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 10/20] tegra: fdt: Add additional USB binding
Hi Olof, On Wed, Jan 18, 2012 at 9:35 PM, Olof Johansson o...@lixom.net wrote: On Wed, Jan 18, 2012 at 03:48:30PM -0700, Stephen Warren wrote: On 01/11/2012 09:32 PM, Simon Glass wrote: This adds a property to indicate a port which can switch between host and device mode. Signed-off-by: Simon Glass s...@chromium.org --- doc/device-tree-bindings/usb/tegra-usb.txt | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt index 035d63d..96fd022 100644 --- a/doc/device-tree-bindings/usb/tegra-usb.txt +++ b/doc/device-tree-bindings/usb/tegra-usb.txt @@ -11,3 +11,7 @@ Required properties : - phy_type : Should be one of ulpi or utmi. - nvidia,vbus-gpio : If present, specifies a gpio that needs to be activated for the bus to be powered. + +Optional properties: + - support-host-mode : If present then this peripheral can switch between + host and device mode All of Tegra's USB ports support host mode, and it's the typical mode of operation. The TRM also indicates that all USB ports support device mode (possibly depending on the PHY type that's been selected for or attached to port). Port 2 explicitly doesn't support run-time switching, but by omission, ports 1 and 3 do. Hence, support-host-mode is not an accurate name, and doesn't match the description given either. I think that it'd be better to: * Add properties to explicitly specify whether the port is intended/allowed to operate (per board design) in each of host or device mode. * Default to static host mode if no properties are present. i.e.: +Optional properties: + - enable-host-mode : Indicate that the port is intended to operate in + host mode. + - enable-device-mode : Indicate that the port is intended to operate + in device mode. fsl-usb.txt uses dr_mode here, which might make sense to reuse given some of the shared IP in question for device mode: - dr_mode : indicates the working mode for fsl-usb2-dr compatible controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. What does 'dr' mean? Regards, Simon -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Hello Wolfgang, Timur, Simon, Wolfgang Denk wrote: Dear Simon Glass, In message capnjgz2klpfmzzwghkdj4el+wixqlv89+cvdvp7pccy+xfa...@mail.gmail.com you wrote: I was really hoping we could get rid of the concept of a current i2c adapter, and just force all drivers to specify the I2C adapter they want to use for a given I2C operation. =A0That's how Linux operates, and it will prevent stuff like this: I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO. Let's do one step at a time. Now we go for multi-bus support. Ok. Implementing a new, better device interface is one of the next steps, then. Some thoughts to the subject get rid of concept of a current i2c - First, it would be great to get rid of that ;-) - 2 reasons why we currently need the info, what is the current i2c adapter/i2c bus: - U-Boot principle says, don't init a device, if you don't use it. So, if we switch to another i2c adapter or i2c bus (A i2c bus is a combination if one i2c adpater and n i2c muxes), we must deinit the current adapter/bus. Ok, current code didn't this too, but this should a goal to keep in mind ... or we define, that this is not needed. - If we have i2c muxes, and you don't know your current i2c bus, you must on every i2c access also setup the i2c muxes on this i2c bus ... would we do this really? if we have the current i2c bus info, we just have to check, if we are on this bus, and do the i2c access ... if we are not on this i2c bus, we can deinit it complete (the new i2c_core disconnects for example all i2c muxes on the i2c bus) and init the new bus. All this work is done in a central function i2c_set_bus_numer() - Looking in the new multibus i2c_core.c file, we should get rid of static unsigned int i2c_cur_bus __attribute__((section(.data))) = CONFIG_SYS_SPD_BUS_NUM; and cur_adap renamed to cur_i2c_bus and should be a struct i2c_bus_hose pointer. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Hi Heiko, On Wed, Jan 18, 2012 at 10:35 PM, Heiko Schocher h...@denx.de wrote: Hello Wolfgang, Timur, Simon, Wolfgang Denk wrote: Dear Simon Glass, In message capnjgz2klpfmzzwghkdj4el+wixqlv89+cvdvp7pccy+xfa...@mail.gmail.com you wrote: I was really hoping we could get rid of the concept of a current i2c adapter, and just force all drivers to specify the I2C adapter they want to use for a given I2C operation. =A0That's how Linux operates, and it will prevent stuff like this: I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO. Let's do one step at a time. Now we go for multi-bus support. Ok. Implementing a new, better device interface is one of the next steps, then. Some thoughts to the subject get rid of concept of a current i2c - First, it would be great to get rid of that ;-) - 2 reasons why we currently need the info, what is the current i2c adapter/i2c bus: - U-Boot principle says, don't init a device, if you don't use it. So, if we switch to another i2c adapter or i2c bus (A i2c bus is a combination if one i2c adpater and n i2c muxes), we must deinit the current adapter/bus. Ok, current code didn't this too, but this should a goal to keep in mind ... or we define, that this is not needed. - If we have i2c muxes, and you don't know your current i2c bus, you must on every i2c access also setup the i2c muxes on this i2c bus ... would we do this really? Ignoring muxes, we can have more than one i2c adaptor inited at a time (i.e. de-initing is optional). Perhaps reword this slightly. U-Boot can have knowledge of a current adaptor, mux settings and so on, and use this internally within the i2c layer to optimise performance and redundant i2c traffic. But the pain is when the concept of a 'current adaptor' is exposed outside the i2c layer. if we have the current i2c bus info, we just have to check, if we are on this bus, and do the i2c access ... if we are not on this i2c bus, we can deinit it complete (the new i2c_core disconnects for example all i2c muxes on the i2c bus) and init the new bus. All this work is done in a central function i2c_set_bus_numer() Yes but this function could become internal perhaps. - Looking in the new multibus i2c_core.c file, we should get rid of static unsigned int i2c_cur_bus __attribute__((section(.data))) = CONFIG_SYS_SPD_BUS_NUM; and cur_adap renamed to cur_i2c_bus and should be a struct i2c_bus_hose pointer. Sounds good. Heiko do you have time to take over your two patches I sent and tidy them up, or should I continue? Regards, Simon bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
On Tue Jan 17, 2012 at 08:27:58AM -0700, Tom Rini wrote: On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache enabled, if u-boot is not initializing it? (And I think, on davinci SoC we have a none working uboot ethernet driver if d-cache is enabled too). There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot don't initialize it, it maybe overrides it ... or miss I something? Well, there is some data in the cache, which if not flushed creates problems on my board. I get the board to boot just by commenting out cpu_init_crit call. My hypothesis that the D-cache is enabled is simply because cache invalidation followed by cache disabling breaks the board, while flushing it prior to disabling gets it to boot fine. This(invalidation) would not have been a problem if the cache was in the disabled state. Putting my TI hat on, I've confirmed with the RBL folks that they aren't turning on ICACHE/DCACHE. Well, i'm not sure then why does the cache invalidation cause a problem on my platform. Btw, will this patch be accepted. Irrespective of the cache state on my board, it is not a wrong fix, and moreover results in the booting of my board. I haven't yet tried out reading the cache bit state in the spl. Will try out this experiment in a day or two, and share the results. I think someone needs to look over this init code very carefully. If I can summarize from memory quickly, when we enable the CP_CRITICAL_INITS code for everyone that exposed a problem on the hawkboard that _looks_like_ DCACHE is enabled by RBL as changing the code from doing an invalidate to a flush+invalidate fixes a problem. But the manual says we should be doing flush+invalidate anyhow and the RBL code is not turning on DCACHE. Maybe we've got something else being done not as the manual says and that's tickling another issue? Tried a few things on my end. * Read the D-cache value in the spl, and confirmed that the data cache is indeed not enabled. * Enabled the data cache explicitly in cpu_init_crit, and booted u-boot. u-boot comes up fine, and trying a ping switches off the data cache with the warning message. So it definitely looks like the cache is not enabled. But still not able to figure out as to why does the flushing operation help. Really need to get a debugger :) -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 10/20] tegra: fdt: Add additional USB binding
Hi Olof, On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson o...@lixom.net wrote: Hi, On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass s...@chromium.org wrote: fsl-usb.txt uses dr_mode here, which might make sense to reuse given some of the shared IP in question for device mode: - dr_mode : indicates the working mode for fsl-usb2-dr compatible controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. What does 'dr' mean? After some searching, it looks like it means dual-role, which seems appropriate terminology for the tegra SoC as well. Thanks for looking that up. Well maybe, but it could mean data reverse mode or distinctive ring...I like Stephen's nice device-tree-friendly naming and explanation :-) Are we stuck with this? Regards, Simon -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 10/20] tegra: fdt: Add additional USB binding
Hi, On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass s...@chromium.org wrote: fsl-usb.txt uses dr_mode here, which might make sense to reuse given some of the shared IP in question for device mode: - dr_mode : indicates the working mode for fsl-usb2-dr compatible controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. What does 'dr' mean? After some searching, it looks like it means dual-role, which seems appropriate terminology for the tegra SoC as well. -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 10/20] tegra: fdt: Add additional USB binding
On Wed, Jan 18, 2012 at 10:59 PM, Simon Glass s...@chromium.org wrote: Hi Olof, On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson o...@lixom.net wrote: Hi, On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass s...@chromium.org wrote: fsl-usb.txt uses dr_mode here, which might make sense to reuse given some of the shared IP in question for device mode: - dr_mode : indicates the working mode for fsl-usb2-dr compatible controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. What does 'dr' mean? After some searching, it looks like it means dual-role, which seems appropriate terminology for the tegra SoC as well. Thanks for looking that up. Well maybe, but it could mean data reverse mode or distinctive ring...I like Stephen's nice device-tree-friendly naming and explanation :-) Are we stuck with this? I think there's value in staying common with similar bindings on other platforms, yes. Sorry. :) -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] tt01: add MMC support
On 01/18/2012 01:37 PM, Stefano Babic wrote:
Hi Helmut,
+#ifdef CONFIG_CONSOLE_EXTRA_INFO
+void video_get_info_str(int line_number, char *info)
This has nothing with MCC. Please extend your commit message to explain
you are also adding this feature.
I simply mixed in a different branch, which was not the intention, sorry
for the noise, I'll resend.
+{
+ u32 srev = get_cpu_rev();
+
+ switch (line_number) {
+ case 2:
+ sprintf(info, CPU : Freescale i.MX31 rev %d.%d%s at %d MHz,
+ (srev 0xF0) 4, (srev 0x0F),
+ ((srev 0x8000) ? unknown : ),
+ mxc_get_clock(MXC_ARM_CLK) / 100);
I know it is only one line, but it is not related to your board because
it is really print_cpuinfo() into a buffer. So this cpu part should be
moved into the SOC place (arch/arm/cpu/arm1136/mx31/generic.c).
However, which is the real reason to do that ? I have supposed that
setting video as stdout it is enough to redirect all output to the LCD,
and then the usual print_cpuinfo() works, without adding / duplicating
function that already use printf() for the output.
I do not see a lot of boards implementing video_get_info_str(), and I
understand that it is a way to customize the output. However, is it the
correct way ? Does print_cpuinfo() not work if redirect to the video ? I
have added Anatolji (video maintainer in CC) to get his opinion.
Best regards,
Stefano Babic
Actually the above is only a glitch, the output sits there since more
than a year (probably adjusted at some point).
I just didn't realize that print_cpuinfo does the same.
I'll be contributing the video stuff in one of the next patches for tt01
and fix it then, so thanks for your review, even though I'll remove it
from this patch.
Helmut
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] tt01: add MMC support
board_mmc_init() initializes the pins of SDHC1 and
turns on V_MMC1 of the PMIC. Config adds support for EXT2
and FAT.
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
V4: removed unrelated video_get_info_str() stuff
V3: moved change from fsl_pmic.h to mc13783.h (mc13892 differs!)
V2: pmic_reg_(read|write) use constants from fsl_pmic.h now
board/hale/tt01/tt01.c | 34 --
include/configs/tt01.h | 12
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/board/hale/tt01/tt01.c b/board/hale/tt01/tt01.c
index 2995c8f..ed3fa6e 100644
--- a/board/hale/tt01/tt01.c
+++ b/board/hale/tt01/tt01.c
@@ -26,6 +26,8 @@
#include netdev.h
#include command.h
#include pmic.h
+#include fsl_pmic.h
+#include mc13783.h
#include asm/arch/clock.h
#include asm/arch/sys_proto.h
#include asm/io.h
@@ -175,8 +177,6 @@ int board_init(void)
int board_late_init(void)
{
- pmic_init();
-
#ifdef CONFIG_HW_WATCHDOG
mxc_hw_watchdog_enable();
#endif
@@ -190,6 +190,36 @@ int checkboard(void)
return 0;
}
+#ifdef CONFIG_MXC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ u32 val;
+ struct pmic *p;
+
+ /*
+ * this is the first driver to use the pmic, so call
+ * pmic_init() here. board_late_init() is too late for
+ * the MMC driver.
+ */
+ pmic_init();
+ p = get_pmic();
+
+ /* configure pins for SDHC1 only */
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_CLK, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_CMD, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA0, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA1, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA2, MUX_CTL_FUNC));
+ mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SD1_DATA3, MUX_CTL_FUNC));
+
+ /* turn on power V_MMC1 */
+ if (pmic_reg_read(p, REG_MODE_1, val) 0)
+ pmic_reg_write(p, REG_MODE_1, val | VMMC1EN);
+
+ return mxc_mmc_init(bis);
+}
+#endif
+
int board_eth_init(bd_t *bis)
{
int rc = 0;
diff --git a/include/configs/tt01.h b/include/configs/tt01.h
index a553712..6846816 100644
--- a/include/configs/tt01.h
+++ b/include/configs/tt01.h
@@ -180,6 +180,11 @@
#define CONFIG_SMC911X_BASE(CS4_BASE+0x20)
#define CONFIG_SMC911X_16_BIT
+/* mmc driver */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MXC_MMC
+#define CONFIG_MXC_MCI_REGS_BASE SDHC1_BASE_ADDR
/*
* Command definition
*/
@@ -229,6 +234,13 @@
#define CONFIG_CMDLINE_EDITING
+/* MMC boot support */
+#define CONFIG_CMD_MMC
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+
#define CONFIG_NAND_MXC
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_MAX_CHIPS 1
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Hello Simon, Simon Glass wrote: Hi Heiko, On Wed, Jan 18, 2012 at 10:35 PM, Heiko Schocher h...@denx.de wrote: Hello Wolfgang, Timur, Simon, Wolfgang Denk wrote: Dear Simon Glass, In message capnjgz2klpfmzzwghkdj4el+wixqlv89+cvdvp7pccy+xfa...@mail.gmail.com you wrote: I was really hoping we could get rid of the concept of a current i2c adapter, and just force all drivers to specify the I2C adapter they want to use for a given I2C operation. =A0That's how Linux operates, and it will prevent stuff like this: I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO. Let's do one step at a time. Now we go for multi-bus support. Ok. Implementing a new, better device interface is one of the next steps, then. Some thoughts to the subject get rid of concept of a current i2c - First, it would be great to get rid of that ;-) - 2 reasons why we currently need the info, what is the current i2c adapter/i2c bus: - U-Boot principle says, don't init a device, if you don't use it. So, if we switch to another i2c adapter or i2c bus (A i2c bus is a combination if one i2c adpater and n i2c muxes), we must deinit the current adapter/bus. Ok, current code didn't this too, but this should a goal to keep in mind ... or we define, that this is not needed. - If we have i2c muxes, and you don't know your current i2c bus, you must on every i2c access also setup the i2c muxes on this i2c bus ... would we do this really? Ignoring muxes, we can have more than one i2c adaptor inited at a time (i.e. de-initing is optional). Ok for the point more adapters inited at one time. But we have to setup the muxes every time! We cannot ignore this. Perhaps reword this slightly. U-Boot can have knowledge of a current adaptor, mux settings and so on, and use this internally within the i2c layer to optimise performance and redundant i2c traffic. But the Ok, thats what I mean. The cur_i2c_bus pointer should only be used in the i2c subsystem! This pointer is in gd_t because it must be writeable, also when running from flash ... pain is when the concept of a 'current adaptor' is exposed outside the i2c layer. The cur_i2c_bus pointer is only used inside the i2c subsystem. if we have the current i2c bus info, we just have to check, if we are on this bus, and do the i2c access ... if we are not on this i2c bus, we can deinit it complete (the new i2c_core disconnects for example all i2c muxes on the i2c bus) and init the new bus. All this work is done in a central function i2c_set_bus_numer() Yes but this function could become internal perhaps. Yes, if we make the change, Timur suggested ... but that can be done easy in a second step, as Wolfgang mentioned. - Looking in the new multibus i2c_core.c file, we should get rid of static unsigned int i2c_cur_bus __attribute__((section(.data))) = CONFIG_SYS_SPD_BUS_NUM; and cur_adap renamed to cur_i2c_bus and should be a struct i2c_bus_hose pointer. Sounds good. Heiko do you have time to take over your two patches I sent and tidy them up, or should I continue? I did some work on this 2 patches, to get it working with soft_i2c.c driver ... I try to rework this suggestions in, and send it to the ML as a v2 ... if I do not find time, I speak up ;-) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
