Re: [U-Boot] [PATCH 2/4] EXYNOS4: Add pinmux support for I2C

[Heiko Schocher]

Hello Jeong,

On 12.12.2012 08:54, Jeong Hyeon Kim wrote:

From: Jeong-Hyeon Kimjh...@insignal.co.kr

This patch adds pinmux support for I2C channels

Signed-off-by: Jeong-Hyeon Kimjh...@insignal.co.kr
---
  arch/arm/cpu/armv7/exynos/pinmux.c |   51 
  1 file changed, 51 insertions(+)


similiar patch is applied to u-boot-i2c, see:

http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commitdiff;h=4d4628dcaa51b501bec148a9c5c55df3920350dc

and pull request is pending. Can you check, if the above patch fits
your needs?

Thanks!

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] [DFU] Implement NAND dfu support

[Lukasz Majewski]

Hi Scott,

 On 12/11/2012 01:56:25 AM, Lukasz Majewski wrote:
  Hi Scott,
  
   On 12/10/2012 09:24:32 AM, Pantelis Antoniou wrote:
+   sprintf(cmd_buf, nand %s %p %llx %llx,
+   op == DFU_OP_READ ? read : write,
+buf, start, count);
+
+   debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
+   ret = run_command(cmd_buf, 0);
  
   Why not use the C interface to NAND?
  
  We also support there eMMC (both with raw and file systems).
  Moreover we had this discussion some time ago (if we shall use
  command or native C API).
 
 I don't see how nand %s %p %llx %llx supports anything that the
 NAND C API doesn't support.
 
 I can't follow every discussion that happens on this list, on the
 off chance it might eventually become relevant to NAND.  Some time
 ago is not an easily followed reference to the archives.

I understand. Please consult following thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134397


 
 -Scott



-- 
Best regards,

Lukasz Majewski

Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] One basic U-boot question

[Martin Peevski]

Hello, I have the following question. It is about the adresses 
where the U-boot and  Linux Kernel are copyed in the SDRAM from NAND.


In my board config file I have:
#define CONFIG_SYS_LOAD_ADDR0x2200/* load address */
Is that the load address of the U-boot?

Also where is defined the load address of the Kernel because may be 
I need to leave more free space about the Kernel and RootFS?


Thanks in advance!
Martin Peevski

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 1/4] Exynos5: Add clock support for SATA

[Vasanth Ananthan]

This patch adds clock support for SATA

Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
 arch/arm/cpu/armv7/exynos/clock.c  |   64 
 arch/arm/include/asm/arch-exynos/clk.h |3 +-
 2 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index fe61f88..db68ef0 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -26,6 +26,7 @@
 #include asm/arch/clock.h
 #include asm/arch/clk.h
 #include asm/arch/periph.h
+#include asm/errno.h
 
 /* Epll Clock division values to achive different frequency output */
 static struct set_epll_con_val exynos5_epll_div[] = {
@@ -326,6 +327,53 @@ static unsigned long exynos4_get_uart_clk(int dev_index)
return uclk;
 }
 
+/* Sets clocks related to SATA */
+static int exynos5_set_sata_clk(void)
+{
+   struct exynos5_clock *clk =
+   (struct exynos5_clock *)samsung_get_base_clock();
+   u32 tmp;
+
+   /* Setting src as MPLL_USER */
+   tmp = readl(clk-src_fsys);
+   tmp = ~(1  24);
+   writel(tmp, clk-src_fsys);
+
+   /* Unmasking SATA clk */
+   tmp = readl(clk-src_mask_fsys);
+   tmp |= (1  24);
+   writel(tmp, clk-src_mask_fsys);
+
+   /* Set divider value for getting sclk as 66 MHz */
+   tmp = readl(clk-div_fsys0);
+   tmp |= (0xB  20);
+
+   return 0;
+}
+
+/* Returns the clock frequency in Hz */
+static unsigned long exynos5_get_sata_clk(void)
+{
+   struct exynos5_clock *clk =
+   (struct exynos5_clock *)samsung_get_base_clock();
+   unsigned long uclk, sclk;
+   u32 ratio, tmp;
+
+   tmp = readl(clk-src_fsys);
+
+   if ((tmp  (1  24)) == 0)
+   sclk = get_pll_clk(MPLL);
+   else
+   sclk = get_pll_clk(BPLL);
+
+   ratio = readl(clk-div_fsys0);
+   ratio = (ratio  20)  0xf;
+
+   uclk = sclk / (ratio + 1);
+
+   return uclk;
+}
+
 /* exynos5: return uart clock frequency */
 static unsigned long exynos5_get_uart_clk(int dev_index)
 {
@@ -963,6 +1011,22 @@ unsigned long get_uart_clk(int dev_index)
return exynos4_get_uart_clk(dev_index);
 }
 
+unsigned long get_sata_clk(void)
+{
+   if (cpu_is_exynos5())
+   return exynos5_get_sata_clk();
+
+   return -ENOSYS;
+}
+
+void set_sata_clk(void)
+{
+   if (cpu_is_exynos5())
+   return exynos5_set_sata_clk();
+
+   return -ENOSYS;
+}
+
 void set_mmc_clk(int dev_index, unsigned int div)
 {
if (cpu_is_exynos5())
diff --git a/arch/arm/include/asm/arch-exynos/clk.h 
b/arch/arm/include/asm/arch-exynos/clk.h
index cd12323..10f28cc 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -42,5 +42,6 @@ void set_i2s_clk_source(void);
 int set_i2s_clk_prescaler(unsigned int src_frq, unsigned int dst_frq);
 int set_epll_clk(unsigned long rate);
 int set_spi_clk(int periph_id, unsigned int rate);
-
+unsigned long get_sata_clk(void);
+void set_sata_clk(void);
 #endif
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 2/4] Exynos5: Add base addresses for SATA

[Vasanth Ananthan]

This patch adds the macro definition of SATA controller and PHY controller
base addresses.

Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
 arch/arm/include/asm/arch-exynos/cpu.h|3 +++
 arch/arm/include/asm/arch-exynos/periph.h |1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index d1b2ea8..6ea1230 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -80,8 +80,11 @@
 #define EXYNOS5_USB_HOST_EHCI_BASE 0x1211
 #define EXYNOS5_USBPHY_BASE0x1213
 #define EXYNOS5_USBOTG_BASE0x1214
+#define EXYNOS5_SATA_PHY_BASE   0x1217
+#define EXYNOS5_SATA_PHY_I2C0x121D
 #define EXYNOS5_MMC_BASE   0x1220
 #define EXYNOS5_SROMC_BASE 0x1225
+#define EXYNOS5_SATA_BASE   0x122F
 #define EXYNOS5_UART_BASE  0x12C0
 #define EXYNOS5_I2C_BASE   0x12C6
 #define EXYNOS5_SPI_BASE   0x12D2
diff --git a/arch/arm/include/asm/arch-exynos/periph.h 
b/arch/arm/include/asm/arch-exynos/periph.h
index 13abd2d..58dc675 100644
--- a/arch/arm/include/asm/arch-exynos/periph.h
+++ b/arch/arm/include/asm/arch-exynos/periph.h
@@ -54,6 +54,7 @@ enum periph_id {
PERIPH_ID_UART1,
PERIPH_ID_UART2,
PERIPH_ID_UART3,
+   PERIPH_ID_SATA,
 
PERIPH_ID_COUNT,
PERIPH_ID_NONE = -1,
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 3/4] Drivers: block: Support for SATA in Exynos5

[Vasanth Ananthan]

This patch provides support for SATA in Exynos5250

Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
 drivers/block/dwc_ahsata.c |  397 ++--
 1 file changed, 387 insertions(+), 10 deletions(-)

diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index c9b71f7..58537d3 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -35,6 +35,64 @@
 #include asm/arch/clock.h
 #include dwc_ahsata.h
 
+#ifdef SATA_DEBUG
+#define debug(fmt, args...)printf(fmt, ##args)
+#else
+#define debug(fmt, args...)
+#endif /* MKIMAGE_DEBUG */
+
+#define MAX_DATA_BYTES_PER_SG  (4 * 1024 * 1024)
+#define MAX_BYTES_PER_TRANS (AHCI_MAX_SG * MAX_DATA_BYTES_PER_SG)
+
+#define writel_with_flush(a, b)do { writel(a, b); readl(b); } while (0)
+
+#define EXYNOS5_SATA_PHY_CONTROL   (0x1004 + 0x724)
+#define S5P_PMU_SATA_PHY_CONTROL_EN0x1
+
+#define SATA_TIME_LIMIT1
+#define SATA_PHY_I2C_SLAVE_ADDRS   0x70
+
+#define SATA_RESET 0x4
+#define RESET_CMN_RST_N(1  1)
+#define LINK_RESET 0xFF
+
+#define SATA_MODE0 0x10
+
+#define SATA_CTRL0 0x14
+#define CTRL0_P0_PHY_CALIBRATED_SEL(1  9)
+#define CTRL0_P0_PHY_CALIBRATED(1  8)
+
+#define SATA_PHSATA_CTRLM  0xE0
+#define PHCTRLM_REF_RATE   (1  1)
+#define PHCTRLM_HIGH_SPEED (1  0)
+
+#define SATA_PHSATA_STATM  0xF0
+#define PHSTATM_PLL_LOCKED (1  0)
+
+#define SATA_I2C_CON   0x00
+#define SATA_I2C_STAT  0x04
+#define SATA_I2C_ADDR  0x08
+#define SATA_I2C_DS0x0C
+#define SATA_I2C_LC0x10
+
+/* I2CCON reg */
+#define CON_ACKEN  (1  7)
+#define CON_CLK512 (1  6)
+#define CON_CLK16  (~CON_CLK512)
+#define CON_INTEN  (1  5)
+#define CON_INTPND (1  4)
+#define CON_TXCLK_PS   (0xF)
+
+/* I2CSTAT reg */
+#define STAT_MSTT  (0x3  6)
+#define STAT_BSYST (1  5)
+#define STAT_RTEN  (1  4)
+#define STAT_LAST  (1  0)
+
+#define LC_FLTR_EN (1  2)
+
+#define SATA_PHY_CON_RESET 0xF003F
+
 struct sata_port_regs {
u32 clb;
u32 clbu;
@@ -88,10 +146,243 @@ struct sata_host_regs {
u32 idr;
 };
 
-#define MAX_DATA_BYTES_PER_SG  (4 * 1024 * 1024)
-#define MAX_BYTES_PER_TRANS (AHCI_MAX_SG * MAX_DATA_BYTES_PER_SG)
+void * const phy_ctrl = (void *)EXYNOS5_SATA_PHY_BASE;
+void * const phy_i2c_base = (void *)EXYNOS5_SATA_PHY_I2C;
 
-#define writel_with_flush(a, b)do { writel(a, b); readl(b); } while (0)
+enum {
+   SATA_GENERATION1,
+   SATA_GENERATION2,
+   SATA_GENERATION3,
+};
+
+static u8 sata_is_reg(void *base, u32 reg, u32 checkbit, u32 status)
+{
+   if ((readl(base + reg)  checkbit) == status)
+   return 1;
+   else
+   return 0;
+}
+
+static u8 wait_for_reg_status(void *base, u32 reg, u32 checkbit,
+   u32 status)
+{
+   u32 time_limit_cnt = 0;
+   while (!sata_is_reg(base, reg, checkbit, status)) {
+   if (time_limit_cnt == SATA_TIME_LIMIT)
+   return 0;
+   udelay(1000);
+   time_limit_cnt++;
+   }
+   return 1;
+}
+
+static void sata_set_gen(u8 gen)
+{
+   writel(gen, phy_ctrl + SATA_MODE0);
+}
+
+/* Address :I2C Address */
+static void sata_i2c_write_addrs(u8 data)
+{
+   writeb((data  0xFE), phy_i2c_base + SATA_I2C_DS);
+}
+
+static void sata_i2c_write_data(u8 data)
+{
+   writeb((data), phy_i2c_base + SATA_I2C_DS);
+}
+
+static void sata_i2c_start(void)
+{
+   u32 val;
+   val = readl(phy_i2c_base + SATA_I2C_STAT);
+   val |= STAT_BSYST;
+   writel(val, phy_i2c_base + SATA_I2C_STAT);
+}
+
+static void sata_i2c_stop(void)
+{
+   u32 val;
+   val = readl(phy_i2c_base + SATA_I2C_STAT);
+   val = ~STAT_BSYST;
+   writel(val, phy_i2c_base + SATA_I2C_STAT);
+}
+
+static u8 sata_i2c_get_int_status(void)
+{
+   if ((readl(phy_i2c_base + SATA_I2C_CON))  CON_INTPND)
+   return 1;
+   else
+   return 0;
+}
+
+static u8 sata_i2c_is_tx_ack(void)
+{
+   if ((readl(phy_i2c_base + SATA_I2C_STAT))  STAT_LAST)
+   return 0;
+   else
+   return 1;
+}
+
+static u8 sata_i2c_is_bus_ready(void)
+{
+   if ((readl(phy_i2c_base + SATA_I2C_STAT))  STAT_BSYST)
+   return 0;
+   else
+   return 1;
+}
+
+static u8 sata_i2c_wait_for_busready(u32 time_out)
+{
+   while (--time_out) {
+   if (sata_i2c_is_bus_ready())
+   return 1;
+   udelay(100);
+   }
+   return 

[U-Boot] [PATCH v3 4/4] SMDK55250: Enable SATA

[Vasanth Ananthan]

This patch adds required macros for enabling SATA.

Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
 include/configs/smdk5250.h |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..67cdbe2 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -68,7 +68,7 @@
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (1  20))
 
 /* select serial console configuration */
-#define CONFIG_SERIAL3 /* use SERIAL 3 */
+#define CONFIG_SERIAL2 /* use SERIAL 2 */
 #define CONFIG_BAUDRATE115200
 #define EXYNOS5_DEFAULT_UART_OFFSET0x01
 
@@ -97,6 +97,7 @@
 #define CONFIG_CMD_EXT2
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_NET
+#define CONFIG_CMD_SATA
 
 #define CONFIG_BOOTDELAY   3
 #define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -192,8 +193,6 @@
 #define EXYNOS_COPY_SPI_FNPTR_ADDR 0x02020058
 #define SPI_FLASH_UBOOT_POS(CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE)
 
-#define CONFIG_DOS_PARTITION
-
 #define CONFIG_IRAM_STACK  0x0205
 
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
@@ -259,4 +258,14 @@
 /* Enable devicetree support */
 #define CONFIG_OF_LIBFDT
 
+/* Enable SATA */
+#ifdef CONFIG_CMD_SATA
+   #define CONFIG_DWC_AHSATA
+   #define CONFIG_SYS_SATA_MAX_DEVICE  1
+   #define CONFIG_DWC_AHSATA_PORT_ID   0
+   #define CONFIG_DWC_AHSATA_BASE_ADDR EXYNOS5_SATA_BASE
+   #define CONFIG_LBA48
+   #define CONFIG_LIBATA
+#endif
+
 #endif /* __CONFIG_H */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] imls: Add support to list images in NAND device

[Vipin Kumar]

imls does not list the images in NAND devices. This patch implements this
support for legacy type images.

Signed-off-by: Vipin Kumar vipin.ku...@st.com
---
Hello Scott,

There has been sometime since you reviewed the first version of this patch.
http://lists.denx.de/pipermail/u-boot/2012-November/139631.html

I am sorry for a late response on this. I was waiting for other comments if any
on the whole patch-set

Regards
Vipin

 README |   3 +-
 common/cmd_bootm.c | 133 -
 2 files changed, 134 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 2077c3b..ec5c31e 100644
--- a/README
+++ b/README
@@ -831,7 +831,8 @@ The following options need to be configured:
CONFIG_CMD_I2C  * I2C serial bus support
CONFIG_CMD_IDE  * IDE harddisk support
CONFIG_CMD_IMIiminfo
-   CONFIG_CMD_IMLS   List all found images
+   CONFIG_CMD_IMLS   List all images found in flash
+   CONFIG_CMD_IMLS_NAND  List all images found in NAND device
CONFIG_CMD_IMMAP* IMMR dump support
CONFIG_CMD_IMPORTENV* import an environment
CONFIG_CMD_INI  * import data from an ini file into the 
env
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d256ddf..8ee562a 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -83,6 +83,9 @@ extern flash_info_t flash_info[]; /* info for FLASH chips */
 static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 #endif
 
+#include linux/err.h
+#include nand.h
+
 #ifdef CONFIG_SILENT_CONSOLE
 static void fixup_silent_linux(void);
 #endif
@@ -1175,7 +1178,7 @@ U_BOOT_CMD(
 /* imls - list all images found in flash */
 /***/
 #if defined(CONFIG_CMD_IMLS)
-static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+static void do_imls_flash(void)
 {
flash_info_t *info;
int i, j;
@@ -1224,6 +1227,134 @@ next_sector:;
}
 next_bank: ;
}
+}
+#endif
+
+#if defined(CONFIG_CMD_IMLS_NAND)
+static void do_imls_nand(void)
+{
+   nand_info_t *nand;
+   int nand_dev = nand_curr_device;
+   size_t read_size;
+   loff_t off;
+   u8 buffer[512];
+   const image_header_t *header = (const image_header_t *)buffer;
+
+   /* the following commands operate on the current device */
+   if (nand_dev  0 || nand_dev = CONFIG_SYS_MAX_NAND_DEVICE) {
+   puts(\nNo NAND devices available\n);
+   return;
+   }
+
+   printf(\n);
+
+   for (nand_dev = 0; nand_dev  CONFIG_SYS_MAX_NAND_DEVICE; nand_dev++) {
+
+   nand = nand_info[nand_dev];
+   if (!nand-name || !nand-size)
+   continue;
+
+   for (off = 0; off  nand-size; off += nand-erasesize) {
+   int ret;
+   void *imgdata;
+
+   if (nand_block_isbad(nand, off))
+   goto next_block;
+
+   read_size = sizeof(buffer);
+
+   ret = nand_read(nand, off, read_size, buffer);
+   if (ret  0  ret != -EUCLEAN)
+   goto next_block;
+
+   header = (const image_header_t *)buffer;
+
+   switch (genimg_get_format(buffer)) {
+   case IMAGE_FORMAT_LEGACY:
+   if (!image_check_hcrc(header))
+   goto next_block;
+
+   read_size = image_get_image_size(header);
+
+   imgdata = malloc(read_size);
+   if (!imgdata) {
+   printf(Not able to list all images  \
+   (Low memory)\n);
+   goto next_block;
+   }
+
+   ret = nand_read_skip_bad(nand, off, read_size,
+   imgdata);
+   if (ret  0  ret != -EUCLEAN) {
+   free(imgdata);
+   goto next_block;
+   }
+
+   printf(Legacy Image at NAND device %d  \
+   offset %08llX:\n, nand_dev, off);
+   image_print_contents(imgdata);
+
+   puts(   Verifying Checksum ... );
+   if (!image_check_dcrc(imgdata))
+   puts(Bad Data CRC\n);
+   else
+   puts(OK\n);
+
+   

Re: [U-Boot] [PATCH v2] usbh/ehci: Increase timeout for enumeration

[Vipin Kumar]

+   ulong start = get_timer(0);
+
+   do {
+   ret = usb_get_port_status(dev, i + 1, portsts);
+   if (ret  0) {
+   USB_HUB_PRINTF(get_port_status failed\n);
+   break;
+   }
+
+   portstatus = le16_to_cpu(portsts-wPortStatus);
+   portchange = le16_to_cpu(portsts-wPortChange);
+
+   if ((portchange  USB_PORT_STAT_C_CONNECTION) ==
+   (portstatus  USB_PORT_STAT_CONNECTION))


I don't know if there is any corner case when the above check
will always fail and so it will always wait a maximal delay time.
Are those registers that identical, or can there be differences?


+   break;
+
+   mdelay(100);
+   } while (get_timer(start)  CONFIG_SYS_HZ * 10);


Is there any justification for the CONFIG_SYS_HZ * 10?
I would be much more fine with this patch if there were any
(even just test based * 2) reason for that number.



Not really. Just a practical test.
Marek, can I have comments from you as well

Thanks
Vipin

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] sdhci: Add sdhci support for spear devices

[Vipin Kumar]

Stefan, Wolfgang,

Can you please add relevant people if not present already in this mail

Regards
Vipin

On 12/6/2012 12:14 PM, Vipin KUMAR wrote:

Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
  drivers/mmc/Makefile  |  1 +
  drivers/mmc/spear_sdhci.c | 44 
  2 files changed, 45 insertions(+)
  create mode 100644 drivers/mmc/spear_sdhci.c

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index a1dd730..01dd61d 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -45,6 +45,7 @@ COBJS-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
  COBJS-$(CONFIG_SDHCI) += sdhci.o
  COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o
  COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o
+COBJS-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
  COBJS-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
  COBJS-$(CONFIG_DWMMC) += dw_mmc.o

diff --git a/drivers/mmc/spear_sdhci.c b/drivers/mmc/spear_sdhci.c
new file mode 100644
index 000..23f1f4b
--- /dev/null
+++ b/drivers/mmc/spear_sdhci.c
@@ -0,0 +1,44 @@
+/*
+ * (C) Copyright 2012
+ * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#includecommon.h
+#includemalloc.h
+#includesdhci.h
+
+int spear_sdhci_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
+{
+   struct sdhci_host *host = NULL;
+   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
+   if (!host) {
+   printf(sdhci host malloc fail!\n);
+   return 1;
+   }
+
+   host-name = sdhci;
+   host-ioaddr = (void *)regbase;
+   host-quirks = quirks;
+
+   if (quirks  SDHCI_QUIRK_REG32_RW)
+   host-version = sdhci_readl(host, SDHCI_HOST_VERSION - 2)  16;
+   else
+   host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+   add_sdhci(host, max_clk, min_clk);
+   return 0;
+}


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] spi/arm-pl022: Add support for ARM PL022 spi controller

[Vipin Kumar]

Ping. Can I get a few Reviewed-by's :)

On 12/6/2012 1:35 PM, Stefan Roese wrote:

(Added Mike to Cc)

On 12/06/2012 07:56 AM, Vipin Kumar wrote:

From: Armando Viscontiarmando.visco...@st.com

This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.

Signed-off-by: Armando Viscontiarmando.visco...@st.com
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---

Dear Wolfgang, Stefan,

There seems to be no direct owner of spi framework. So, I am directing this
patch to you


IIRC, Mike Frysinger did a bit of SPI maintenance in the last years.
Perhaps he can comment. Mike, still around?

Thanks,
Stefan




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend 1/2] net/designware: Do not select MIIPORT for RGMII interface

[Vipin Kumar]

ping

On 12/6/2012 12:40 PM, Vipin KUMAR wrote:

Do not select MIIPORT for RGMII interface

Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
  drivers/net/designware.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index bf21a08..46f6601 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -113,7 +113,9 @@ static int mac_reset(struct eth_device *dev)
int timeout = CONFIG_MACRESET_TIMEOUT;

writel(DMAMAC_SRST,dma_p-busmode);
-   writel(MII_PORTSELECT,mac_p-conf);
+
+   if (priv-interface != PHY_INTERFACE_MODE_RGMII)
+   writel(MII_PORTSELECT,mac_p-conf);

start = get_timer(0);
while (get_timer(start)  timeout) {


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus

[Vipin Kumar]

ping

On 12/6/2012 2:52 PM, Vipin KUMAR wrote:

Certain ARMV7 cpus eg. CortexA9 contains a local and a global timer within the
CPU core itself.  This patch adds generic support for local timer.

Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
  arch/arm/cpu/armv7/Makefile   |  11 ++-
  arch/arm/cpu/armv7/ca9_ltimer.c   | 152 ++
  arch/arm/include/asm/ca9_ltimer.h |  40 ++
  3 files changed, 199 insertions(+), 4 deletions(-)
  create mode 100644 arch/arm/cpu/armv7/ca9_ltimer.c
  create mode 100644 arch/arm/include/asm/ca9_ltimer.h

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4fdbee4..3ef01f6 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -27,15 +27,18 @@ LIB = $(obj)lib$(CPU).o

  START := start.o

-COBJS  += cache_v7.o
+COBJS-y+= cache_v7.o

-COBJS  += cpu.o
-COBJS  += syslib.o
+COBJS-y+= cpu.o
+COBJS-y+= syslib.o
+COBJS-$(CONFIG_ARMV7_CA9LTIMER) += ca9_ltimer.o

  ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA20),)
-SOBJS  += lowlevel_init.o
+SOBJS-y+= lowlevel_init.o
  endif

+COBJS  := $(sort $(COBJS-y))
+SOBJS  := $(sort $(SOBJS-y))
  SRCS  := $(START:.o=.S) $(COBJS:.o=.c)
  OBJS  := $(addprefix $(obj),$(COBJS) $(SOBJS))
  START := $(addprefix $(obj),$(START))
diff --git a/arch/arm/cpu/armv7/ca9_ltimer.c b/arch/arm/cpu/armv7/ca9_ltimer.c
new file mode 100644
index 000..cbf1552
--- /dev/null
+++ b/arch/arm/cpu/armv7/ca9_ltimer.c
@@ -0,0 +1,152 @@
+/*
+ * (C) Copyright 2012
+ * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.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
+ */
+
+#includecommon.h
+#includeasm/io.h
+#includeasm/ca9_ltimer.h
+#includeasm/arch/hardware.h
+
+#define READ_TIMER()   readl(ca9_timer_p-count)
+
+static struct ca9_timer_regs *const ca9_timer_p =
+   (struct ca9_timer_regs *)CONFIG_ARMV7_LTIMER_BASE;
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define timestamp  gd-tbl
+#define lastdecgd-lastinc
+#define tickshzgd-timer_rate_hz
+#define ticksper10usec gd-tbu
+
+int timer_init(void)
+{
+   u32 prescaler, timertickshz;
+   /*
+* Genrally, CortexA9 MPUs are operating from 500MHz to 1500MHz which
+* means that CA9 local timer clock would be in the range of 250 MHz to
+* 750MHz.
+* Try to find a prescaler which can perfectly divide the local timer
+* clock. Take prescaler as 200 if nothing is found
+*/
+   for (prescaler = 255; prescaler  1; prescaler--) {
+   if (CONFIG_ARMV7_LTMR_CLK ==
+   (CONFIG_ARMV7_LTMR_CLK / prescaler) * prescaler)
+   break;
+   }
+
+   if (prescaler == 1)
+   prescaler = 200;
+   timertickshz = CONFIG_ARMV7_LTMR_CLK / prescaler;
+   ticksper10usec = timertickshz / (100 * 1000);
+   tickshz = timertickshz / CONFIG_SYS_HZ;
+
+   /* disable timers */
+   writel(((prescaler - 1)  8) | AUTO_RELOAD,ca9_timer_p-control);
+
+   /* load value for free running */
+   writel(FREE_RUNNING,ca9_timer_p-load);
+
+   /* auto reload, start timer */
+   setbits_le32(ca9_timer_p-control, TIMER_ENABLE);
+
+   reset_timer_masked();
+
+   return 0;
+}
+
+/*
+ * timer without interrupts
+ */
+
+void reset_timer(void)
+{
+   reset_timer_masked();
+}
+
+ulong get_timer(ulong base)
+{
+   return (get_timer_masked() / tickshz) - base;
+}
+
+void set_timer(ulong t)
+{
+   timestamp = t;
+}
+
+void __udelay(unsigned long usec)
+{
+   ulong tmo;
+   ulong start = get_timer_masked();
+   ulong rndoff;
+
+   rndoff = (usec % 10) ? 1 : 0;
+   tmo = ((usec / 10) + rndoff) * ticksper10usec;
+
+   while ((ulong) (get_timer_masked() - start)  tmo);
+}
+
+void reset_timer_masked(void)
+{
+   /* reset time */
+   lastdec = READ_TIMER();
+   timestamp = 0;
+}
+
+ulong get_timer_masked(void)
+{
+   ulong now = READ_TIMER();
+
+   if (now= lastdec) {
+   /* normal mode */
+   timestamp += lastdec - now;
+   } else {
+   /* we have an overflow ... */
+   

Re: [U-Boot] [PATCH resend] sdhci: Add sdhci support for spear devices

[Stefan Roese]

On 12/06/2012 07:44 AM, Vipin Kumar wrote:
 Signed-off-by: Vipin Kumar vipin.ku...@st.com

Looks good, so:

Acked-by: Stefan Roese s...@denx.de

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend 1/2] net/designware: Do not select MIIPORT for RGMII interface

[Stefan Roese]

On 12/06/2012 08:10 AM, Vipin Kumar wrote:
 Do not select MIIPORT for RGMII interface
 
 Signed-off-by: Vipin Kumar vipin.ku...@st.com

Acked-by: Stefan Roese s...@denx.de

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] sdhci: Add sdhci support for spear devices

[Jaehoon Chung]

I didn't test..but it looks fine.

Acked-by: Jaehoon Chung jh80.ch...@samsung.com

On 12/06/2012 03:44 PM, Vipin Kumar wrote:
 Signed-off-by: Vipin Kumar vipin.ku...@st.com
 ---
  drivers/mmc/Makefile  |  1 +
  drivers/mmc/spear_sdhci.c | 44 
  2 files changed, 45 insertions(+)
  create mode 100644 drivers/mmc/spear_sdhci.c
 
 diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
 index a1dd730..01dd61d 100644
 --- a/drivers/mmc/Makefile
 +++ b/drivers/mmc/Makefile
 @@ -45,6 +45,7 @@ COBJS-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
  COBJS-$(CONFIG_SDHCI) += sdhci.o
  COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o
  COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o
 +COBJS-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
  COBJS-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
  COBJS-$(CONFIG_DWMMC) += dw_mmc.o
  
 diff --git a/drivers/mmc/spear_sdhci.c b/drivers/mmc/spear_sdhci.c
 new file mode 100644
 index 000..23f1f4b
 --- /dev/null
 +++ b/drivers/mmc/spear_sdhci.c
 @@ -0,0 +1,44 @@
 +/*
 + * (C) Copyright 2012
 + * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + */
 +
 +#include common.h
 +#include malloc.h
 +#include sdhci.h
 +
 +int spear_sdhci_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
 +{
 + struct sdhci_host *host = NULL;
 + host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
 + if (!host) {
 + printf(sdhci host malloc fail!\n);
 + return 1;
 + }
 +
 + host-name = sdhci;
 + host-ioaddr = (void *)regbase;
 + host-quirks = quirks;
 +
 + if (quirks  SDHCI_QUIRK_REG32_RW)
 + host-version = sdhci_readl(host, SDHCI_HOST_VERSION - 2)  16;
 + else
 + host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
 +
 + add_sdhci(host, max_clk, min_clk);
 + return 0;
 +}
 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] spi/arm-pl022: Add support for ARM PL022 spi controller

[Stefan Roese]

On 12/06/2012 07:56 AM, Vipin Kumar wrote:
 From: Armando Visconti armando.visco...@st.com
 
 This patch adds the support for the ARM PL022 SPI controller for the standard
 variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.
 
 Signed-off-by: Armando Visconti armando.visco...@st.com
 Signed-off-by: Vipin Kumar vipin.ku...@st.com
 ---
 
 Dear Wolfgang, Stefan,
 
 There seems to be no direct owner of spi framework. So, I am directing this
 patch to you

A few comments below.

 Regards
 Vipin
 
  drivers/spi/Makefile|   1 +
  drivers/spi/pl022_spi.c | 308 
 
  2 files changed, 309 insertions(+)
  create mode 100644 drivers/spi/pl022_spi.c
 
 diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
 index 824d357..3a4e4b0 100644
 --- a/drivers/spi/Makefile
 +++ b/drivers/spi/Makefile
 @@ -42,6 +42,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
  COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
  COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
  COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 +COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
  COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
  COBJS-$(CONFIG_SH_SPI) += sh_spi.o
  COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
 diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
 new file mode 100644
 index 000..3ea769a
 --- /dev/null
 +++ b/drivers/spi/pl022_spi.c
 @@ -0,0 +1,308 @@
 +/*
 + * (C) Copyright 2012
 + * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
 + *
 + * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
 + * by Atmel Corporation.
 + *
 + * 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 malloc.h
 +#include spi.h
 +#include asm/io.h
 +#include asm/arch/hardware.h
 +
 +/* SSP registers mapping */
 +#define SSP_CR0  0x000
 +#define SSP_CR1  0x004
 +#define SSP_DR   0x008
 +#define SSP_SR   0x00C
 +#define SSP_CPSR 0x010
 +#define SSP_IMSC 0x014
 +#define SSP_RIS  0x018
 +#define SSP_MIS  0x01C
 +#define SSP_ICR  0x020
 +#define SSP_DMACR0x024
 +#define SSP_ITCR 0x080
 +#define SSP_ITIP 0x084
 +#define SSP_ITOP 0x088
 +#define SSP_TDR  0x08C

Please use C-structs instead to access the registers.

 +#define SSP_PID0 0xFE0
 +#define SSP_PID1 0xFE4
 +#define SSP_PID2 0xFE8
 +#define SSP_PID3 0xFEC
 +
 +#define SSP_CID0 0xFF0
 +#define SSP_CID1 0xFF4
 +#define SSP_CID2 0xFF8
 +#define SSP_CID3 0xFFC
 +
 +/* SSP Control Register 0  - SSP_CR0 */
 +#define SSP_CR0_SPO  (0x1  6)
 +#define SSP_CR0_SPH  (0x1  7)
 +#define SSP_CR0_8BIT_MODE(0x07)
 +#define SSP_SCR_MAX  (0xFF)
 +#define SSP_SCR_SHFT 8
 +
 +/* SSP Control Register 0  - SSP_CR1 */
 +#define SSP_CR1_MASK_SSE (0x1  1)
 +
 +#define SSP_CPSR_MAX (0xFE)
 +
 +/* SSP Status Register - SSP_SR */
 +#define SSP_SR_MASK_TFE  (0x1  0) /* Transmit FIFO empty */
 +#define SSP_SR_MASK_TNF  (0x1  1) /* Transmit FIFO not full */
 +#define SSP_SR_MASK_RNE  (0x1  2) /* Receive FIFO not empty */
 +#define SSP_SR_MASK_RFF  (0x1  3) /* Receive FIFO full */
 +#define SSP_SR_MASK_BSY  (0x1  4) /* Busy Flag */
 +
 +struct pl022_spi_slave {
 + struct spi_slave slave;
 + void *regs;
 + unsigned int freq;
 +};
 +
 +static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
 +{
 + return container_of(slave, struct pl022_spi_slave, slave);
 +}
 +
 +/*
 + * Following three functions should be provided by the
 + * board support package.
 + */
 +int spi_cs_is_valid(unsigned int bus, unsigned int cs)
 + __attribute__((weak, alias(__spi_cs_is_valid)));
 +void spi_cs_activate(struct spi_slave *slave)
 + __attribute__((weak, alias(__spi_cs_activate)));
 +void spi_cs_deactivate(struct spi_slave *slave)
 + __attribute__((weak, alias(__spi_cs_deactivate)));

__weak from linux/compiler.h

 +int __spi_cs_is_valid(unsigned int bus, unsigned int cs)
 +{
 + return 1;
 +}
 +
 +void __spi_cs_activate(struct spi_slave *slave)
 +{
 + /* do nothing */
 +}
 +
 +void __spi_cs_deactivate(struct spi_slave *slave)
 +{
 + /* do nothing */
 +}
 +
 +void 

Re: [U-Boot] [PATCH resend] spi/arm-pl022: Add support for ARM PL022 spi controller

[Vipin Kumar]

On 12/12/2012 3:48 PM, Stefan Roese wrote:

On 12/06/2012 07:56 AM, Vipin Kumar wrote:

From: Armando Viscontiarmando.visco...@st.com

This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.

Signed-off-by: Armando Viscontiarmando.visco...@st.com
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---

Dear Wolfgang, Stefan,

There seems to be no direct owner of spi framework. So, I am directing this
patch to you


A few comments below.


Regards
Vipin

  drivers/spi/Makefile|   1 +
  drivers/spi/pl022_spi.c | 308 
  2 files changed, 309 insertions(+)
  create mode 100644 drivers/spi/pl022_spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 824d357..3a4e4b0 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
  COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
  COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
  COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
  COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
  COBJS-$(CONFIG_SH_SPI) += sh_spi.o
  COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
new file mode 100644
index 000..3ea769a
--- /dev/null
+++ b/drivers/spi/pl022_spi.c
@@ -0,0 +1,308 @@
+/*
+ * (C) Copyright 2012
+ * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
+ *
+ * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
+ * by Atmel Corporation.
+ *
+ * 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
+ */
+
+#includecommon.h
+#includemalloc.h
+#includespi.h
+#includeasm/io.h
+#includeasm/arch/hardware.h
+
+/* SSP registers mapping */
+#define SSP_CR00x000
+#define SSP_CR10x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR   0x010
+#define SSP_IMSC   0x014
+#define SSP_RIS0x018
+#define SSP_MIS0x01C
+#define SSP_ICR0x020
+#define SSP_DMACR  0x024
+#define SSP_ITCR   0x080
+#define SSP_ITIP   0x084
+#define SSP_ITOP   0x088
+#define SSP_TDR0x08C


Please use C-structs instead to access the registers.



May be this patch is a ripped version from linux. That's why
Thanks. I will do this in v2


+#define SSP_PID0   0xFE0
+#define SSP_PID1   0xFE4
+#define SSP_PID2   0xFE8
+#define SSP_PID3   0xFEC
+
+#define SSP_CID0   0xFF0
+#define SSP_CID1   0xFF4
+#define SSP_CID2   0xFF8
+#define SSP_CID3   0xFFC
+
+/* SSP Control Register 0  - SSP_CR0 */
+#define SSP_CR0_SPO(0x1  6)
+#define SSP_CR0_SPH(0x1  7)
+#define SSP_CR0_8BIT_MODE  (0x07)
+#define SSP_SCR_MAX(0xFF)
+#define SSP_SCR_SHFT   8
+
+/* SSP Control Register 0  - SSP_CR1 */
+#define SSP_CR1_MASK_SSE   (0x1  1)
+
+#define SSP_CPSR_MAX   (0xFE)
+
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE(0x1  0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF(0x1  1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE(0x1  2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF(0x1  3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY(0x1  4) /* Busy Flag */
+
+struct pl022_spi_slave {
+   struct spi_slave slave;
+   void *regs;
+   unsigned int freq;
+};
+
+static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
+{
+   return container_of(slave, struct pl022_spi_slave, slave);
+}
+
+/*
+ * Following three functions should be provided by the
+ * board support package.
+ */
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+   __attribute__((weak, alias(__spi_cs_is_valid)));
+void spi_cs_activate(struct spi_slave *slave)
+   __attribute__((weak, alias(__spi_cs_activate)));
+void spi_cs_deactivate(struct spi_slave *slave)
+   __attribute__((weak, alias(__spi_cs_deactivate)));


__weak from linux/compiler.h



OK


+int __spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+   return 1;
+}
+
+void __spi_cs_activate(struct spi_slave *slave)
+{
+   /* do nothing */
+}
+
+void 

Re: [U-Boot] [PATCH resend 2/2] net/macb: Add arch specific routine to get mdio control

[Vipin Kumar]

ping. one more :)

On 12/6/2012 12:40 PM, Vipin KUMAR wrote:

From: Shiraz Hashimshiraz.has...@st.com

SPEAr310 and SPEAr320 Ethernet interfaces share same MDIO lines to control their
respective phys. Currently their is a fixed configuration in which only a
particular MAC can use the MDIO lines.

Call an arch specific function to take control of specific mdio lines at
runtime.

Signed-off-by: Shiraz Hashimshiraz.has...@st.com
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
  drivers/net/macb.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 8bacbda..45fbbd7 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -163,6 +163,13 @@ static u16 macb_mdio_read(struct macb_device *macb, u8 reg)
return MACB_BFEXT(DATA, frame);
  }

+static void __def_arch_get_mdio_control(const char *name)
+{
+   return;
+}
+int arch_get_mdio_control(const char *name)
+   __attribute__((weak, alias(__def_arch_get_mdio_control)));
+
  #if defined(CONFIG_CMD_MII)

  int macb_miiphy_read(const char *devname, u8 phy_adr, u8 reg, u16 *value)
@@ -173,6 +180,7 @@ int macb_miiphy_read(const char *devname, u8 phy_adr, u8 
reg, u16 *value)
if ( macb-phy_addr != phy_adr )
return -1;

+   arch_get_mdio_control(devname);
*value = macb_mdio_read(macb, reg);

return 0;
@@ -186,6 +194,7 @@ int macb_miiphy_write(const char *devname, u8 phy_adr, u8 
reg, u16 value)
if ( macb-phy_addr != phy_adr )
return -1;

+   arch_get_mdio_control(devname);
macb_mdio_write(macb, reg, value);

return 0;
@@ -377,6 +386,7 @@ static int macb_phy_init(struct macb_device *macb)
int media, speed, duplex;
int i;

+   arch_get_mdio_control(netdev-name);
  #ifdef CONFIG_MACB_SEARCH_PHY
/* Auto-detect phy_addr */
if (!macb_phy_find(macb)) {


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend 2/2] net/macb: Add arch specific routine to get mdio control

[Stefan Roese]

On 12/06/2012 08:10 AM, Vipin Kumar wrote:
 From: Shiraz Hashim shiraz.has...@st.com
 
 SPEAr310 and SPEAr320 Ethernet interfaces share same MDIO lines to control 
 their
 respective phys. Currently their is a fixed configuration in which only a
 particular MAC can use the MDIO lines.

there is instead of their is

 Call an arch specific function to take control of specific mdio lines at
 runtime.
 
 Signed-off-by: Shiraz Hashim shiraz.has...@st.com
 Signed-off-by: Vipin Kumar vipin.ku...@st.com
 ---
  drivers/net/macb.c | 10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/drivers/net/macb.c b/drivers/net/macb.c
 index 8bacbda..45fbbd7 100644
 --- a/drivers/net/macb.c
 +++ b/drivers/net/macb.c
 @@ -163,6 +163,13 @@ static u16 macb_mdio_read(struct macb_device *macb, u8 
 reg)
   return MACB_BFEXT(DATA, frame);
  }
  
 +static void __def_arch_get_mdio_control(const char *name)
 +{
 + return;
 +}
 +int arch_get_mdio_control(const char *name)
 + __attribute__((weak, alias(__def_arch_get_mdio_control)));

__weak from linux/compiler.h please

Otherwise:

Acked-by: Stefan Roese s...@denx.de

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] spi/arm-pl022: Add support for ARM PL022 spi controller

[Armando Visconti]

+
+/* SSP registers mapping */
+#define SSP_CR00x000
+#define SSP_CR10x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR   0x010
+#define SSP_IMSC   0x014
+#define SSP_RIS0x018
+#define SSP_MIS0x01C
+#define SSP_ICR0x020
+#define SSP_DMACR  0x024
+#define SSP_ITCR   0x080
+#define SSP_ITIP   0x084
+#define SSP_ITOP   0x088
+#define SSP_TDR0x08C


Please use C-structs instead to access the registers.



May be this patch is a ripped version from linux. That's why
Thanks. I will do this in v2



Yes,
I took this part from the linux pl022 driver.

Never understood which way (C-struct or defines) is preferable
and why...

Rgds,
Arm

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend 2/2] net/macb: Add arch specific routine to get mdio control

[Vipin Kumar]

On 12/12/2012 4:37 PM, Stefan Roese wrote:

On 12/06/2012 08:10 AM, Vipin Kumar wrote:

From: Shiraz Hashimshiraz.has...@st.com

SPEAr310 and SPEAr320 Ethernet interfaces share same MDIO lines to control their
respective phys. Currently their is a fixed configuration in which only a
particular MAC can use the MDIO lines.


there is instead of their is



Thanks. I would change this in v2


Call an arch specific function to take control of specific mdio lines at
runtime.

Signed-off-by: Shiraz Hashimshiraz.has...@st.com
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
  drivers/net/macb.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 8bacbda..45fbbd7 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -163,6 +163,13 @@ static u16 macb_mdio_read(struct macb_device *macb, u8 reg)
return MACB_BFEXT(DATA, frame);
  }

+static void __def_arch_get_mdio_control(const char *name)
+{
+   return;
+}
+int arch_get_mdio_control(const char *name)
+   __attribute__((weak, alias(__def_arch_get_mdio_control)));


__weak from linux/compiler.h please



in v2


Otherwise:

Acked-by: Stefan Roeses...@denx.de

Thanks,
Stefan




Vipin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] spi/arm-pl022: Add support for ARM PL022 spi controller

[Vipin Kumar]

On 12/12/2012 4:40 PM, Armando VISCONTI wrote:

+
+/* SSP registers mapping */
+#define SSP_CR0 0x000
+#define SSP_CR1 0x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR 0x010
+#define SSP_IMSC 0x014
+#define SSP_RIS 0x018
+#define SSP_MIS 0x01C
+#define SSP_ICR 0x020
+#define SSP_DMACR 0x024
+#define SSP_ITCR 0x080
+#define SSP_ITIP 0x084
+#define SSP_ITOP 0x088
+#define SSP_TDR 0x08C


Please use C-structs instead to access the registers.



May be this patch is a ripped version from linux. That's why
Thanks. I will do this in v2



Yes,
I took this part from the linux pl022 driver.

Never understood which way (C-struct or defines) is preferable
and why...



U-boot uses the structure way(I do not exactly understand why) and the 
kernel code uses both ways

I would change it to use the structure


Rgds,
Arm




Vipin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] EXYNOS5: Add GPIO numbering feature

[Rajeshwari Shinde]

This patchset adds GPIO numbering feature where pinmux setting
can be done just by seding the pin munber and we do not have to
remember which bank it belongs to.

Rajeshwari Shinde (2):
  S5P: GPIO: Add generic pin mumbering API's
  EXYNOS5: Add gpio pin numbering feature

 arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +
 arch/arm/include/asm/arch-exynos/gpio.h |  366 ++-
 drivers/gpio/s5p_gpio.c |   18 ++
 3 files changed, 437 insertions(+), 95 deletions(-)

-- 
1.7.4.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] S5P: GPIO: Add generic pin mumbering API's

[Rajeshwari Shinde]

This patch adds API's to set config,drive and pull factor in
gpio pin mumbering feature.

Signed-off-by: Rajeshawari Shinde rajeshwar...@samsung.com
---
 drivers/gpio/s5p_gpio.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index 656bf4a..a53bdca 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -196,3 +196,21 @@ int gpio_set_value(unsigned gpio, int value)
 
return 0;
 }
+
+void gpio_set_pull(int gpio, int mode)
+{
+   s5p_gpio_set_pull(s5p_gpio_get_bank(gpio),
+   s5p_gpio_get_pin(gpio), mode);
+}
+
+void gpio_set_drv(int gpio, int mode)
+{
+   s5p_gpio_set_drv(s5p_gpio_get_bank(gpio),
+   s5p_gpio_get_pin(gpio), mode);
+}
+
+void gpio_cfg_pin(int gpio, int cfg)
+{
+   s5p_gpio_cfg_pin(s5p_gpio_get_bank(gpio),
+   s5p_gpio_get_pin(gpio), cfg);
+}
-- 
1.7.4.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend] spi/arm-pl022: Add support for ARM PL022 spi controller

[Stefan Roese]

On 12/12/2012 12:10 PM, Armando Visconti wrote:
 +
 +/* SSP registers mapping */
 +#define SSP_CR0   0x000
 +#define SSP_CR1   0x004
 +#define SSP_DR0x008
 +#define SSP_SR0x00C
 +#define SSP_CPSR  0x010
 +#define SSP_IMSC  0x014
 +#define SSP_RIS   0x018
 +#define SSP_MIS   0x01C
 +#define SSP_ICR   0x020
 +#define SSP_DMACR 0x024
 +#define SSP_ITCR  0x080
 +#define SSP_ITIP  0x084
 +#define SSP_ITOP  0x088
 +#define SSP_TDR   0x08C

 Please use C-structs instead to access the registers.


 May be this patch is a ripped version from linux. That's why
 Thanks. I will do this in v2

 
 Yes,
 I took this part from the linux pl022 driver.
 
 Never understood which way (C-struct or defines) is preferable
 and why...

U-Boot is here more strict than Linux here. Using C-struct's enables
type-checking. So thats the preferred way.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] EXYNOS5: Add gpio pin numbering feature

[Rajeshwari Shinde]

This patch adds support for gpio pin numbering support on EXYNOS5
pinmux.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +
 arch/arm/include/asm/arch-exynos/gpio.h |  360 ++-
 2 files changed, 413 insertions(+), 95 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index f02f441..9b4355a 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -28,89 +28,77 @@
 
 static void exynos5_uart_config(int peripheral)
 {
-   struct exynos5_gpio_part1 *gpio1 =
-   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
-   struct s5p_gpio_bank *bank;
int i, start, count;
 
switch (peripheral) {
case PERIPH_ID_UART0:
-   bank = gpio1-a0;
-   start = 0;
+   start = GPIO_A00;
count = 4;
break;
case PERIPH_ID_UART1:
-   bank = gpio1-d0;
-   start = 0;
+   start = GPIO_D00;
count = 4;
break;
case PERIPH_ID_UART2:
-   bank = gpio1-a1;
-   start = 0;
+   start = GPIO_A10;
count = 4;
break;
case PERIPH_ID_UART3:
-   bank = gpio1-a1;
-   start = 4;
+   start = GPIO_A14;
count = 2;
break;
}
for (i = start; i  start + count; i++) {
-   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
-   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+   gpio_set_pull(i, GPIO_PULL_NONE);
+   gpio_cfg_pin(i, GPIO_FUNC(0x2));
}
 }
 
 static int exynos5_mmc_config(int peripheral, int flags)
 {
-   struct exynos5_gpio_part1 *gpio1 =
-   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
-   struct s5p_gpio_bank *bank, *bank_ext;
-   int i, start = 0, gpio_func = 0;
+   int i, start, start_ext, gpio_func = 0;
 
switch (peripheral) {
case PERIPH_ID_SDMMC0:
-   bank = gpio1-c0;
-   bank_ext = gpio1-c1;
-   start = 0;
+   start = GPIO_C00;
+   start_ext = GPIO_C10;
gpio_func = GPIO_FUNC(0x2);
break;
case PERIPH_ID_SDMMC1:
-   bank = gpio1-c2;
-   bank_ext = NULL;
+   start = GPIO_C20;
+   start_ext = 0;
break;
case PERIPH_ID_SDMMC2:
-   bank = gpio1-c3;
-   bank_ext = gpio1-c4;
-   start = 3;
+   start = GPIO_C30;
+   start_ext = GPIO_C43;
gpio_func = GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC3:
-   bank = gpio1-c4;
-   bank_ext = NULL;
+   start = GPIO_C40;
+   start_ext = 0;
break;
}
-   if ((flags  PINMUX_FLAG_8BIT_MODE)  !bank_ext) {
+   if ((flags  PINMUX_FLAG_8BIT_MODE)  !start_ext) {
debug(SDMMC device %d does not support 8bit mode,
peripheral);
return -1;
}
if (flags  PINMUX_FLAG_8BIT_MODE) {
-   for (i = start; i = (start + 3); i++) {
-   s5p_gpio_cfg_pin(bank_ext, i, gpio_func);
-   s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_UP);
-   s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
+   for (i = start_ext; i = (start_ext + 3); i++) {
+   gpio_cfg_pin(i, gpio_func);
+   gpio_set_pull(i, GPIO_PULL_UP);
+   gpio_set_drv(i, GPIO_DRV_4X);
}
}
for (i = 0; i  2; i++) {
-   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
-   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
-   s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
+   gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
+   gpio_set_pull(start + i, GPIO_PULL_NONE);
+   gpio_set_drv(start + i, GPIO_DRV_4X);
}
for (i = 3; i = 6; i++) {
-   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
-   s5p_gpio_set_pull(bank, i, GPIO_PULL_UP);
-   s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
+   gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
+   gpio_set_pull(start + i, GPIO_PULL_UP);
+   gpio_set_drv(start + i, GPIO_DRV_4X);
}
 
return 0;
@@ -118,8 +106,6 @@ static int exynos5_mmc_config(int peripheral, int flags)
 
 static void exynos5_sromc_config(int flags)
 {
-   struct exynos5_gpio_part1 *gpio1 =
-   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();

Re: [U-Boot] [PATCH v2] usbh/ehci: Increase timeout for enumeration

[Igor Grinberg]

On 12/12/12 11:54, Vipin Kumar wrote:
 
 +ulong start = get_timer(0);
 +
 +do {
 +ret = usb_get_port_status(dev, i + 1, portsts);
 +if (ret  0) {
 +USB_HUB_PRINTF(get_port_status failed\n);
 +break;
 +}
 +
 +portstatus = le16_to_cpu(portsts-wPortStatus);
 +portchange = le16_to_cpu(portsts-wPortChange);
 +
 +if ((portchange  USB_PORT_STAT_C_CONNECTION) ==
 +(portstatus  USB_PORT_STAT_CONNECTION))

 I don't know if there is any corner case when the above check
 will always fail and so it will always wait a maximal delay time.
 Are those registers that identical, or can there be differences?

 +break;
 +
 +mdelay(100);
 +} while (get_timer(start)  CONFIG_SYS_HZ * 10);

 Is there any justification for the CONFIG_SYS_HZ * 10?
 I would be much more fine with this patch if there were any
 (even just test based * 2) reason for that number.

 
 Not really. Just a practical test.

Ok. good. can we please have a comment saying that this value
is based on observations? Thanks!
You can add my ack along with the comment in v3.

Thanks for the patch!

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] EXYNOS4: Add pinmux support for I2C

[김정현]

Dear Heiko,

Thanks for your concern.

I didn't know the patch.
It can be replaced my patch.

Thank you,
JHKIM



2012년 12월 12일 17:16, Heiko Schocher 쓴 글:
 Hello Jeong,

 On 12.12.2012 08:54, Jeong Hyeon Kim wrote:
 From: Jeong-Hyeon Kimjh...@insignal.co.kr

 This patch adds pinmux support for I2C channels

 Signed-off-by: Jeong-Hyeon Kimjh...@insignal.co.kr
 ---
 arch/arm/cpu/armv7/exynos/pinmux.c | 51
 
 1 file changed, 51 insertions(+)

 similiar patch is applied to u-boot-i2c, see:

 http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commitdiff;h=4d4628dcaa51b501bec148a9c5c55df3920350dc


 and pull request is pending. Can you check, if the above patch fits
 your needs?

 Thanks!

 bye,
 Heiko

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] usbh/ehci: Increase timeout for enumeration

[Vipin Kumar]

On 12/12/2012 5:10 PM, Igor Grinberg wrote:

On 12/12/12 11:54, Vipin Kumar wrote:



+ulong start = get_timer(0);
+
+do {
+ret = usb_get_port_status(dev, i + 1, portsts);
+if (ret   0) {
+USB_HUB_PRINTF(get_port_status failed\n);
+break;
+}
+
+portstatus = le16_to_cpu(portsts-wPortStatus);
+portchange = le16_to_cpu(portsts-wPortChange);
+
+if ((portchange   USB_PORT_STAT_C_CONNECTION) ==
+(portstatus   USB_PORT_STAT_CONNECTION))


I don't know if there is any corner case when the above check
will always fail and so it will always wait a maximal delay time.
Are those registers that identical, or can there be differences?


+break;
+
+mdelay(100);
+} while (get_timer(start)   CONFIG_SYS_HZ * 10);


Is there any justification for the CONFIG_SYS_HZ * 10?
I would be much more fine with this patch if there were any
(even just test based * 2) reason for that number.



Not really. Just a practical test.


Ok. good. can we please have a comment saying that this value
is based on observations? Thanks!
You can add my ack along with the comment in v3.

Thanks for the patch!



Thanks Igor
Marek, I am waiting for your comments now, if any

-Vipin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] spi/arm-pl022: Add support for ARM PL022 spi controller

[Vipin Kumar]

From: Armando Visconti armando.visco...@st.com

This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.

Signed-off-by: Armando Visconti armando.visco...@st.com
Signed-off-by: Vipin Kumar vipin.ku...@st.com
---
 drivers/spi/Makefile|   1 +
 drivers/spi/pl022_spi.c | 310 
 2 files changed, 311 insertions(+)
 create mode 100644 drivers/spi/pl022_spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 824d357..3a4e4b0 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
 COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
 COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
 COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
 COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
 COBJS-$(CONFIG_SH_SPI) += sh_spi.o
 COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
new file mode 100644
index 000..ba018b8
--- /dev/null
+++ b/drivers/spi/pl022_spi.c
@@ -0,0 +1,310 @@
+/*
+ * (C) Copyright 2012
+ * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
+ *
+ * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
+ * by Atmel Corporation.
+ *
+ * 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 malloc.h
+#include spi.h
+#include asm/io.h
+#include asm/arch/hardware.h
+
+/* SSP registers mapping */
+struct pl022 {
+   u32 ssp_cr0;/* 0x000 */
+   u32 ssp_cr1;/* 0x004 */
+   u32 ssp_dr; /* 0x008 */
+   u32 ssp_sr; /* 0x00c */
+   u32 ssp_cpsr;   /* 0x010 */
+   u32 ssp_imsc;   /* 0x014 */
+   u32 ssp_ris;/* 0x018 */
+   u32 ssp_mis;/* 0x01c */
+   u32 ssp_icr;/* 0x020 */
+   u32 ssp_dmacr;  /* 0x024 */
+   u8  reserved_1[0x080 - 0x028];
+   u32 ssp_itcr;   /* 0x080 */
+   u32 ssp_itip;   /* 0x084 */
+   u32 ssp_itop;   /* 0x088 */
+   u32 ssp_tdr;/* 0x08c */
+   u8  reserved_2[0xFE0 - 0x090];
+   u32 ssp_pid0;   /* 0xfe0 */
+   u32 ssp_pid1;   /* 0xfe4 */
+   u32 ssp_pid2;   /* 0xfe8 */
+   u32 ssp_pid3;   /* 0xfec */
+   u32 ssp_cid0;   /* 0xff0 */
+   u32 ssp_cid1;   /* 0xff4 */
+   u32 ssp_cid2;   /* 0xff8 */
+   u32 ssp_cid3;   /* 0xffc */
+};
+
+/* SSP Control Register 0  - SSP_CR0 */
+#define SSP_CR0_SPO(0x1  6)
+#define SSP_CR0_SPH(0x1  7)
+#define SSP_CR0_8BIT_MODE  (0x07)
+#define SSP_SCR_MAX(0xFF)
+#define SSP_SCR_SHFT   8
+
+/* SSP Control Register 0  - SSP_CR1 */
+#define SSP_CR1_MASK_SSE   (0x1  1)
+
+#define SSP_CPSR_MAX   (0xFE)
+
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE(0x1  0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF(0x1  1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE(0x1  2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF(0x1  3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY(0x1  4) /* Busy Flag */
+
+struct pl022_spi_slave {
+   struct spi_slave slave;
+   void *regs;
+   unsigned int freq;
+};
+
+static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
+{
+   return container_of(slave, struct pl022_spi_slave, slave);
+}
+
+/*
+ * Following three functions should be provided by the
+ * board support package.
+ */
+int __weak spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+   return 1;
+}
+
+void __weak spi_cs_activate(struct spi_slave *slave)
+{
+   /* do nothing */
+}
+
+void __weak spi_cs_deactivate(struct spi_slave *slave)
+{
+   /* do nothing */
+}
+
+void spi_init()
+{
+   /* do nothing */
+}
+
+/*
+ * ARM PL022 exists in different 'flavors'.
+ * This drivers currently support the standard variant (0x00041022), that has a
+ * 16bit wide and 8 locations deep TX/RX FIFO.
+ */
+static int pl022_is_supported(struct pl022_spi_slave *ps)
+{
+   struct pl022 

Re: [U-Boot] [PATCH v2] spi/arm-pl022: Add support for ARM PL022 spi controller

[Stefan Roese]

On 12/12/2012 01:04 PM, Vipin Kumar wrote:
 From: Armando Visconti armando.visco...@st.com
 
 This patch adds the support for the ARM PL022 SPI controller for the standard
 variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.
 
 Signed-off-by: Armando Visconti armando.visco...@st.com
 Signed-off-by: Vipin Kumar vipin.ku...@st.com

I'm not that familiar with the U-Boot SPI stuff. But patch looks in
general good, so:

Acked-by: Stefan Roese s...@denx.de

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [BUGFIX PATCH] mips: serial: Fix busted manual relocation

[Daniel Schwierzeck]

Hi Joe,

2012/12/12 Joe Hershberger joe.hershber...@ni.com:
 serial_initialize() must be called after relocation to adjust the
 pointers to putc(), getc(), etc.  This is busted ever since the
 serial driver-model-ification series.

 Signed-off-by: Joe Hershberger joe.hershber...@ni.com
 ---
  arch/mips/lib/board.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
 index 7ddd778..e47989b 100644
 --- a/arch/mips/lib/board.c
 +++ b/arch/mips/lib/board.c
 @@ -262,6 +262,8 @@ void board_init_r(gd_t *id, ulong dest_addr)

 monitor_flash_len = (ulong)uboot_end_data - dest_addr;

 +   serial_initialize();
 +
  #if defined(CONFIG_NEEDS_MANUAL_RELOC)
 /*
  * We have to relocate the command table manually
 --

good catch, thanks.

gcc-4.7 raises a warning:

board.c: In function 'board_init_r':
board.c:265:2: warning: implicit declaration of function
'serial_initialize' [-Wimplicit-function-declaration]

But if I include serial.h (which includes asm/io.h) I get following error:

board.c:50:15: error: conflicting type qualifiers for 'mips_io_port_base'
In file included from /work/git-trees/u-boot-mips/include/post.h:32:0,
 from /work/git-trees/u-boot-mips/include/serial.h:4,
 from board.c:27:
/work/git-trees/u-boot-mips/build/qemu_mipsel/include2/asm/io.h:74:28:
note: previous declaration of 'mips_io_port_base' was here

I will fix it in the MIPS tree and send new patches today.

-- 
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] MIPS: constify mips_io_port_base

[Daniel Schwierzeck]

mips_io_port_base is exported as 'extern const unsigned long mips_io_port_base;'
in arch/mips/include/asm/io.h. Thus make the variable const too.

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 arch/mips/lib/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index 7ddd778..4f330cc 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -46,7 +46,7 @@ static char *failed = *** failed ***\n;
  * mips_io_port_base is the begin of the address space to which x86 style
  * I/O ports are mapped.
  */
-unsigned long mips_io_port_base = -1;
+const unsigned long mips_io_port_base = -1;
 
 int __board_early_init_f(void)
 {
-- 
1.8.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] mips: serial: Fix busted manual relocation

[Daniel Schwierzeck]

From: Joe Hershberger joe.hershber...@ni.com

serial_initialize() must be called after relocation to adjust the
pointers to putc(), getc(), etc.  This is busted ever since the
serial driver-model-ification series.

Signed-off-by: Joe Hershberger joe.hershber...@ni.com
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
Changes for v2:
- include serial.h to fix gcc-4.7 warnings

This patch depends on http://patchwork.ozlabs.org/patch/205498/ to compile
without warnings.

 arch/mips/lib/board.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index 4f330cc..d79e183 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -24,6 +24,7 @@
 #include common.h
 #include command.h
 #include malloc.h
+#include serial.h
 #include stdio_dev.h
 #include version.h
 #include net.h
@@ -262,6 +263,8 @@ void board_init_r(gd_t *id, ulong dest_addr)

monitor_flash_len = (ulong)uboot_end_data - dest_addr;

+   serial_initialize();
+
 #if defined(CONFIG_NEEDS_MANUAL_RELOC)
/*
 * We have to relocate the command table manually
--
1.8.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [GIT PULL] u-boot-mips/master

[Daniel Schwierzeck]

Hi Tom,

please pull two bugfixes for MIPS.


The following changes since commit ea40a05422bdc87a7af5dc349e8adce59f982e72:

  MIPS: constify address pointer in test_bit() (2012-12-08 21:48:19 +0100)

are available in the git repository at:

  git://git.denx.de/u-boot-mips.git master

for you to fetch changes up to f88e09de8d4ce7307c6aaf3a3adff53e85b4b5b3:

  mips: serial: Fix busted manual relocation (2012-12-12 13:20:24 +0100)


Daniel Schwierzeck (1):
  MIPS: constify mips_io_port_base

Joe Hershberger (1):
  mips: serial: Fix busted manual relocation

 arch/mips/lib/board.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 15/20] Add console command to access io space registers

[Tom Rini]

On Sat, Dec 08, 2012 at 11:54:13AM -0800, Simon Glass wrote:
 Hi Fabio,
 
 On Wed, Dec 5, 2012 at 5:30 PM, Fabio Estevam feste...@gmail.com wrote:
  On Wed, Dec 5, 2012 at 11:25 PM, Vadim Bendebury vben...@chromium.org 
  wrote:
 
  No - md/mw access memory, the new commands access the IO space (which
  is an x86 architecture property).
 
  Ok, understood. On ARM we are able to access registers via md/mw.
 
  Maybe it would be better to put a note in the commit message that this
  is x86 specific.
 
 Yes I put it an x86: tag on it for the next version. I have not added
 any x86 note in the README - in fact this is sadly missing a README
 comment.

Please address adding to the README in another patch, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/20] Various patches in common/

[Tom Rini]

On Wed, Dec 05, 2012 at 04:46:27PM -0800, Simon Glass wrote:

 This collection of patches to common/ adds the following:
 
 - EDID support for LCD displays
 - TPM stress test
 - gettime command to find out the time since boot
 - Adds coreboot information to the 'version' command
 - Fixes LMB on x86
 - SHA256 hashing using a new hashing framework created in response to
list feedback
 - Reading raw data from a partition of a block device
 
 Some patches have been dropped from v2 in response to list feedback.
 
 Also fixes a few minor bugs and tidy-ups.
 
 Changes in v3:
 - Rename stricmp() to strcasecmp() to match Linux / POSIX
 - Bracket strcasecmp() declarations with __HAVE_ARCH_...
 - Rename stricmp() to strcasecmp() to match Linux / POSIX
 - Correct hash error message to show the algorithm name, not always SHA1
 - Fix ordering of hash.o in Makefile
 - Correct hash command help to say 'hash' instead of 'sha1sum'
 - Drop meminfo from this series
 - Drop patch 'Update time command to avoid using get_timer_masked()'
 
 Changes in v2:
 - Remove arm: tag from bootstage step patch
 - Convert space to tab in README
 - Update gettime commit message to include boards without CONFIG_SYS_HZ
 - Add more comments to the stdio strncpy commit message
 - Add new patch to adjust sha1 functions to use const/unsigned
 - Add new patch to adjust sha256 functions to const and watchdog
 - Add stricmp() patch again since it is used in this series
 - Add generic hash API to allow SHA256 command to be added without duplication
 - Add new patch to change sha1sum to use generic hash API
 - Add new hash command to support generic hash API
 - Add patch to enable hashing and EDID on smdk5250
 - Add x86 patch to enable io command for coreboot
 - Add x86 tag to version command patch
 
 Anton Staaf (1):
   Add gettime command
 
 Kenneth Waters (1):
   Add a command to read raw blocks from a partition
 
 Luigi Semenzato (1):
   tpm: Add TPM stress test
 
 Simon Glass (11):
   Add new bootstage step for the main loop
   Fix use of conditional LMB
   sha1: Use const where possible, and unsigned for input len
   sha256: Use const where possible and add watchdog function
   Add strcasecmp() and strncasecmp()
   Add generic hash API
   sha1sum: Use generic hash layer
   Add hash command to perform hashing using various algorithms
   console: Enable function to display console info
   exynos: Enable hashing functions and EDID for smdk5250
   x86: coreboot: Enable io command
 
 Stefan Reinauer (1):
   x86: Add coreboot version to u-boot's version command
 
 Tom Wai-Hong Tam (3):
   edid: Library of EDID decode and print
   edid: Add I2C command for printing the EDID
   fdt: edid: Enable fdt_add_edid() function when CONFIG_LCD defined
 
 Vadim Bendebury (1):
   Add console command to access io space registers
 
 Vincent Palatin (1):
   stdio: remove useless strncpy
 
  README|   25 +++
  arch/m68k/include/asm/string.h|2 +-
  arch/powerpc/include/asm/string.h |2 +-
  arch/sparc/include/asm/string.h   |2 +-
  common/Makefile   |6 +
  common/cmd_bootm.c|2 +-
  common/cmd_gettime.c  |   56 +++
  common/cmd_hash.c |   63 
  common/cmd_i2c.c  |   39 +
  common/cmd_io.c   |   93 +++
  common/cmd_read.c |   81 ++
  common/cmd_sha1sum.c  |  129 +---
  common/cmd_tpm.c  |   93 +++-
  common/cmd_version.c  |7 +-
  common/console.c  |6 +-
  common/edid.c |  307 
 +
  common/fdt_support.c  |2 +-
  common/hash.c |  221 ++
  common/main.c |2 +
  common/stdio.c|1 -
  include/command.h |8 +-
  include/config_cmd_all.h  |4 +
  include/configs/coreboot.h|1 +
  include/configs/smdk5250.h|7 +
  include/edid.h|  275 +
  include/hash.h|   69 +
  include/linux/string.h|7 +-
  include/sha1.h|   26 +--
  include/sha256.h  |8 +-
  lib/sha1.c|   19 ++-
  lib/sha256.c  |   37 +-
  lib/string.c  |   16 ++-
  32 files changed, 1438 insertions(+), 178 deletions(-)
  create mode 100644 common/cmd_gettime.c
  create mode 100644 common/cmd_hash.c
  create mode 100644 common/cmd_io.c
  create mode 100644 common/cmd_read.c
  create mode 100644 common/edid.c
  create mode 100644 common/hash.c
  create mode 100644 include/edid.h
  create mode 100644 include/hash.h

Except for 19 and 20, which never hit patchwork, this is now applied to
u-boot/master.  If you want to put 19 and 20 into 

Re: [U-Boot] [PATCH] cmd:spl:fix: Prevent from a build error on boards, which don't support FDT

[Tom Rini]

On Thu, Dec 06, 2012 at 04:33:33PM +0100, Stefano Babic wrote:
 On 06/12/2012 16:23, Lukasz Majewski wrote:
  Do not compile in FDT related code, when it is not supported.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   common/cmd_spl.c |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
  
  diff --git a/common/cmd_spl.c b/common/cmd_spl.c
  index 9ec054a..e3c543b 100644
  --- a/common/cmd_spl.c
  +++ b/common/cmd_spl.c
  @@ -130,10 +130,12 @@ static int spl_export(cmd_tbl_t *cmdtp, int flag, int 
  argc, char * const argv[])
  if (call_bootm(argc, argv, subcmd_list[(int)c-cmd]))
  return -1;
  switch ((int)c-cmd) {
  +#ifdef CONFIG_OF_LIBFDT
  case SPL_EXPORT_FDT:
  printf(Argument image is now in RAM: 0x%p\n,
  (void *)images.ft_addr);
  break;
  +#endif
  case SPL_EXPORT_ATAGS:
  printf(Argument image is now in RAM at: 0x%p\n,
  (void *)gd-bd-bi_boot_params);
  
 
 Acked-by: Stefano Babic sba...@denx.de

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [GIT PULL] u-boot-i2c/master

[Tom Rini]

On Tue, Dec 11, 2012 at 07:42:19AM +0100, Heiko Schocher wrote:

 Hello Tom,
 
 The following changes since commit fd4d564b3c80b111f18c93adb14233a6a7ddb0e9:
 
   Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07 08:47:59 
 -0700)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-i2c.git master
 
 Andreas Bie?mann (1):
   soft_i2c: add necessary includes for AVR32
 
 Armando Visconti (5):
   designware_i2c.c: Added the support for MULTI_BUS
   designware_i2c: Added s/w generation of stop bit
   designware_i2c: Fixed the setting of the i2c bus speed
   designware_i2c.h: Fixed the correct values for SCL low/high time
   designware_i2c.h: Define IC_CLK only if not already defined in config 
 file
 
 Marek Vasut (9):
   i2c: Use __weak instead of __attribute__((weak, alias))
   i2c: Staticize local functions in mxc i2c driver
   i2c: kerneldoc: Add kerneldoc annotations to cmd_i2c.c
   i2c: mxs: Abstract out the MXS I2C speed setup
   i2c: mxs: Implement i2c_get/set_bus_speed()
   i2c: mxs: Use i2c_set_bus_speed() in i2c_init()
   i2c: mxs: Fix TIMING2 register value
   mxs: i2c: Restore speed setting after block reset
   mxs: i2c: Implement algorithm to set up arbitrary i2c speed
 
 Piotr Wilczek (4):
   exynos:clock: Add i2c clock
   exynos:cpu: Add Exynos4 I2C spacing
   exynos:pinmux: Add pinmux support for i2c
   drivers:i2c: Modify I2C driver for Exynos4
 
 Vincent Stehl? (1):
   omap24xx_i2c: Handle OMAP5 like OMAP2,3,4

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-net.git master

[Tom Rini]

On Tue, Dec 11, 2012 at 09:42:21PM -0600, Joe Hershberger wrote:
 Hi Thomas,
 
 On Tue, Dec 11, 2012 at 5:47 PM, Langer Thomas (LQDE RD ST PON SW)
 thomas.lan...@lantiq.com wrote:
  Hello Joe,
 
  These patches for static initialization of the struct eth_ops will break 
  the drivers on any architecture which needs manual relocation!
 
  I've send a comment regarding this, please see here:
  http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146092/focus=147607
 
 I missed that message before.  Thanks for keeping an eye out!
 
  The tests with QEMU are insufficient, as probably the memory locations 
  before relocation were still available and used via the
  uncorrected pointers.
 
 I just ran into another issue on MIPS where the is the case... serial
 is busted (serial_initialize() isn't called, which manually
 relocates), but it doesn't appear as a crash because of the
 pre-relocation addresses still being valid.
 
  So please consider to revoke the pull request until an update with fixes 
  for the eth_ops series is available.
 
 Indeed.  Tom, please disregard this pull request.

Disregarded.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] EXYNOS5: Add gpio pin numbering feature

[Kyungmin Park]

Hi,

On Wed, Dec 12, 2012 at 8:33 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
 This patch adds support for gpio pin numbering support on EXYNOS5
 pinmux.

We already know that each exynos5 SoCs has different GPIO name and offsets.
So it's good time to use proper soc prefix. e.g., EXYNOS5250_*.
Since only exynos5250 is mainlined at this time.

Thank you,
Kyungmin Park


 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
  arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +
  arch/arm/include/asm/arch-exynos/gpio.h |  360 
 ++-
  2 files changed, 413 insertions(+), 95 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
 b/arch/arm/cpu/armv7/exynos/pinmux.c
 index f02f441..9b4355a 100644
 --- a/arch/arm/cpu/armv7/exynos/pinmux.c
 +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
 @@ -28,89 +28,77 @@

  static void exynos5_uart_config(int peripheral)
  {
 -   struct exynos5_gpio_part1 *gpio1 =
 -   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 -   struct s5p_gpio_bank *bank;
 int i, start, count;

 switch (peripheral) {
 case PERIPH_ID_UART0:
 -   bank = gpio1-a0;
 -   start = 0;
 +   start = GPIO_A00;
 count = 4;
 break;
 case PERIPH_ID_UART1:
 -   bank = gpio1-d0;
 -   start = 0;
 +   start = GPIO_D00;
 count = 4;
 break;
 case PERIPH_ID_UART2:
 -   bank = gpio1-a1;
 -   start = 0;
 +   start = GPIO_A10;
 count = 4;
 break;
 case PERIPH_ID_UART3:
 -   bank = gpio1-a1;
 -   start = 4;
 +   start = GPIO_A14;
 count = 2;
 break;
 }
 for (i = start; i  start + count; i++) {
 -   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
 -   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
 +   gpio_set_pull(i, GPIO_PULL_NONE);
 +   gpio_cfg_pin(i, GPIO_FUNC(0x2));
 }
  }

  static int exynos5_mmc_config(int peripheral, int flags)
  {
 -   struct exynos5_gpio_part1 *gpio1 =
 -   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 -   struct s5p_gpio_bank *bank, *bank_ext;
 -   int i, start = 0, gpio_func = 0;
 +   int i, start, start_ext, gpio_func = 0;

 switch (peripheral) {
 case PERIPH_ID_SDMMC0:
 -   bank = gpio1-c0;
 -   bank_ext = gpio1-c1;
 -   start = 0;
 +   start = GPIO_C00;
 +   start_ext = GPIO_C10;
 gpio_func = GPIO_FUNC(0x2);
 break;
 case PERIPH_ID_SDMMC1:
 -   bank = gpio1-c2;
 -   bank_ext = NULL;
 +   start = GPIO_C20;
 +   start_ext = 0;
 break;
 case PERIPH_ID_SDMMC2:
 -   bank = gpio1-c3;
 -   bank_ext = gpio1-c4;
 -   start = 3;
 +   start = GPIO_C30;
 +   start_ext = GPIO_C43;
 gpio_func = GPIO_FUNC(0x3);
 break;
 case PERIPH_ID_SDMMC3:
 -   bank = gpio1-c4;
 -   bank_ext = NULL;
 +   start = GPIO_C40;
 +   start_ext = 0;
 break;
 }
 -   if ((flags  PINMUX_FLAG_8BIT_MODE)  !bank_ext) {
 +   if ((flags  PINMUX_FLAG_8BIT_MODE)  !start_ext) {
 debug(SDMMC device %d does not support 8bit mode,
 peripheral);
 return -1;
 }
 if (flags  PINMUX_FLAG_8BIT_MODE) {
 -   for (i = start; i = (start + 3); i++) {
 -   s5p_gpio_cfg_pin(bank_ext, i, gpio_func);
 -   s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_UP);
 -   s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
 +   for (i = start_ext; i = (start_ext + 3); i++) {
 +   gpio_cfg_pin(i, gpio_func);
 +   gpio_set_pull(i, GPIO_PULL_UP);
 +   gpio_set_drv(i, GPIO_DRV_4X);
 }
 }
 for (i = 0; i  2; i++) {
 -   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
 -   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
 -   s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
 +   gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
 +   gpio_set_pull(start + i, GPIO_PULL_NONE);
 +   gpio_set_drv(start + i, GPIO_DRV_4X);
 }
 for (i = 3; i = 6; i++) {
 -   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
 -   s5p_gpio_set_pull(bank, i, GPIO_PULL_UP);
 -   s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
 +   

Re: [U-Boot] [PATCH v3 0/20] Various patches in common/

[Simon Glass]

Hi Tom,

On Wed, Dec 12, 2012 at 5:13 AM, Tom Rini tr...@ti.com wrote:
 On Wed, Dec 05, 2012 at 04:46:27PM -0800, Simon Glass wrote:

 This collection of patches to common/ adds the following:

 - EDID support for LCD displays
 - TPM stress test
 - gettime command to find out the time since boot
 - Adds coreboot information to the 'version' command
 - Fixes LMB on x86
 - SHA256 hashing using a new hashing framework created in response to
list feedback
 - Reading raw data from a partition of a block device

 Some patches have been dropped from v2 in response to list feedback.

 Also fixes a few minor bugs and tidy-ups.

 Changes in v3:
 - Rename stricmp() to strcasecmp() to match Linux / POSIX
 - Bracket strcasecmp() declarations with __HAVE_ARCH_...
 - Rename stricmp() to strcasecmp() to match Linux / POSIX
 - Correct hash error message to show the algorithm name, not always SHA1
 - Fix ordering of hash.o in Makefile
 - Correct hash command help to say 'hash' instead of 'sha1sum'
 - Drop meminfo from this series
 - Drop patch 'Update time command to avoid using get_timer_masked()'

 Changes in v2:
 - Remove arm: tag from bootstage step patch
 - Convert space to tab in README
 - Update gettime commit message to include boards without CONFIG_SYS_HZ
 - Add more comments to the stdio strncpy commit message
 - Add new patch to adjust sha1 functions to use const/unsigned
 - Add new patch to adjust sha256 functions to const and watchdog
 - Add stricmp() patch again since it is used in this series
 - Add generic hash API to allow SHA256 command to be added without 
 duplication
 - Add new patch to change sha1sum to use generic hash API
 - Add new hash command to support generic hash API
 - Add patch to enable hashing and EDID on smdk5250
 - Add x86 patch to enable io command for coreboot
 - Add x86 tag to version command patch

 Anton Staaf (1):
   Add gettime command

 Kenneth Waters (1):
   Add a command to read raw blocks from a partition

 Luigi Semenzato (1):
   tpm: Add TPM stress test

 Simon Glass (11):
   Add new bootstage step for the main loop
   Fix use of conditional LMB
   sha1: Use const where possible, and unsigned for input len
   sha256: Use const where possible and add watchdog function
   Add strcasecmp() and strncasecmp()
   Add generic hash API
   sha1sum: Use generic hash layer
   Add hash command to perform hashing using various algorithms
   console: Enable function to display console info
   exynos: Enable hashing functions and EDID for smdk5250
   x86: coreboot: Enable io command

 Stefan Reinauer (1):
   x86: Add coreboot version to u-boot's version command

 Tom Wai-Hong Tam (3):
   edid: Library of EDID decode and print
   edid: Add I2C command for printing the EDID
   fdt: edid: Enable fdt_add_edid() function when CONFIG_LCD defined

 Vadim Bendebury (1):
   Add console command to access io space registers

 Vincent Palatin (1):
   stdio: remove useless strncpy

  README|   25 +++
  arch/m68k/include/asm/string.h|2 +-
  arch/powerpc/include/asm/string.h |2 +-
  arch/sparc/include/asm/string.h   |2 +-
  common/Makefile   |6 +
  common/cmd_bootm.c|2 +-
  common/cmd_gettime.c  |   56 +++
  common/cmd_hash.c |   63 
  common/cmd_i2c.c  |   39 +
  common/cmd_io.c   |   93 +++
  common/cmd_read.c |   81 ++
  common/cmd_sha1sum.c  |  129 +---
  common/cmd_tpm.c  |   93 +++-
  common/cmd_version.c  |7 +-
  common/console.c  |6 +-
  common/edid.c |  307 
 +
  common/fdt_support.c  |2 +-
  common/hash.c |  221 ++
  common/main.c |2 +
  common/stdio.c|1 -
  include/command.h |8 +-
  include/config_cmd_all.h  |4 +
  include/configs/coreboot.h|1 +
  include/configs/smdk5250.h|7 +
  include/edid.h|  275 +
  include/hash.h|   69 +
  include/linux/string.h|7 +-
  include/sha1.h|   26 +--
  include/sha256.h  |8 +-
  lib/sha1.c|   19 ++-
  lib/sha256.c  |   37 +-
  lib/string.c  |   16 ++-
  32 files changed, 1438 insertions(+), 178 deletions(-)
  create mode 100644 common/cmd_gettime.c
  create mode 100644 common/cmd_hash.c
  create mode 100644 common/cmd_io.c
  create mode 100644 common/cmd_read.c
  create mode 100644 common/edid.c
  create mode 100644 common/hash.c
  create mode 100644 include/edid.h
  create mode 100644 include/hash.h

 Except for 19 and 20, which never hit patchwork, this is now applied 

Re: [U-Boot] [GIT PULL] u-boot-mips/master

[Tom Rini]

On Wed, Dec 12, 2012 at 02:00:33PM +0100, Daniel Schwierzeck wrote:

 Hi Tom,
 
 please pull two bugfixes for MIPS.
 
 
 The following changes since commit ea40a05422bdc87a7af5dc349e8adce59f982e72:
 
   MIPS: constify address pointer in test_bit() (2012-12-08 21:48:19 +0100)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-mips.git master
 
 for you to fetch changes up to f88e09de8d4ce7307c6aaf3a3adff53e85b4b5b3:
 
   mips: serial: Fix busted manual relocation (2012-12-12 13:20:24 +0100)
 
 
 Daniel Schwierzeck (1):
   MIPS: constify mips_io_port_base
 
 Joe Hershberger (1):
   mips: serial: Fix busted manual relocation
 
  arch/mips/lib/board.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp

[Simon Glass]

Hi,

On Tue, Dec 11, 2012 at 4:30 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Hatim Ali,

 In message 1355223289-15685-8-git-send-email-hatim...@samsung.com you wrote:
 From: Alim Akhtar alim.akh...@samsung.com

 Adds a new u-boot command to read current temprature from tmu driver.

 Signed-off-by: Alim Akhtar alim.akh...@samsung.com
 Acked-by: Simon Glass s...@chromium.org

 Do we really need a new command here?

 We already have dtt, which basicly does the same.

 It makes no sense to add new commands for each new device, all doing
 basicly trhe same, just in an incompatible way.

This patch feature does not use i2c as the temperature measurement is
inside the SOC. I wonder whether cmd_dtt.c could be extended so that
it only does the i2c stuff if CONFIG_SYS_DTT_BUS_NUM is defined. Then
you could use dtt_get_temp() to get the termperature as now.

Regards,
Simon


 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
 The explanation requiring the fewest assumptions is the  most  likely
 to be correct.-- William of Occam
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit

[Simon Glass]

Hi Hatim,

On Tue, Dec 11, 2012 at 4:43 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Hatim Ali,

 In message 1355223289-15685-4-git-send-email-hatim...@samsung.com you wrote:
 From: Akshay Saraswat aksha...@samsung.com

 Adding API in power for system shutdown when tripping value is reached
 in Exynos Thermal Management Unit.

 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org

 If we add something like this, it should be general enough to be used
 by other systems as well, i. e. please chose a generic API like plain
 poweroff() or similar.

Maybe rename the function and move to a new include/power.h header,
with the implementation staying where it is?

Regards,
Simon


 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
 Chapter 1 -- The story so  far:
 In the beginning the Universe was created. This has  made  a  lot  of
 people very angry and been widely regarded as a bad move.
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] EXYNOS5: Add pinmux for LCD

[Kyungmin Park]

Hi,

On Tue, Dec 11, 2012 at 8:01 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
 This patch adds pinmux configuration for backlight, LCD reset
 and HPD for DP panel on Exynos5 SMDK.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  arch/arm/cpu/armv7/exynos/pinmux.c|   20 
  arch/arm/include/asm/arch-exynos/periph.h |1 +
  2 files changed, 21 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
 b/arch/arm/cpu/armv7/exynos/pinmux.c
 index f02f441..84f52ea 100644
 --- a/arch/arm/cpu/armv7/exynos/pinmux.c
 +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
 @@ -284,6 +284,23 @@ void exynos5_spi_config(int peripheral)
 }
  }

 +void exynos5_lcd_config()
missing void
 +{
 +   struct exynos5_gpio_part1 *gpio1 =
 +   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 +
 +   /* For Backlight */
 +   s5p_gpio_cfg_pin(gpio1-b2, 0, GPIO_OUTPUT);
 +   s5p_gpio_set_value(gpio1-b2, 0, 1);
 +
 +   /* LCD power on */
 +   s5p_gpio_cfg_pin(gpio1-x1, 5, GPIO_OUTPUT);
 +   s5p_gpio_set_value(gpio1-x1, 5, 1);
 +
 +   /* Set Hotplug detect for DP */
 +   s5p_gpio_cfg_pin(gpio1-x0, 7, GPIO_FUNC(0x3));
It should be SMDK5250 specific codes, it can't located at common file.

Thank you,
Kyungmin Park
 +}
 +
  static int exynos5_pinmux_config(int peripheral, int flags)
  {
 switch (peripheral) {
 @@ -321,6 +338,9 @@ static int exynos5_pinmux_config(int peripheral, int 
 flags)
 case PERIPH_ID_SPI4:
 exynos5_spi_config(peripheral);
 break;
 +   case PERIPH_ID_LCD:
 +   exynos5_lcd_config();
 +   break;
 default:
 debug(%s: invalid peripheral %d, __func__, peripheral);
 return -1;
 diff --git a/arch/arm/include/asm/arch-exynos/periph.h 
 b/arch/arm/include/asm/arch-exynos/periph.h
 index 13abd2d..446f5c9 100644
 --- a/arch/arm/include/asm/arch-exynos/periph.h
 +++ b/arch/arm/include/asm/arch-exynos/periph.h
 @@ -54,6 +54,7 @@ enum periph_id {
 PERIPH_ID_UART1,
 PERIPH_ID_UART2,
 PERIPH_ID_UART3,
 +   PERIPH_ID_LCD,

 PERIPH_ID_COUNT,
 PERIPH_ID_NONE = -1,
 --
 1.7.1

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spi/arm-pl022: Add support for ARM PL022 spi controller

[Armando Visconti]

Ciao Vipin,

On 12/12/2012 01:04 PM, Vipin KUMAR wrote:

From: Armando Viscontiarmando.visco...@st.com

This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.



Have you tested this patch on the new variant as well?
You should have a couple of boards there with the
new asic.


Signed-off-by: Armando Viscontiarmando.visco...@st.com
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
  drivers/spi/Makefile|   1 +
  drivers/spi/pl022_spi.c | 310 
  2 files changed, 311 insertions(+)
  create mode 100644 drivers/spi/pl022_spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 824d357..3a4e4b0 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
  COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
  COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
  COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
  COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
  COBJS-$(CONFIG_SH_SPI) += sh_spi.o
  COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
new file mode 100644
index 000..ba018b8
--- /dev/null
+++ b/drivers/spi/pl022_spi.c
@@ -0,0 +1,310 @@
+/*
+ * (C) Copyright 2012
+ * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
+ *
+ * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
+ * by Atmel Corporation.
+ *
+ * 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
+ */
+
+#includecommon.h
+#includemalloc.h
+#includespi.h
+#includeasm/io.h
+#includeasm/arch/hardware.h
+
+/* SSP registers mapping */
+struct pl022 {
+   u32 ssp_cr0;/* 0x000 */
+   u32 ssp_cr1;/* 0x004 */
+   u32 ssp_dr; /* 0x008 */
+   u32 ssp_sr; /* 0x00c */
+   u32 ssp_cpsr;   /* 0x010 */
+   u32 ssp_imsc;   /* 0x014 */
+   u32 ssp_ris;/* 0x018 */
+   u32 ssp_mis;/* 0x01c */
+   u32 ssp_icr;/* 0x020 */
+   u32 ssp_dmacr;  /* 0x024 */
+   u8  reserved_1[0x080 - 0x028];
+   u32 ssp_itcr;   /* 0x080 */
+   u32 ssp_itip;   /* 0x084 */
+   u32 ssp_itop;   /* 0x088 */
+   u32 ssp_tdr;/* 0x08c */
+   u8  reserved_2[0xFE0 - 0x090];
+   u32 ssp_pid0;   /* 0xfe0 */
+   u32 ssp_pid1;   /* 0xfe4 */
+   u32 ssp_pid2;   /* 0xfe8 */
+   u32 ssp_pid3;   /* 0xfec */
+   u32 ssp_cid0;   /* 0xff0 */
+   u32 ssp_cid1;   /* 0xff4 */
+   u32 ssp_cid2;   /* 0xff8 */
+   u32 ssp_cid3;   /* 0xffc */
+};


It's correct!
:)


+
+/* SSP Control Register 0  - SSP_CR0 */
+#define SSP_CR0_SPO(0x1  6)
+#define SSP_CR0_SPH(0x1  7)
+#define SSP_CR0_8BIT_MODE  (0x07)
+#define SSP_SCR_MAX(0xFF)
+#define SSP_SCR_SHFT   8
+
+/* SSP Control Register 0  - SSP_CR1 */
+#define SSP_CR1_MASK_SSE   (0x1  1)
+
+#define SSP_CPSR_MAX   (0xFE)
+
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE(0x1  0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF(0x1  1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE(0x1  2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF(0x1  3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY(0x1  4) /* Busy Flag */
+
+struct pl022_spi_slave {
+   struct spi_slave slave;
+   void *regs;
+   unsigned int freq;
+};
+
+static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
+{
+   return container_of(slave, struct pl022_spi_slave, slave);
+}
+
+/*
+ * Following three functions should be provided by the
+ * board support package.
+ */
+int __weak spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+   return 1;
+}
+
+void __weak spi_cs_activate(struct spi_slave *slave)
+{
+   /* do nothing */
+}
+
+void __weak spi_cs_deactivate(struct spi_slave *slave)
+{
+   /* do nothing */
+}
+
+void spi_init()


Maybe you can put 'void' also in the arguments.
I think we forgot it in the original patch.


+{
+   

Re: [U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Simon Glass]

Hi Wolfgang,

On Tue, Dec 11, 2012 at 4:39 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Hatim Ali,

 In message 1355223289-15685-5-git-send-email-hatim...@samsung.com you wrote:
 From: Akshay Saraswat aksha...@samsung.com

 Adding a generic polling function to continuously monitor events and
 trigger actions corresponding to them.

 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org

 diff --git a/README b/README
 index 037513a..0e4083c 100644
 --- a/README
 +++ b/README
 @@ -2841,6 +2841,13 @@ Configuration Settings:
   the application (usually a Linux kernel) when it is
   booted

 +- CONFIG_BOARD_POLL
 + There are various scenarios in which parallel-thread like
 + polling is required to monitor status of variety of devices.
 + For such situations CONFIG_BOARD_POLL shall be enabled
 + and funtion call board_poll_devices() from console_tstc()
 + will then poll for the device status as defined inside function.


 Sorry, but I dislike this, for a number of reasons.

 1) There is, and has always been, a very basic design decision, that
U-Boot is strictly single-tasking, i. e. we don't have any kind of
background activities goind on.  Your introduction of a device
polling mechanism violates this principle.

I don't say that this is unacceptable, but we have to be aware that
this is a far-reaching decision, so we should consider it very
carefully.

If anything like this gets implemented, it has to be done in a way
that will be general enough to be useful to others as well.

Yes. It isn't really clear how this sort of thing should be done, but
creating a board polling function seems like a reasonable idea. It's
then just a question of when to call it. Since there is no particular
idle or event loop in U-Boot, perhaps we need to create one, and the
console code is probably the only sensible place since it is waiting
for user input.

I am not sure about the general issue. Obviously some sort of
background activity is going on in the chip all the time, and
monitoring is sometimes necessary. I am not sure about the best
approach for this.


 2) U-Boot is a boot loader, not an OS.  Do we really need continuous
temperature management in U-Boot?  I think not.  After all, our
main purpose is to boot an OS, and do that as fast as possible.
The majority of users will see U-Boot running only for a few
milliseconds, and only when they boot the device - which may be
very seldom.

So what exactly do we need this for?

It is possible that the OS cannot be found or is corrupted due to some
sort of failure or error. In that case we may need to prompt the user
to insert media that can be used to recover the device. If the secure
boot is turned off, we may want to print a warning and require that
the user confirm. In both cases, we can be in U-Boot for a while.

By monitoring temperature we can be sure that the system does not
overheat - it does depend on the hardware of course (power output,
heatsinks) but it can happen very quickly, certainly within a few 10s
of seconds.


 3) Your hooking of a device polling into console_tstc() is broken by
design.   It may be sufficient for the specific use case you have
in mind here, but it is totally useless for any other purpose.

 This needs a lot of additional thought, and major changes to the
 implementation.

Perhaps add a new idle function in common code which can be called
from various places (including console), and itself calls
board_poll_devices()? That is cosmetic, but does at least detach the
code from the console.

Regards,
Simon


 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
 Without facts, the decision cannot be made logically. You  must  rely
 on your human intuition.
 -- Spock, Assignment: Earth, stardate unknown
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5 v3] exynos5: config: Rename the smdk5250.h to exynos5250-dt.h

[Simon Glass]

Hi Hatim,

On Tue, Dec 11, 2012 at 2:52 AM, Hatim Ali hatim...@samsung.com wrote:
 Create a common configuration file for all exynos5250 based boards.
 Going forward we will be using DT based driver discovery for all the boards
 based on Exynos5. The different boards added will have there own config.h 
 files
 which internally will include this file and specify their specific DT files.

 Signed-off-by: Hatim Ali hatim...@samsung.com

Acked-by: Simon Glass s...@chromium.org

I'm very pleased to see this - I was going to suggest it too.

Regards,
Simon

 ---
 Changes since v2:
 - No Change

  include/configs/{smdk5250.h = exynos5250-dt.h} |9 +++--
  1 files changed, 7 insertions(+), 2 deletions(-)
  rename include/configs/{smdk5250.h = exynos5250-dt.h} (96%)

 diff --git a/include/configs/smdk5250.h b/include/configs/exynos5250-dt.h
 similarity index 96%
 rename from include/configs/smdk5250.h
 rename to include/configs/exynos5250-dt.h
 index e412da8..12f555c 100644
 --- a/include/configs/smdk5250.h
 +++ b/include/configs/exynos5250-dt.h
 @@ -1,7 +1,7 @@
  /*
 - * Copyright (C) 2011 Samsung Electronics
 + * Copyright (C) 2012 Samsung Electronics
   *
 - * Configuration settings for the SAMSUNG SMDK5250 (EXYNOS5250) board.
 + * Configuration settings for the SAMSUNG EXYNOS5250 board.
   *
   * See file CREDITS for list of people who contributed to this
   * project.
 @@ -37,6 +37,11 @@
  #define CONFIG_DISPLAY_CPUINFO
  #define CONFIG_DISPLAY_BOARDINFO

 +/* Enable fdt support for Exynos5250 */
 +#define CONFIG_ARCH_DEVICE_TREEexynos5250
 +#define CONFIG_OF_CONTROL
 +#define CONFIG_OF_SEPARATE
 +
  /* Keep L2 Cache Disabled */
  #define CONFIG_SYS_DCACHE_OFF

 --
 1.7.2.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5 v3] SMDK5250: config: Add configuration file for SMDK5250 board

[Simon Glass]

On Tue, Dec 11, 2012 at 2:52 AM, Hatim Ali hatim...@samsung.com wrote:
 Add the configuration file for exynos5250 based SMDK5250 board.

 Signed-off-by: Hatim Ali hatim...@samsung.com

Acked-by: Simon Glass s...@chromium.org

 ---
 Changes since v2:
 - No Change

  include/configs/smdk5250.h |   33 +
  1 files changed, 33 insertions(+), 0 deletions(-)
  create mode 100644 include/configs/smdk5250.h

 diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
 new file mode 100644
 index 000..81f83a8
 --- /dev/null
 +++ b/include/configs/smdk5250.h
 @@ -0,0 +1,33 @@
 +/*
 + * Copyright (C) 2012 Samsung Electronics
 + *
 + * Configuration settings for the SAMSUNG SMDK5250 board.
 + *
 + * 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 __CONFIG_SMDK_H
 +#define __CONFIG_SMDK_H
 +
 +#include configs/exynos5250-dt.h
 +
 +#undef CONFIG_DEFAULT_DEVICE_TREE
 +#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-smdk5250
 +
 +#endif /* __CONFIG_SMDK_H */
 --
 1.7.2.3


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] POWER: MAX77686: Modified as per the latest Implementation

[Simon Glass]

Hi Rajeshwari,

On Mon, Dec 10, 2012 at 3:55 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
 Moved the pmic_max77686.c max77686_pmic.h to drivers/power
 and made required changes accordingly

 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com

Acked-by: Simon Glass s...@chomium.org

See nit below if you end up resending.

You might consider using the -M option to git format-patch which
detects renames. Or you could use patman...


 ---
  drivers/misc/pmic_max77686.c   |   42 --
  drivers/power/pmic/Makefile|1 +
  drivers/power/pmic/pmic_max77686.c |   48 +++
  include/max77686_pmic.h|  158 
 
  include/power/max77686_pmic.h  |  158 
 
  5 files changed, 207 insertions(+), 200 deletions(-)
  delete mode 100644 drivers/misc/pmic_max77686.c
  create mode 100644 drivers/power/pmic/pmic_max77686.c
  delete mode 100644 include/max77686_pmic.h
  create mode 100644 include/power/max77686_pmic.h

 diff --git a/drivers/misc/pmic_max77686.c b/drivers/misc/pmic_max77686.c
 deleted file mode 100644
 index 36f7f4d..000

[snip]
\
 +++ b/drivers/power/pmic/pmic_max77686.c
 @@ -0,0 +1,48 @@
 +/*
 + *  Copyright (C) 2012 Samsung Electronics
 + *  Rajeshwari Shinde rajeshwar...@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 power/pmic.h
 +#include power/max77686_pmic.h
 +#include errno.h

I think this should go above the power/ headers, below common.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] SMDK5250: Enable pmic MAX77686

[Simon Glass]

Hi Rajeshwari,

On Mon, Dec 10, 2012 at 3:55 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
 Enabled pmic MAX77686 for SMDK5250.

 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com

With nit below fixed:

Acked-by: Simon Glass s...@chromium.org

 ---
  board/samsung/smdk5250/smdk5250.c |   15 +++
  include/configs/smdk5250.h|8 
  2 files changed, 15 insertions(+), 8 deletions(-)

 diff --git a/board/samsung/smdk5250/smdk5250.c 
 b/board/samsung/smdk5250/smdk5250.c
 index 4c50342..9c926d6 100644
 --- a/board/samsung/smdk5250/smdk5250.c
 +++ b/board/samsung/smdk5250/smdk5250.c
 @@ -30,7 +30,7 @@
  #include asm/arch/mmc.h
  #include asm/arch/pinmux.h
  #include asm/arch/sromc.h
 -#include pmic.h
 +#include power/pmic.h

  DECLARE_GLOBAL_DATA_PTR;

 @@ -65,9 +65,6 @@ static int smc9115_pre_init(void)
  int board_init(void)
  {
 gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
 -#if defined(CONFIG_PMIC)
 -   pmic_init();
 -#endif
  #ifdef CONFIG_EXYNOS_SPI
 spi_init();
  #endif
 @@ -87,6 +84,16 @@ int dram_init(void)
 return 0;
  }

 +#if defined(CONFIG_POWER)
 +int power_init_board(void)
 +{
 +   if (pmic_init(I2C_PMIC))
 +   return -1;
 +   else
 +   return 0;
 +}
 +#endif
 +
  void dram_init_banksize(void)
  {
 gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
 diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
 index e412da8..df00305 100644
 --- a/include/configs/smdk5250.h
 +++ b/include/configs/smdk5250.h
 @@ -65,7 +65,7 @@
  #define INFORM1_OFFSET 0x804

  /* Size of malloc() pool */
 -#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (1  20))
 +#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (4  20))

Unrelated?


  /* select serial console configuration */
  #define CONFIG_SERIAL3 /* use SERIAL 3 */
 @@ -209,9 +209,9 @@
  #define CONFIG_SYS_I2C_SLAVE0x0

  /* PMIC */
 -#define CONFIG_PMIC
 -#define CONFIG_PMIC_I2C
 -#define CONFIG_PMIC_MAX77686
 +#define CONFIG_POWER
 +#define CONFIG_POWER_I2C
 +#define CONFIG_POWER_MAX77686

  /* SPI */
  #define CONFIG_ENV_IS_IN_SPI_FLASH
 --
 1.7.4.4


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] EXYNOS5: Change parent clock of FIMD to MPLL

[Simon Glass]

Hi Ajay,

On Tue, Dec 11, 2012 at 3:01 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 With VPLL as source clock to FIMD,
 Exynos DP Initializaton was failing sometimes with unstable clock.
 Changing FIMD source to resolves this issue.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com

Acked-by: Simon Glass s...@chromium.org

At some point it would be nice to have defines for these, or even a
full clock api, with clock_set_rate(), clock_set_source(), etc.

Regards,
Simon

 ---
  arch/arm/cpu/armv7/exynos/clock.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
 b/arch/arm/cpu/armv7/exynos/clock.c
 index fe61f88..bfcd5f7 100644
 --- a/arch/arm/cpu/armv7/exynos/clock.c
 +++ b/arch/arm/cpu/armv7/exynos/clock.c
 @@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void)
  */
 cfg = readl(clk-src_disp1_0);
 cfg = ~(0xf);
 -   cfg |= 0x8;
 +   cfg |= 0x6;
 writel(cfg, clk-src_disp1_0);

 /*
 --
 1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] video: Fix compilation dependency of exynos_dp and exynos_mipi on exynos_fb

[Simon Glass]

On Tue, Dec 11, 2012 at 3:01 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
 Similarly, when only MIPI is used, we need not enable CONFIG_EXYNOS_DP.
 But the current structuring of code forces us to enable both
 CONFIG_EXYNOS_MIPI_DSIM and CONFIG_EXYNOS_DP.
 This patch adds conditional compilation check to remove the dependency.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com

Acked-by: Simon Glass s...@chromium.org

 ---
  drivers/video/exynos_fb.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
 index d9a3f9a..39d3b74 100644
 --- a/drivers/video/exynos_fb.c
 +++ b/drivers/video/exynos_fb.c
 @@ -103,8 +103,10 @@ static void lcd_panel_on(vidinfo_t *vid)

 udelay(vid-power_on_delay);

 +#ifdef CONFIG_EXYNOS_DP
 if (vid-dp_enabled)
 exynos_init_dp();
 +#endif

 if (vid-reset_lcd) {
 vid-reset_lcd();
 @@ -120,8 +122,10 @@ static void lcd_panel_on(vidinfo_t *vid)
 if (vid-enable_ldo)
 vid-enable_ldo(1);

 +#ifdef CONFIG_EXYNOS_MIPI_DSIM
 if (vid-mipi_enabled)
 exynos_mipi_dsi_init();
 +#endif
  }

  void lcd_ctrl_init(void *lcdbase)
 --
 1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] EXYNOS5: Add device node for USB.

[Simon Glass]

Hi Rajeshwari,

On Mon, Dec 3, 2012 at 5:30 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
 This patch adds the device node required for USB

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  arch/arm/dts/exynos5250.dtsi |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
 index e8ecf3f..dd2c6ac 100644
 --- a/arch/arm/dts/exynos5250.dtsi
 +++ b/arch/arm/dts/exynos5250.dtsi
 @@ -127,4 +127,10 @@
 clock-frequency = 5000;
 interrupts = 0 70 0;
  };
 +
 +   ehci@1211 {
 +   compatible = samsung,exynos-ehci;
 +   reg = 0x1211 0x100;
 +   phyreg = 0x1213;

I think this last thing is a phy, but perhaps it should be written out
as a sub-node, something like:

 +   ehci@1211 {
 +   compatible = samsung,exynos-ehci;
 +   reg = 0x1211 0x100;
 +   phy {
compatible = samsung,exynos-usb-phy;
reg = 0x1213 0xsomething;
}

If you copy your patch to devicetree-discuss you might get some ideas.

 +   };
  };
 --
 1.7.4.4


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] EXYNOS5: Add support for FIMD and DP

[Simon Glass]

Hi Ajay,

On Tue, Dec 11, 2012 at 3:01 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 Add panel_info structure required by LCD driver
 and DP panel platdata for SMDK5250.
 Enable FIMD and DP support on SMDK5250.
 DP Panel size: 2560x1600.
 We use 16BPP resolution to get LCD console.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com

Acked-by: Simon Glass s...@chromium.org

See suggestion below. I hope that this can be FDT-enabled later.

 ---
  board/samsung/smdk5250/smdk5250.c |   82 
 +
  include/configs/smdk5250.h|9 
  2 files changed, 91 insertions(+), 0 deletions(-)

 diff --git a/board/samsung/smdk5250/smdk5250.c 
 b/board/samsung/smdk5250/smdk5250.c
 index 4c50342..e3d6ac1 100644
 --- a/board/samsung/smdk5250/smdk5250.c
 +++ b/board/samsung/smdk5250/smdk5250.c
 @@ -24,12 +24,15 @@
  #include asm/io.h
  #include i2c.h
  #include netdev.h
 +#include lcd.h
  #include spi.h
  #include asm/arch/cpu.h
  #include asm/arch/gpio.h
  #include asm/arch/mmc.h
 +#include asm/arch/power.h
  #include asm/arch/pinmux.h
  #include asm/arch/sromc.h
 +#include asm/arch/dp_info.h
  #include pmic.h

  DECLARE_GLOBAL_DATA_PTR;
 @@ -181,6 +184,85 @@ static int board_uart_init(void)
 return 0;
  }

 +vidinfo_t panel_info = {
 +   .vl_freq= 60,
 +   .vl_col = 2560,
 +   .vl_row = 1600,
 +   .vl_width   = 2560,
 +   .vl_height  = 1600,
 +   .vl_clkp= CONFIG_SYS_LOW,
 +   .vl_hsp = CONFIG_SYS_LOW,
 +   .vl_vsp = CONFIG_SYS_LOW,
 +   .vl_dp  = CONFIG_SYS_LOW,
 +   .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
 +
 +   /* wDP panel timing infomation */
 +   .vl_hspw= 32,
 +   .vl_hbpd= 80,
 +   .vl_hfpd= 48,
 +
 +   .vl_vspw= 6,
 +   .vl_vbpd= 37,
 +   .vl_vfpd= 3,
 +   .vl_cmd_allow_len = 0xf,
 +
 +   .win_id = 3,
 +   .cfg_gpio   = NULL,
 +   .backlight_on   = NULL,
 +   .lcd_power_on   = NULL,
 +   .reset_lcd  = NULL,
 +   .dual_lcd_enabled = 0,
 +
 +   .init_delay = 0,
 +   .power_on_delay = 0,
 +   .reset_delay= 0,
 +   .interface_mode = FIMD_RGB_INTERFACE,
 +   .dp_enabled = 1,
 +};
 +
 +static struct edp_device_info edp_info = {
 +   .disp_info = {
 +   .h_res = 2560,
 +   .h_sync_width = 32,
 +   .h_back_porch = 80,
 +   .h_front_porch = 48,
 +   .v_res = 1600,
 +   .v_sync_width  = 6,
 +   .v_back_porch = 37,
 +   .v_front_porch = 3,
 +   .v_sync_rate = 60,
 +   },
 +   .lt_info = {
 +   .lt_status = DP_LT_NONE,
 +   },
 +   .video_info = {
 +   .master_mode = 0,
 +   .bist_mode = DP_DISABLE,
 +   .bist_pattern = NO_PATTERN,
 +   .h_sync_polarity = 0,
 +   .v_sync_polarity = 0,
 +   .interlaced = 0,
 +   .color_space = COLOR_RGB,
 +   .dynamic_range = VESA,
 +   .ycbcr_coeff = COLOR_YCBCR601,
 +   .color_depth = COLOR_8,
 +   },
 +};
 +
 +static struct exynos_dp_platform_data dp_platform_data = {
 +   .phy_enable = set_dp_phy_ctrl,
 +   .edp_dev_info   = edp_info,
 +};
 +
 +void init_panel_info(vidinfo_t *vid)
 +{
 +   vid-logo_on= 1,
 +   vid-rgb_mode   = MODE_RGB_P,
 +
 +   exynos_set_dp_platform_data(dp_platform_data);
 +   exynos_pinmux_config(PERIPH_ID_LCD, NULL);
 +}
 +
  #ifdef CONFIG_SYS_I2C_INIT_BOARD
  static int board_i2c_init(void)
  {
 diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
 index e412da8..9489714 100644
 --- a/include/configs/smdk5250.h
 +++ b/include/configs/smdk5250.h
 @@ -256,6 +256,15 @@
  #define CONFIG_SOUND_WM8994
  #endif

 +/* Display */
 +#define CONFIG_LCD
 +#define CONFIG_EXYNOS_FB
 +#define CONFIG_EXYNOS_DP
 +#define LCD_XRES   2560
 +#define LCD_YRES   1600
 +#define LCD_BPPLCD_COLOR16
 +#define CONFIG_CMD_BMP

Perhaps CONFIG_LCD_BMP_RLE8 as well?

 +
  /* Enable devicetree support */
  #define CONFIG_OF_LIBFDT

 --
 1.7.1


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions

[Jagan Teki]

Hi Simon,

On Wed, Dec 12, 2012 at 12:01 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Mon, Dec 10, 2012 at 10:37 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 I understand your concern.

 But currently there is no prints a/f reading/writing/erasing the SPI flash.
 User's are unable to confirm whether that particular sf commands are
 properly done/not.

 Well if there is no error, then I suppose it worked ok. We should
 definitely print errors, and progress information can sometimes be
 useful for very long operations. But serial and LCD output is slow, so
 it can affect run time, quite apart from the verbosity, so IMO the
 less the better.

 Would it not be possible to put this message into cmd_sf.c?

Yes it will possible to do this on cmd_sf.
But I am not understanding what is the side effect, if we put in this area..
will you please elaborate.

Thanks,
Jagan.

 Regards,
 Simon


 Thanks,
 Jagan.


 On Tue, Dec 11, 2012 at 12:56 AM, Simon Glass s...@chromium.org wrote:

 Hi,

 On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
  This patch provides to enabled the prints on erase and write
  functions to make sure that how many bytes erase/write into flash
  device.
 
  Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
  ---
   drivers/mtd/spi/spi_flash.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
  index 00aece9..464c2ab 100644
  --- a/drivers/mtd/spi/spi_flash.c
  +++ b/drivers/mtd/spi/spi_flash.c
  @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash
  *flash, u32 offset,
  byte_addr = 0;
  }
 
  -   debug(SF: program %s %zu bytes @ %#x\n,
  +   printf(SF: program %s %zu bytes @ %#x\n,
ret ? failure : success, len, offset);

 I don't think we want this - it will make programming very slow and
 verbose.

 
  spi_release_bus(flash-spi);
  @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
  offset, size_t len)
  goto out;
  }
 
  -   debug(SF: Successfully erased %zu bytes @ %#x\n, len, start);
  +   printf(SF: Successfully erased %zu bytes @ %#x\n, len, start);

 You may want to put this code into cmd_sf instead, where it is
 reasonable to add messages. You are changing core spi code which might
 be used from many places.

 
out:
  spi_release_bus(flash-spi);
  --
  1.7.0.4
 
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] sf: Add print message on flash read function

[Jagan Teki]

Hi Simon,

On Wed, Dec 12, 2012 at 12:03 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch adds a print message on spi_flash_cmd_read_fast()
 to make sure that how many bytes read from flash device.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com

 I have the same verbosity comment on this patch, BTW.

This is also needs to put it on cmd_sf,c?

Thanks,
Jagan.


 Regards,
 Simon

 ---
  drivers/mtd/spi/spi_flash.c |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 464c2ab..800ed8b 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -139,12 +139,17 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, 
 u32 offset,
 size_t len, void *data)
  {
 u8 cmd[5];
 +   int ret;

 cmd[0] = CMD_READ_ARRAY_FAST;
 spi_flash_addr(offset, cmd);
 cmd[4] = 0x00;

 -   return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
 +   ret = spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
 +   printf(SF: re-program %s %zu bytes @ %#x\n,
 +   ret ? failure : success, len, offset);
 +
 +   return ret;
  }

  int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
 --
 1.7.0.4

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] video: Modify exynos_fimd driver to support LCD console.

[Simon Glass]

On Tue, Dec 11, 2012 at 3:01 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
 In order to get LCD console, we need to enable half word swap feature
 of FIMD and use 16 BPP.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com

Eventual FDT support should help to remove these ifdefs. But even in
the meantime, would it not be better to create a new
CONFIG_EXYNOS_FIMD_... option to select the behavior and then put the
option in the board config file?

Regards,
Simon

 ---
  drivers/video/exynos_fimd.c |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)

 diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
 index 06eae2e..8a12c30 100644
 --- a/drivers/video/exynos_fimd.c
 +++ b/drivers/video/exynos_fimd.c
 @@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
 /* DATAPATH is DMA */
 cfg |= EXYNOS_WINCON_DATAPATH_DMA;

 -   /* bpp is 32 */
 +#ifdef CONFIG_TIZEN /* Tizen uses Proprietary LOGO */
 cfg |= EXYNOS_WINCON_WSWP_ENABLE;
 +#else  /* Other boards must use output console on LCD */
 +   cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
 +#endif

 /* dma burst is 16 */
 cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;

 -   /* pixel format is unpacked RGB888 */
 +#ifdef CONFIG_TIZEN /* Tizen uses Proprietary LOGO */
 cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
 +#else  /* Other boards must use output console on LCD */
 +   cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
 +#endif

 writel(cfg, (unsigned int)fimd_ctrl-wincon0 +
 EXYNOS_WINCON(win_id));
 --
 1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sf: stmicro: add support for N25Q064

[Jagannadha Sutradharudu Teki]

Add support for Numonyx N25Q064 SPI flash.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
 drivers/mtd/spi/stmicro.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 30b626a..9ec938a 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -93,6 +93,12 @@ static const struct stmicro_spi_flash_params 
stmicro_spi_flash_table[] = {
.name = M25P128,
},
{
+   .id = 0xba17,
+   .pages_per_sector = 256,
+   .nr_sectors = 128,
+   .name = N25Q064,
+   },
+   {
.id = 0xba18,
.pages_per_sector = 256,
.nr_sectors = 256,
-- 
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 1/8] EXYNOS5: FDT: Add TMU device node values

[Simon Glass]

Hi Hatim,

On Tue, Dec 11, 2012 at 2:54 AM, Hatim Ali hatim...@samsung.com wrote:
 From: Akshay Saraswat aksha...@samsung.com

 Fdt entry for Exynos TMU driver specific pre-defined values used for
 calibration of current temperature and defining threshold values.

 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org

 diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
 index fa4d498..db22db6 100644
 --- a/arch/arm/dts/exynos5250.dtsi
 +++ b/arch/arm/dts/exynos5250.dtsi
 @@ -28,4 +28,9 @@
 #address-cells = 1;
 #size-cells = 0;
 };
 +
 +   tmu@1006 {
 +   compatible = samsung,exynos-tmu;
 +   reg = 0x1006 0x;

I think the  should be 0x1.

 +   };
  };
 diff --git a/board/samsung/dts/exynos5250-smdk5250.dts 
 b/board/samsung/dts/exynos5250-smdk5250.dts
 index b6fbb67..2d3ecca 100644
 --- a/board/samsung/dts/exynos5250-smdk5250.dts
 +++ b/board/samsung/dts/exynos5250-smdk5250.dts
 @@ -26,4 +26,17 @@
 phy-mode = mii;
 };
 };
 +
 +   tmu@1006 {
 +   samsung,mux = 6;
 +   samsung,min-temp= 25;
 +   samsung,max-temp= 125;
 +   samsung,start-warning   = 95;
 +   samsung,start-tripping  = 105;
 +   samsung,efuse-min-value = 40;
 +   samsung,efuse-value = 55;
 +   samsung,efuse-max-value = 100;
 +   samsung,slope   = 268470274;
 +   samsung,dc-value= 25;
 +   };
  };
 diff --git a/doc/device-tree-bindings/exynos/tmu.txt 
 b/doc/device-tree-bindings/exynos/tmu.txt
 new file mode 100644
 index 000..99e7164
 --- /dev/null
 +++ b/doc/device-tree-bindings/exynos/tmu.txt
 @@ -0,0 +1,35 @@
 +Exynos Thermal management Unit
 +
 +The device node for TMU that is a part of Exynos5250
 +SOC is as described in the document Open Firmware Recommended
 +Practic : Universal Serial Bus with the following modifications
 +and additions:
 +
 +Required properties :
 + - compatible : Should be samsung,exynos-tmu for TMU
 + - samsung,mux : mux Address for the TMU to enable TMU core:
 + - samsung,min-temp : Minimum temperature, default is 25:
 + - samsung,max-temp : Maximum temperature, defalut set to 125:
 + - samsung,start-warning : temp at which TMU start giving warning:
 + - samsung,start-tripping : temp at which system will trip and shutdown:
 + - samsung,efuse-min-value : SOC efuse min value:
 + - samsung,efuse-value : SOC actual efuse value:
 + - samsung,efuse-max-value : SoC max efuse value:
 + - samsung,slope : Gain of amplifier, default is 268470274:
 + - samsung,dc-value : DC value of TMU, default is 25:

Can you add a few more details here on these last 5? The units of each
should be listed (and for temperature above which I think is degrees
C). The 'slope' in particular is a very large random number which
could do with some docs. Also re samsung.mux, what are the available
options?

Also remove : at the end of lines.


 +
 +Example:
 +
 +tmu@1006 {
 +   compatible = samsung,exynos-tmu
 +   samsung,mux = 6;
 +   samsung,min-temp = 25;
 +   samsung,max-temp = 125;
 +   samsung,start-warning = 95;
 +   samsung,start-tripping = 105;
 +   samsung,efuse-min-value = 40;
 +   samsung,efuse-value = 55;
 +   samsung,efuse-max-value = 100;
 +   samsung,slope = 268470274;
 +   samsung,dc-value = 25;
 +};
 diff --git a/include/fdtdec.h b/include/fdtdec.h
 index da3c85f..2d74cec 100644
 --- a/include/fdtdec.h
 +++ b/include/fdtdec.h
 @@ -70,6 +70,7 @@ enum fdt_compat_id {
 COMPAT_NVIDIA_TEGRA20_DC,   /* Tegra 2 Display controller */
 COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
 COMPAT_SAMSUNG_EXYNOS5_SROMC,   /* Exynos5 SROMC */
 +   COMPAT_SAMSUNG_EXYNOS_TMU,  /* Exynos TMU */

 COMPAT_COUNT,
  };
 diff --git a/lib/fdtdec.c b/lib/fdtdec.c
 index 85e733c..2b9df7f 100644
 --- a/lib/fdtdec.c
 +++ b/lib/fdtdec.c
 @@ -47,6 +47,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
 COMPAT(NVIDIA_TEGRA20_DC, nvidia,tegra20-dc),
 COMPAT(SMSC_LAN9215, smsc,lan9215),
 COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
 +   COMPAT(SAMSUNG_EXYNOS_TMU, samsung,exynos-tmu),
  };

  const char *fdtdec_get_compatible(enum fdt_compat_id id)
 --
 1.7.2.3


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 1/7] Tegra30: Add arch-tegra30 include files

[Simon Glass]

On Tue, Dec 11, 2012 at 3:34 PM, Tom Warren twarren.nvi...@gmail.com wrote:
 Common Tegra files are in arch-tegra, shared between T20 and T30.
 Tegra30-specific headers are in arch-tegra30. Note that some of
 these will be filled in as more T30 support is added (drivers,
 WB/LP0 support, etc.). A couple of Tegra20 files were changed
 to support common headers in arch-tegra, also.

 Signed-off-by: Tom Warren twar...@nvidia.com

Not a thorough review but it looks good, thanks.

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/7] Tegra30: Add AVP (arm720t) files

[Simon Glass]

On Tue, Dec 11, 2012 at 3:34 PM, Tom Warren twarren.nvi...@gmail.com wrote:
 This provides SPL support for T30 boards - AVP early init, plus
 CPU (A9) init/jump to main U-Boot.

 Some changes were made to Tegra20 cpu.c to move common routines
 into tegra-common/cpu.c and reduce code duplication.

 Signed-off-by: Tom Warren twar...@nvidia.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions

[Simon Glass]

Hi Jagan,

On Wed, Dec 12, 2012 at 6:43 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:01 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Mon, Dec 10, 2012 at 10:37 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Simon,

 I understand your concern.

 But currently there is no prints a/f reading/writing/erasing the SPI flash.
 User's are unable to confirm whether that particular sf commands are
 properly done/not.

 Well if there is no error, then I suppose it worked ok. We should
 definitely print errors, and progress information can sometimes be
 useful for very long operations. But serial and LCD output is slow, so
 it can affect run time, quite apart from the verbosity, so IMO the
 less the better.

 Would it not be possible to put this message into cmd_sf.c?

 Yes it will possible to do this on cmd_sf.
 But I am not understanding what is the side effect, if we put in this area..
 will you please elaborate.

Well if someone writes some code that calls the spi_flash interface
from else where, such as:

http://patchwork.ozlabs.org/patch/190164/

or defines CONFIG_ENV_IS_IN_SPI_FLASH

then your patch will start printing messages when none are required.

By putting it in cmd_sf.c, and perhaps evening making it optional
through a CONFIG_SF_VERBOSE, you make it possible for people to keep
the existing behavior.

Regards,
Simon


 Thanks,
 Jagan.

 Regards,
 Simon


 Thanks,
 Jagan.


 On Tue, Dec 11, 2012 at 12:56 AM, Simon Glass s...@chromium.org wrote:

 Hi,

 On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
  This patch provides to enabled the prints on erase and write
  functions to make sure that how many bytes erase/write into flash
  device.
 
  Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
  ---
   drivers/mtd/spi/spi_flash.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
  index 00aece9..464c2ab 100644
  --- a/drivers/mtd/spi/spi_flash.c
  +++ b/drivers/mtd/spi/spi_flash.c
  @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash
  *flash, u32 offset,
  byte_addr = 0;
  }
 
  -   debug(SF: program %s %zu bytes @ %#x\n,
  +   printf(SF: program %s %zu bytes @ %#x\n,
ret ? failure : success, len, offset);

 I don't think we want this - it will make programming very slow and
 verbose.

 
  spi_release_bus(flash-spi);
  @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
  offset, size_t len)
  goto out;
  }
 
  -   debug(SF: Successfully erased %zu bytes @ %#x\n, len, start);
  +   printf(SF: Successfully erased %zu bytes @ %#x\n, len, start);

 You may want to put this code into cmd_sf instead, where it is
 reasonable to add messages. You are changing core spi code which might
 be used from many places.

 
out:
  spi_release_bus(flash-spi);
  --
  1.7.0.4
 
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] EXYNOS5: Add gpio pin numbering feature

[Simon Glass]

Hi,

On Wed, Dec 12, 2012 at 5:17 AM, Kyungmin Park kmp...@infradead.org wrote:
 Hi,

 On Wed, Dec 12, 2012 at 8:33 PM, Rajeshwari Shinde
 rajeshwar...@samsung.com wrote:
 This patch adds support for gpio pin numbering support on EXYNOS5
 pinmux.

 We already know that each exynos5 SoCs has different GPIO name and offsets.
 So it's good time to use proper soc prefix. e.g., EXYNOS5250_*.
 Since only exynos5250 is mainlined at this time.

Do you mean for the GPIO_ names? I am not so sure - after all only one
SOC can be included at a time, so we either use one numbering or
another, and this will make the names much longer.

I think this series should enable CMD_GPIO and it would be nice if
that command could support named GPIOs so we can use:

gpio set gpa0

for example.

Regards,
Simon


 Thank you,
 Kyungmin Park


 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
  arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +
  arch/arm/include/asm/arch-exynos/gpio.h |  360 
 ++-
  2 files changed, 413 insertions(+), 95 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
 b/arch/arm/cpu/armv7/exynos/pinmux.c
 index f02f441..9b4355a 100644
 --- a/arch/arm/cpu/armv7/exynos/pinmux.c
 +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
 @@ -28,89 +28,77 @@

  static void exynos5_uart_config(int peripheral)
  {
 -   struct exynos5_gpio_part1 *gpio1 =
 -   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 -   struct s5p_gpio_bank *bank;
 int i, start, count;

 switch (peripheral) {
 case PERIPH_ID_UART0:
 -   bank = gpio1-a0;
 -   start = 0;
 +   start = GPIO_A00;
 count = 4;
 break;
 case PERIPH_ID_UART1:
 -   bank = gpio1-d0;
 -   start = 0;
 +   start = GPIO_D00;
 count = 4;
 break;
 case PERIPH_ID_UART2:
 -   bank = gpio1-a1;
 -   start = 0;
 +   start = GPIO_A10;
 count = 4;
 break;
 case PERIPH_ID_UART3:
 -   bank = gpio1-a1;
 -   start = 4;
 +   start = GPIO_A14;
 count = 2;
 break;
 }
 for (i = start; i  start + count; i++) {
 -   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
 -   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
 +   gpio_set_pull(i, GPIO_PULL_NONE);
 +   gpio_cfg_pin(i, GPIO_FUNC(0x2));
 }
  }

  static int exynos5_mmc_config(int peripheral, int flags)
  {
 -   struct exynos5_gpio_part1 *gpio1 =
 -   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 -   struct s5p_gpio_bank *bank, *bank_ext;
 -   int i, start = 0, gpio_func = 0;
 +   int i, start, start_ext, gpio_func = 0;

 switch (peripheral) {
 case PERIPH_ID_SDMMC0:
 -   bank = gpio1-c0;
 -   bank_ext = gpio1-c1;
 -   start = 0;
 +   start = GPIO_C00;
 +   start_ext = GPIO_C10;
 gpio_func = GPIO_FUNC(0x2);
 break;
 case PERIPH_ID_SDMMC1:
 -   bank = gpio1-c2;
 -   bank_ext = NULL;
 +   start = GPIO_C20;
 +   start_ext = 0;
 break;
 case PERIPH_ID_SDMMC2:
 -   bank = gpio1-c3;
 -   bank_ext = gpio1-c4;
 -   start = 3;
 +   start = GPIO_C30;
 +   start_ext = GPIO_C43;
 gpio_func = GPIO_FUNC(0x3);
 break;
 case PERIPH_ID_SDMMC3:
 -   bank = gpio1-c4;
 -   bank_ext = NULL;
 +   start = GPIO_C40;
 +   start_ext = 0;
 break;
 }
 -   if ((flags  PINMUX_FLAG_8BIT_MODE)  !bank_ext) {
 +   if ((flags  PINMUX_FLAG_8BIT_MODE)  !start_ext) {
 debug(SDMMC device %d does not support 8bit mode,
 peripheral);
 return -1;
 }
 if (flags  PINMUX_FLAG_8BIT_MODE) {
 -   for (i = start; i = (start + 3); i++) {
 -   s5p_gpio_cfg_pin(bank_ext, i, gpio_func);
 -   s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_UP);
 -   s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
 +   for (i = start_ext; i = (start_ext + 3); i++) {
 +   gpio_cfg_pin(i, gpio_func);
 +   gpio_set_pull(i, GPIO_PULL_UP);
 +   gpio_set_drv(i, GPIO_DRV_4X);
 }
 }
 for (i = 0; i  2; i++) {
 -   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
 -   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
 -   

Re: [U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions

[Jagan Teki]

Hi Simon,

On Wed, Dec 12, 2012 at 8:31 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Wed, Dec 12, 2012 at 6:43 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:01 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Mon, Dec 10, 2012 at 10:37 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Simon,

 I understand your concern.

 But currently there is no prints a/f reading/writing/erasing the SPI flash.
 User's are unable to confirm whether that particular sf commands are
 properly done/not.

 Well if there is no error, then I suppose it worked ok. We should
 definitely print errors, and progress information can sometimes be
 useful for very long operations. But serial and LCD output is slow, so
 it can affect run time, quite apart from the verbosity, so IMO the
 less the better.

 Would it not be possible to put this message into cmd_sf.c?

 Yes it will possible to do this on cmd_sf.
 But I am not understanding what is the side effect, if we put in this area..
 will you please elaborate.

 Well if someone writes some code that calls the spi_flash interface
 from else where, such as:

 http://patchwork.ozlabs.org/patch/190164/

 or defines CONFIG_ENV_IS_IN_SPI_FLASH

 then your patch will start printing messages when none are required.

 By putting it in cmd_sf.c, and perhaps evening making it optional
 through a CONFIG_SF_VERBOSE, you make it possible for people to keep
 the existing behavior.

Thanks for your information.
Now I understood the whole scenario's.

OK, can I move the prints on cmd_sf.c with CONFIG_SF_VERBOSE?

Thanks,
Jagan.


 Regards,
 Simon


 Thanks,
 Jagan.

 Regards,
 Simon


 Thanks,
 Jagan.


 On Tue, Dec 11, 2012 at 12:56 AM, Simon Glass s...@chromium.org wrote:

 Hi,

 On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
  This patch provides to enabled the prints on erase and write
  functions to make sure that how many bytes erase/write into flash
  device.
 
  Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
  ---
   drivers/mtd/spi/spi_flash.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
  index 00aece9..464c2ab 100644
  --- a/drivers/mtd/spi/spi_flash.c
  +++ b/drivers/mtd/spi/spi_flash.c
  @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash
  *flash, u32 offset,
  byte_addr = 0;
  }
 
  -   debug(SF: program %s %zu bytes @ %#x\n,
  +   printf(SF: program %s %zu bytes @ %#x\n,
ret ? failure : success, len, offset);

 I don't think we want this - it will make programming very slow and
 verbose.

 
  spi_release_bus(flash-spi);
  @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
  offset, size_t len)
  goto out;
  }
 
  -   debug(SF: Successfully erased %zu bytes @ %#x\n, len, start);
  +   printf(SF: Successfully erased %zu bytes @ %#x\n, len, start);

 You may want to put this code into cmd_sf instead, where it is
 reasonable to add messages. You are changing core spi code which might
 be used from many places.

 
out:
  spi_release_bus(flash-spi);
  --
  1.7.0.4
 
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sf: Add configuration register writing

[Jagan Teki]

Hi Simon,

On Wed, Dec 12, 2012 at 12:05 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash config register.

 Configuration register contains the control bits used to configure
 the different configurations and security features of a device.

 User need to set these bits through spi_flash_cmd_write_config()
 based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
  drivers/mtd/spi/spi_flash.c  |   27 +++
  drivers/mtd/spi/spi_flash_internal.h |3 +++
  2 files changed, 30 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 800ed8b..a8f0af0 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -274,6 +274,33 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, 
 u8 sr)
 return 0;
  }

 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr)
 +{
 +   u8 cmd;
 +   int ret;
 +
 +   ret = spi_flash_cmd_write_enable(flash);
 +   if (ret  0) {
 +   debug(SF: enabling write failed\n);
 +   return ret;
 +   }
 +
 +   cmd = CMD_WRITE_STATUS;
 +   ret = spi_flash_cmd_write(flash-spi, cmd, 1, cr, 2);

 Does this assume a particular endianness? Perhaps should put the
 values into a byte array instead?

Yes it follows the endianness.

On my QPP patch,
ret = spi_flash_cmd_write_config(flash, 0x0200);

where 02 is config and 00 is status register
WRR have CMD+status+config = for CMD+16 data format.

Let me know if you need any info.

Thanks,
Jagan.


 +   if (ret) {
 +   debug(SF: fail to write config register\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
 +   if (ret  0) {
 +   debug(SF: write config register timed out\n);
 +   return ret;
 +   }
 +
 +   return 0;
 +}
 +
  /*
   * The following table holds all device probe functions
   *
 diff --git a/drivers/mtd/spi/spi_flash_internal.h 
 b/drivers/mtd/spi/spi_flash_internal.h
 index 141cfa8..9287778 100644
 --- a/drivers/mtd/spi/spi_flash_internal.h
 +++ b/drivers/mtd/spi/spi_flash_internal.h
 @@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
 spi_flash *flash)
  /* Program the status register. */
  int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);

 +/* Program the config register. */
 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr);
 +
  /*
   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
   * bus. Used as common part of the -read() operation.
 --
 1.7.0.4

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions

[Simon Glass]

+Mike who is the maintainer

On Wed, Dec 12, 2012 at 7:16 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 8:31 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Wed, Dec 12, 2012 at 6:43 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:01 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Mon, Dec 10, 2012 at 10:37 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Simon,

 I understand your concern.

 But currently there is no prints a/f reading/writing/erasing the SPI 
 flash.
 User's are unable to confirm whether that particular sf commands are
 properly done/not.

 Well if there is no error, then I suppose it worked ok. We should
 definitely print errors, and progress information can sometimes be
 useful for very long operations. But serial and LCD output is slow, so
 it can affect run time, quite apart from the verbosity, so IMO the
 less the better.

 Would it not be possible to put this message into cmd_sf.c?

 Yes it will possible to do this on cmd_sf.
 But I am not understanding what is the side effect, if we put in this area..
 will you please elaborate.

 Well if someone writes some code that calls the spi_flash interface
 from else where, such as:

 http://patchwork.ozlabs.org/patch/190164/

 or defines CONFIG_ENV_IS_IN_SPI_FLASH

 then your patch will start printing messages when none are required.

 By putting it in cmd_sf.c, and perhaps evening making it optional
 through a CONFIG_SF_VERBOSE, you make it possible for people to keep
 the existing behavior.

 Thanks for your information.
 Now I understood the whole scenario's.

 OK, can I move the prints on cmd_sf.c with CONFIG_SF_VERBOSE?

That would be my preference, but Mike might have thoughts on this.

Regards,
Simon


 Thanks,
 Jagan.


 Regards,
 Simon


 Thanks,
 Jagan.

 Regards,
 Simon


 Thanks,
 Jagan.


 On Tue, Dec 11, 2012 at 12:56 AM, Simon Glass s...@chromium.org wrote:

 Hi,

 On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
  This patch provides to enabled the prints on erase and write
  functions to make sure that how many bytes erase/write into flash
  device.
 
  Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
  ---
   drivers/mtd/spi/spi_flash.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
  index 00aece9..464c2ab 100644
  --- a/drivers/mtd/spi/spi_flash.c
  +++ b/drivers/mtd/spi/spi_flash.c
  @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash
  *flash, u32 offset,
  byte_addr = 0;
  }
 
  -   debug(SF: program %s %zu bytes @ %#x\n,
  +   printf(SF: program %s %zu bytes @ %#x\n,
ret ? failure : success, len, offset);

 I don't think we want this - it will make programming very slow and
 verbose.

 
  spi_release_bus(flash-spi);
  @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, 
  u32
  offset, size_t len)
  goto out;
  }
 
  -   debug(SF: Successfully erased %zu bytes @ %#x\n, len, start);
  +   printf(SF: Successfully erased %zu bytes @ %#x\n, len, 
  start);

 You may want to put this code into cmd_sf instead, where it is
 reasonable to add messages. You are changing core spi code which might
 be used from many places.

 
out:
  spi_release_bus(flash-spi);
  --
  1.7.0.4
 
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sf: Add configuration register writing

[Simon Glass]

Hi Jagan,

On Wed, Dec 12, 2012 at 7:20 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:05 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash config register.

 Configuration register contains the control bits used to configure
 the different configurations and security features of a device.

 User need to set these bits through spi_flash_cmd_write_config()
 based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
  drivers/mtd/spi/spi_flash.c  |   27 +++
  drivers/mtd/spi/spi_flash_internal.h |3 +++
  2 files changed, 30 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 800ed8b..a8f0af0 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -274,6 +274,33 @@ int spi_flash_cmd_write_status(struct spi_flash 
 *flash, u8 sr)
 return 0;
  }

 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr)
 +{
 +   u8 cmd;
 +   int ret;
 +
 +   ret = spi_flash_cmd_write_enable(flash);
 +   if (ret  0) {
 +   debug(SF: enabling write failed\n);
 +   return ret;
 +   }
 +
 +   cmd = CMD_WRITE_STATUS;
 +   ret = spi_flash_cmd_write(flash-spi, cmd, 1, cr, 2);

 Does this assume a particular endianness? Perhaps should put the
 values into a byte array instead?

 Yes it follows the endianness.

My concern was more that u16 is being used to send two bytes. How about:

u8 data[2];

put_unaligned_le16(cr, data)


 On my QPP patch,
 ret = spi_flash_cmd_write_config(flash, 0x0200);

 where 02 is config and 00 is status register
 WRR have CMD+status+config = for CMD+16 data format.

 Let me know if you need any info.

OK.

Regards,
Simon


 Thanks,
 Jagan.


 +   if (ret) {
 +   debug(SF: fail to write config register\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
 +   if (ret  0) {
 +   debug(SF: write config register timed out\n);
 +   return ret;
 +   }
 +
 +   return 0;
 +}
 +
  /*
   * The following table holds all device probe functions
   *
 diff --git a/drivers/mtd/spi/spi_flash_internal.h 
 b/drivers/mtd/spi/spi_flash_internal.h
 index 141cfa8..9287778 100644
 --- a/drivers/mtd/spi/spi_flash_internal.h
 +++ b/drivers/mtd/spi/spi_flash_internal.h
 @@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
 spi_flash *flash)
  /* Program the status register. */
  int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);

 +/* Program the config register. */
 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr);
 +
  /*
   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
   * bus. Used as common part of the -read() operation.
 --
 1.7.0.4

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 4/7] Tegra30: Add common CPU (shared) files

[Tom Warren]

Allen,

On Tue, Dec 11, 2012 at 5:45 PM, Allen Martin amar...@nvidia.com wrote:
 On Tue, Dec 11, 2012 at 03:34:15PM -0800, Tom Warren wrote:
 These files are used by both SPL and main U-Boot.
 Also made minor changes to shared Tegra code to support
 T30 differences.

 Signed-off-by: Tom Warren twar...@nvidia.com
 ---
 V2:
 * Differentiate between T20 and T30 in ODMDATA and query_sdram_size.
 * Fix numerous func entries in pingroup table as per Stephen.
 * Added warning about LOCK bit in pinmux_set_lock.
 V3:
 * Always program PLLP to 408MHz
 * Use generic SoC string in print_cpuinfo

snip

 -   bct_start = readl(AP20_BASE_PA_SRAM + NVBOOTINFOTABLE_BCTPTR);
 +   bct_start = readl(NV_PA_BASE_SRAM + NVBOOTINFOTABLE_BCTPTR);
 odmdata = readl(bct_start + BCT_ODMDATA_OFFSET);

 return odmdata;
 @@ -127,5 +137,5 @@ void s_init(void)
 orrr0, r0, #0x41\n
 mcrp15, 0, r0, c1, c0, 1\n);

 -   /* FIXME: should have ap20's L2 disabled too? */
 +   /* FIXME: should have SoC's L2 disabled too? */

 We should probably just remove this README, I don't believe it applies
 any more.

By README, you mean FIXME? It can be removed, but only if I'm forced
to do a V4 patchset for more substantive changes. Otherwise I'll put
it in my list of 'cleanup' items.


  }
 diff --git a/arch/arm/cpu/tegra-common/board.c 
 b/arch/arm/cpu/tegra-common/board.c
 index b2e10c6..af1879c 100644
 --- a/arch/arm/cpu/tegra-common/board.c
 +++ b/arch/arm/cpu/tegra-common/board.c
snip

  int dram_init(void)
 @@ -82,19 +103,27 @@ int checkboard(void)
  #endif /* CONFIG_DISPLAY_BOARDINFO */

  static int uart_configs[] = {
 -#if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
 +#if defined(CONFIG_TEGRA20)
 + #if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
 FUNCMUX_UART1_UAA_UAB,
 -#elif defined(CONFIG_TEGRA_UARTA_GPU)
 + #elif defined(CONFIG_TEGRA_UARTA_GPU)
 FUNCMUX_UART1_GPU,
 -#elif defined(CONFIG_TEGRA_UARTA_SDIO1)
 + #elif defined(CONFIG_TEGRA_UARTA_SDIO1)
 FUNCMUX_UART1_SDIO1,
 -#else
 + #else
 FUNCMUX_UART1_IRRX_IRTX,
 -#endif
 + #endif
 FUNCMUX_UART2_IRDA,
 -1,
 FUNCMUX_UART4_GMC,
 -1,
 +#else  /* Tegra30 */
 +   FUNCMUX_UART1_ULPI, /* UARTA */
 +   -1,
 +   -1,
 +   -1,
 +   -1,

 Shouldn't there be entries for other UART selections here?

Right now, there are no other T30 boards in my possession with any
other UARTs used for debug output. Stephen's soon-to-be-adopted
ODMDATA/ODMDATA2 changes will hopefully remove the need for these
tables.

snip

 diff --git a/arch/arm/cpu/arm720t/tegra30/Makefile 
 b/arch/arm/cpu/tegra30-common/Makefile
 similarity index 80%
 copy from arch/arm/cpu/arm720t/tegra30/Makefile
 copy to arch/arm/cpu/tegra30-common/Makefile
 index bd96997..75fef32 100644
 --- a/arch/arm/cpu/arm720t/tegra30/Makefile
 +++ b/arch/arm/cpu/tegra30-common/Makefile
 @@ -19,12 +19,15 @@

  include $(TOPDIR)/config.mk

 -LIB= $(obj)lib$(SOC).o
 +# The AVP is ARMv4T architecture so we must use special compiler
 +# flags for any startup files it might use.

 The SPL build should make this transparent to this Makefile.

Ill remove the comment if I do a V4 patchset, otherwise it'll go in
the 'cleanup' patchset.

Thanks,

Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sf: Add configuration register writing

[Jagan Teki]

Hi Simon,

On Wed, Dec 12, 2012 at 8:53 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Wed, Dec 12, 2012 at 7:20 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:05 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash config register.

 Configuration register contains the control bits used to configure
 the different configurations and security features of a device.

 User need to set these bits through spi_flash_cmd_write_config()
 based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
  drivers/mtd/spi/spi_flash.c  |   27 +++
  drivers/mtd/spi/spi_flash_internal.h |3 +++
  2 files changed, 30 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 800ed8b..a8f0af0 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -274,6 +274,33 @@ int spi_flash_cmd_write_status(struct spi_flash 
 *flash, u8 sr)
 return 0;
  }

 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr)
 +{
 +   u8 cmd;
 +   int ret;
 +
 +   ret = spi_flash_cmd_write_enable(flash);
 +   if (ret  0) {
 +   debug(SF: enabling write failed\n);
 +   return ret;
 +   }
 +
 +   cmd = CMD_WRITE_STATUS;
 +   ret = spi_flash_cmd_write(flash-spi, cmd, 1, cr, 2);

 Does this assume a particular endianness? Perhaps should put the
 values into a byte array instead?

 Yes it follows the endianness.

 My concern was more that u16 is being used to send two bytes. How about:

 u8 data[2];

Means I need to send status on data[1] and config on data[0].?


 put_unaligned_le16(cr, data)

I couldn't understand this, may be for endianness.?

Thanks,
Jagan.



 On my QPP patch,
 ret = spi_flash_cmd_write_config(flash, 0x0200);

 where 02 is config and 00 is status register
 WRR have CMD+status+config = for CMD+16 data format.

 Let me know if you need any info.

 OK.

 Regards,
 Simon


 Thanks,
 Jagan.


 +   if (ret) {
 +   debug(SF: fail to write config register\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
 +   if (ret  0) {
 +   debug(SF: write config register timed out\n);
 +   return ret;
 +   }
 +
 +   return 0;
 +}
 +
  /*
   * The following table holds all device probe functions
   *
 diff --git a/drivers/mtd/spi/spi_flash_internal.h 
 b/drivers/mtd/spi/spi_flash_internal.h
 index 141cfa8..9287778 100644
 --- a/drivers/mtd/spi/spi_flash_internal.h
 +++ b/drivers/mtd/spi/spi_flash_internal.h
 @@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
 spi_flash *flash)
  /* Program the status register. */
  int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);

 +/* Program the config register. */
 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr);
 +
  /*
   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
   * bus. Used as common part of the -read() operation.
 --
 1.7.0.4

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 1/7] Tegra30: Add arch-tegra30 include files

[Tom Warren]

Stephen,

On Tue, Dec 11, 2012 at 5:36 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 12/11/2012 04:34 PM, Tom Warren wrote:
 Common Tegra files are in arch-tegra, shared between T20 and T30.
 Tegra30-specific headers are in arch-tegra30. Note that some of
 these will be filled in as more T30 support is added (drivers,
 WB/LP0 support, etc.). A couple of Tegra20 files were changed
 to support common headers in arch-tegra, also.

 diff --git a/arch/arm/include/asm/arch-tegra/tegra.h 
 b/arch/arm/include/asm/arch-tegra/tegra.h

 + TEGRA_SOC2_SLOW,/* T2x needs to run at slow clock initially */

 I don't think that's used anywhere; drop it?

This is a series to add T30 support. I've done some changes to
combine/commonize shared files, etc., but I've tried to avoid any
T20-only changes whenever possible.

I'll add this as a note in my to-do cleanup patch list for T20.


 - TEGRA_SOC_COUNT,
 + TEGRA_SOC_CNT,

 A little arbitrary, but whatever.

Not arbitrary, I needed to keep the tegra_pll_x_table declaration in
common/cpu.c below 80 chars, and didn't like the look of it anywhere I
split it, so I decided to shrink this label a bit since it was only
used in that one place and would have the least impact.


 Aside from that, this patch,
 Reviewed-by: Stephen Warren swar...@nvidia.com

Thanks,

Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/7] Tegra30: Add AVP (arm720t) files

[Tom Warren]

Stephen,

On Tue, Dec 11, 2012 at 5:40 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 12/11/2012 04:34 PM, Tom Warren wrote:
 This provides SPL support for T30 boards - AVP early init, plus
 CPU (A9) init/jump to main U-Boot.

 Some changes were made to Tegra20 cpu.c to move common routines
 into tegra-common/cpu.c and reduce code duplication.

 diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
 b/arch/arm/cpu/arm720t/tegra-common/cpu.c

 +struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] 
 = {

 + /* TEGRA_SOC2_SLOW: 312 MHz */
 + {{ 312, 13, 0, 12}, /* OSC 13M */
 +  { 260, 16, 0, 8},  /* OSC 19.2M */
 +  { 312, 12, 0, 12}, /* OSC 12M */
 +  { 312, 26, 0, 12}, /* OSC 26M */
 + },

 Given my comment on patch 1, I'd suggest dropping that table entry too.

Will do, in a future cleanup patchset.


 Aside from that, this patch,
 Reviewed-by: Stephen Warren swar...@nvidia.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] usbh/ehci: Increase timeout for enumeration

[Marek Vasut]

Dear Vipin Kumar,

  +  ulong start = get_timer(0);
  +
  +  do {
  +  ret = usb_get_port_status(dev, i + 1, portsts);
  +  if (ret  0) {
  +  USB_HUB_PRINTF(get_port_status failed\n);
  +  break;
  +  }
  +
  +  portstatus = le16_to_cpu(portsts-wPortStatus);
  +  portchange = le16_to_cpu(portsts-wPortChange);
  +
  +  if ((portchange  USB_PORT_STAT_C_CONNECTION) ==
  +  (portstatus  USB_PORT_STAT_CONNECTION))
  
  I don't know if there is any corner case when the above check
  will always fail and so it will always wait a maximal delay time.
  Are those registers that identical, or can there be differences?
  
  +  break;
  +
  +  mdelay(100);
  +  } while (get_timer(start)  CONFIG_SYS_HZ * 10);
  
  Is there any justification for the CONFIG_SYS_HZ * 10?
  I would be much more fine with this patch if there were any
  (even just test based * 2) reason for that number.
 
 Not really. Just a practical test.
 Marek, can I have comments from you as well
 

Sorry, I'm really busy these days. I went through it and I see Igor still has 
some comment. Just fix that one and I'm good.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] sf: Add Quad-input Page Program(32h) instruction support

[Jagan Teki]

Hi Simon,

On Wed, Dec 12, 2012 at 12:11 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash using
 Quad-input Page Program(32h) instruction.

 This will effectively increases the data transfer rate
 by up to four times, as compared to the Page Program(PP) instruction.

 Respective flash drivers need to use spi_flash_cmd_write_multi_qpp()
 based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com

 It's great to have this support. A few comments below.

Thanks.


 ---
  README   |1 +
  common/cmd_sf.c  |   12 +++-
  drivers/mtd/spi/spi_flash.c  |  108 
 ++
  drivers/mtd/spi/spi_flash_internal.h |   13 
  include/spi_flash.h  |   12 
  5 files changed, 144 insertions(+), 2 deletions(-)

 diff --git a/README b/README
 index 5a86ae9..a01de13 100644
 --- a/README
 +++ b/README
 @@ -869,6 +869,7 @@ The following options need to be configured:
 CONFIG_CMD_SETGETDCR  Support for DCR Register access
   (4xx only)
 CONFIG_CMD_SF   * Read/write/erase SPI NOR flash
 +   CONFIG_CMD_SF_QPP   * Program SPI flash using Quad-input 
 Page Program
 CONFIG_CMD_SHA1SUMprint sha1 memory digest
   (requires CONFIG_CMD_MEMORY)
 CONFIG_CMD_SOURCE source command Support
 diff --git a/common/cmd_sf.c b/common/cmd_sf.c
 index 5ac1d0c..a449d2c 100644
 --- a/common/cmd_sf.c
 +++ b/common/cmd_sf.c
 @@ -228,6 +228,10 @@ static int do_spi_flash_read_write(int argc, char * 
 const argv[])
 ret = spi_flash_update(flash, offset, len, buf);
 else if (strcmp(argv[0], read) == 0)
 ret = spi_flash_read(flash, offset, len, buf);
 +#ifdef CONFIG_CMD_SF_QPP
 +   else if (strcmp(argv[0], write.qpp) == 0)
 +   ret = spi_flash_write_qpp(flash, offset, len, buf);
 +#endif
 else
 ret = spi_flash_write(flash, offset, len, buf);

 @@ -300,7 +304,7 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int 
 argc, char * const argv[
 }

 if (strcmp(cmd, read) == 0 || strcmp(cmd, write) == 0 ||
 -   strcmp(cmd, update) == 0)
 +   strcmp(cmd, update) == 0 || strcmp(cmd, write.qpp) == 0)
 ret = do_spi_flash_read_write(argc, argv);
 else if (strcmp(cmd, erase) == 0)
 ret = do_spi_flash_erase(argc, argv);
 @@ -327,5 +331,9 @@ U_BOOT_CMD(
 sf erase offset [+]len - erase `len' bytes from `offset'\n
  `+len' round up `len' to block 
 size\n
 sf update addr offset len  - erase and write `len' bytes from 
 memory\n
 -at `addr' to flash at `offset'
 +at `addr' to flash at `offset'\n
 +#ifdef CONFIG_CMD_SF_QPP
 +   sf write.qpp addr offset len   - write `len' bytes from memory\n
 +at `addr' to flash at `offset' 
 using Quad-input Page Program(32h)
 +#endif
  );
 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index a8f0af0..3545f59 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -122,6 +122,114 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, 
 u32 offset,
 return ret;
  }

 +#ifdef CONFIG_CMD_SF_QPP
 +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
 +{
 +   u8 cmd = CMD_READ_CONFIG;
 +   u8 data = 0;
 +   int ret;
 +
 +   ret = spi_flash_read_common(flash,
 +   cmd, sizeof(cmd), data, sizeof(data));
 +   if (ret  0) {
 +   debug(SF: fail to read config register\n);
 +   return ret;
 +   }
 +
 +   if (data  0x2) {

 Can we have defines/enums for this please?

Yes I will do.


 +   debug(SF: quad enable bit is already set.\n);
 +   return ret;
 +   } else {
 +   debug(SF: need to set quad enable bit\n);
 +
 +   ret = spi_flash_cmd_write_config(flash, 0x0200);

 and here?

Ok.


 +   if (ret  0) {
 +   debug(SF: fail to write quad enable bit\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_read_common(flash,
 +   cmd, sizeof(cmd), data, sizeof(data));
 +   if (ret  0) {
 +   debug(SF: fail to read config register\n);
 +   return ret;
 +   }

 It almost seems like you could have a loop here: read it, return if
 ok, write it, then loop again (up to two times). Might reduce the code
 length, 

Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup

[Marek Vasut]

Dear Tom Rini,

 On 12/10/12 19:47, Marek Vasut wrote:
  Dear Lukasz Majewski,
  
  Pantelis,
  
  [...]
  
  Hm hm ... I suspect it'd be nice to have a separate DFU custodian.
  That'd leverage some burden from me. I like that idea. I wonder if
  it'd be nice to start building such bigger net of custodians.
 
 So long as everyone involved plays nice, we have a maintainer of the
 code (Lukasz) and another user / developer of the code (Pantelis).  I
 don't think we need to go full on custodian right now.  Lukasz is
 reviewing and trying to understand what Pantelis is seeing since we're
 seeing some odd issues on the second platform to add DFU support.

WFM, but it'd leverage burden from me. And I honestly dont understand the DFU 
as 
much as Lukasz does.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/12 12:55, Marek Vasut wrote:
 Dear Tom Rini,
 
 On 12/10/12 19:47, Marek Vasut wrote:
 Dear Lukasz Majewski,
 
 Pantelis,
 
 [...]
 
 Hm hm ... I suspect it'd be nice to have a separate DFU
 custodian. That'd leverage some burden from me. I like that
 idea. I wonder if it'd be nice to start building such bigger
 net of custodians.
 
 So long as everyone involved plays nice, we have a maintainer of
 the code (Lukasz) and another user / developer of the code
 (Pantelis).  I don't think we need to go full on custodian right
 now.  Lukasz is reviewing and trying to understand what Pantelis
 is seeing since we're seeing some odd issues on the second
 platform to add DFU support.
 
 WFM, but it'd leverage burden from me. And I honestly dont
 understand the DFU as much as Lukasz does.

That's fine.  Lean on maintainers as much as they're agreeable to.
I'm sure (well, I hope and assume) Lukasz would like to ack anything
DFU related that goes in and if you don't want to pull for u-boot-usb
until he does, that's fine and good with me.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQyMbsAAoJENk4IS6UOR1W/nUP/05xGbixnO450kJyxMCQZGc2
0QHAy41jTqGnBKGLutZE0ged/lKxo2UwNbAklJc/EixILFLIjOaRpNlKARo7G4hH
NHX8SXYgHVUY4R1fWgciH/gMO+lNAsLOP30peR0KtQyL6EBmC7fEUxjEPUKsCKWy
RA8AOG9QBD88k1wt2GxEkuXlONpPO9/LTb39ZPrUgfo9iG8oTEcYWq98OfitWKvf
Rd3q2XxUpu1UxUxh4ThPE1uj9V5l+d5eeTYismOcB/WvjAAJ0o6H26MDov1Z49TP
9ezB++NEzAoh5VO2WMBmruLBUBZkvl+XQLHCLgGy62Zvw5EYolYdQu0+2TYsNB17
kxWDdZEi0t+y+uZ3qSXcxnTta/yAwvv0LeE6mODA1h8Q717qlBSkCch2Nr3jwYU5
LbPvnAVHX+f1gslGmiL192uCpQ0YtNE+0McHSQ55/P9s+aZrOnlkZApLvAfKyQJr
E9bufbgeey3JXa8O64mVNX8rDcvVPXftdP1Hqbrw42UkCK89KiskTjQ7PYO2yVpq
Ge/JnJzNnYDtf3YCbM8iIM7rUo228ugG8d7Wd9t0ISimT3zU05KoNdOOIqiCsmAd
FLyC9tjQqctic1kh2+KBBAaNy3rpKaDDb2LOpjYjaQsftDOUJ0zBxcCinh5GPI7n
yYnG1XxwV1sqT1Fov49x
=YfYD
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imls: Add support to list images in NAND device

[Wolfgang Denk]

Dear Vipin Kumar,

In message 
dba14c4ffef38a108f75342968bcd9ce2b75c4c7.1355303894.git.vipin.ku...@st.com 
you wrote:
 imls does not list the images in NAND devices. This patch implements this
 support for legacy type images.
...
 -static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 +static void do_imls_flash(void)

Why is this void?  Should we not return error codes? Or at least be
able to?

 +static void do_imls_nand(void)

Ditto.


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
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/8] TMU: Add u-boot command to read current temp

[Wolfgang Denk]

Dear Simon Glass,

In message CAPnjgZ18daUnwQtAxtPOU43EGLA7=tn0efutbbzkntdy8da...@mail.gmail.com 
you wrote:
 
  Do we really need a new command here?
 
  We already have dtt, which basicly does the same.
 
  It makes no sense to add new commands for each new device, all doing
  basicly trhe same, just in an incompatible way.
 
 This patch feature does not use i2c as the temperature measurement is
 inside the SOC. I wonder whether cmd_dtt.c could be extended so that
 it only does the i2c stuff if CONFIG_SYS_DTT_BUS_NUM is defined. Then
 you could use dtt_get_temp() to get the termperature as now.

Dtt should actually be completely agnostic of the underlying method to
access the devices it operates on.  If such generalization is needed
now, then yes, it should be added.

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
I used to think that the brain was the most wonderful  organ  in  my
body. Then I realized who was telling me this.- Emo Phillips
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] EXYNOS5: Power down API for Thermal Management Unit

[Wolfgang Denk]

Dear Simon Glass,

In message capnjgz0biqyy-k0rbrlomkqfk6pc1rjvgtmbluvp3wr9uss...@mail.gmail.com 
you wrote:
 
  If we add something like this, it should be general enough to be used
  by other systems as well, i. e. please chose a generic API like plain
  poweroff() or similar.
 
 Maybe rename the function and move to a new include/power.h header,
 with the implementation staying where it is?

Assuming there is no common code to be expected, yes.

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
Only two things are infinite,  the universe and human stupidity,  and
I'm not sure about the former. -- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

Dear Simon Glass,

In message CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6wq4cdob0zqmgi7xwgw...@mail.gmail.com 
you wrote:
 
 If anything like this gets implemented, it has to be done in a way
 that will be general enough to be useful to others as well.
 
 Yes. It isn't really clear how this sort of thing should be done, but
 creating a board polling function seems like a reasonable idea. It's
 then just a question of when to call it. Since there is no particular
 idle or event loop in U-Boot, perhaps we need to create one, and the
 console code is probably the only sensible place since it is waiting
 for user input.

No, using the console driver for such a hook is not sensible at all.

Do we really have to re-invent the wheel each time we need one?

If we need a periodic service, then this should be obviously (at least
this seems obvious to me) be bound to the timer services.  On PPC, we
could for example simply hook it in the timer interrupt.

Also, this should not be considered as somethin board specific as the
name board polling function might suggest.  What is being discussed
here is not more and not less than support for periodic, asynchronous
services.  So let's call it that, so everybody understand what it's
about.

 I am not sure about the general issue. Obviously some sort of
 background activity is going on in the chip all the time, and
 monitoring is sometimes necessary. I am not sure about the best
 approach for this.

I agree about the sometimes necessary.  In this specific case, I
doubt is this is one of these some cases.  But I asked this before.

 By monitoring temperature we can be sure that the system does not
 overheat - it does depend on the hardware of course (power output,
 heatsinks) but it can happen very quickly, certainly within a few 10s
 of seconds.

Is this some theoretical consideration, or does it refer to the actual
state of a specific piece of hardware?

Assume we have such a system - how would it be going to be used?
Example:

- power on
- U-Boot enters (either directly or as a result of some boot
  error or similar) the interactive command line interface and
  waits for input from the user
- temperature monitoring detects overheating
- system powers down

How would one recover from that?

Would it not make much more sense to bring up the system in such a
mode of operation that no overheating will happen?

  This needs a lot of additional thought, and major changes to the
  implementation.
 
 Perhaps add a new idle function in common code which can be called
 from various places (including console), and itself calls
 board_poll_devices()? That is cosmetic, but does at least detach the
 code from the console.

No.  This is crap.  If we need a periodic service, we should implement
one, and not add hooks here and there at random.  We already did this
once (for the watchdog triggering), and look what a crap it is. We
should not repeat this.

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
I often quote myself; it adds spice to my conversation.  - G. B. Shaw
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/t4qds: move VSC3316 config data from t4qds.h to t4qds.c

[Timur Tabi]

Static variables should be defined in C files, not header files, because
otherwise every C file that #includes the header file will generate a
duplicate of the variables.  Since the vsc3316_xxx[] arrays are only
used by t4qds.c anyway, just put the variables there.

Signed-off-by: Timur Tabi ti...@freescale.com
---
 board/freescale/t4qds/t4qds.c |   12 
 board/freescale/t4qds/t4qds.h |   11 ---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/board/freescale/t4qds/t4qds.c b/board/freescale/t4qds/t4qds.c
index 88b8ced..392c8c0 100644
--- a/board/freescale/t4qds/t4qds.c
+++ b/board/freescale/t4qds/t4qds.c
@@ -42,6 +42,18 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+static const int8_t vsc3316_fsm1_tx[8][2] = { {0, 0}, {1, 1}, {6, 6}, {7, 7},
+   {8, 8}, {9, 9}, {14, 14}, {15, 15} };
+
+static const int8_t vsc3316_fsm2_tx[8][2] = { {2, 2}, {3, 3}, {4, 4}, {5, 5},
+   {10, 10}, {11, 11}, {12, 12}, {13, 13} };
+
+static const int8_t vsc3316_fsm1_rx[8][2] = { {2, 12}, {3, 13}, {4, 5}, {5, 4},
+   {10, 11}, {11, 10}, {12, 2}, {13, 3} };
+
+static const int8_t vsc3316_fsm2_rx[8][2] = { {0, 15}, {1, 14}, {6, 7}, {7, 6},
+   {8, 9}, {9, 8}, {14, 1}, {15, 0} };
+
 int checkboard(void)
 {
u8 sw;
diff --git a/board/freescale/t4qds/t4qds.h b/board/freescale/t4qds/t4qds.h
index c6a3492..f290f3c 100644
--- a/board/freescale/t4qds/t4qds.h
+++ b/board/freescale/t4qds/t4qds.h
@@ -23,15 +23,4 @@
 void fdt_fixup_board_enet(void *blob);
 void pci_of_setup(void *blob, bd_t *bd);
 
-static const int8_t vsc3316_fsm1_tx[8][2] = { {0, 0}, {1, 1}, {6, 6}, {7, 7},
-   {8, 8}, {9, 9}, {14, 14}, {15, 15} };
-
-static const int8_t vsc3316_fsm2_tx[8][2] = { {2, 2}, {3, 3}, {4, 4}, {5, 5},
-   {10, 10}, {11, 11}, {12, 12}, {13, 13} };
-
-static const int8_t vsc3316_fsm1_rx[8][2] = { {2, 12}, {3, 13}, {4, 5}, {5, 4},
-   {10, 11}, {11, 10}, {12, 2}, {13, 3} };
-
-static const int8_t vsc3316_fsm2_rx[8][2] = { {0, 15}, {1, 14}, {6, 7}, {7, 6},
-   {8, 9}, {9, 8}, {14, 1}, {15, 0} };
 #endif
-- 
1.7.3.4


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Simon Glass]

Hi Wolfgang,

On Wed, Dec 12, 2012 at 12:44 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 
 CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6wq4cdob0zqmgi7xwgw...@mail.gmail.com you 
 wrote:

 If anything like this gets implemented, it has to be done in a way
 that will be general enough to be useful to others as well.

 Yes. It isn't really clear how this sort of thing should be done, but
 creating a board polling function seems like a reasonable idea. It's
 then just a question of when to call it. Since there is no particular
 idle or event loop in U-Boot, perhaps we need to create one, and the
 console code is probably the only sensible place since it is waiting
 for user input.

 No, using the console driver for such a hook is not sensible at all.

 Do we really have to re-invent the wheel each time we need one?

 If we need a periodic service, then this should be obviously (at least
 this seems obvious to me) be bound to the timer services.  On PPC, we
 could for example simply hook it in the timer interrupt.

 Also, this should not be considered as somethin board specific as the
 name board polling function might suggest.  What is being discussed
 here is not more and not less than support for periodic, asynchronous
 services.  So let's call it that, so everybody understand what it's
 about.

Well that means interrupts. Are you suggesting that we implement
generic timers and allow drivers to register a timer callback function
to be called periodically? That seems like a bold move, but we could
do it.


 I am not sure about the general issue. Obviously some sort of
 background activity is going on in the chip all the time, and
 monitoring is sometimes necessary. I am not sure about the best
 approach for this.

 I agree about the sometimes necessary.  In this specific case, I
 doubt is this is one of these some cases.  But I asked this before.

 By monitoring temperature we can be sure that the system does not
 overheat - it does depend on the hardware of course (power output,
 heatsinks) but it can happen very quickly, certainly within a few 10s
 of seconds.

 Is this some theoretical consideration, or does it refer to the actual
 state of a specific piece of hardware?

 Assume we have such a system - how would it be going to be used?
 Example:

 - power on
 - U-Boot enters (either directly or as a result of some boot
   error or similar) the interactive command line interface and
   waits for input from the user
 - temperature monitoring detects overheating
 - system powers down

 How would one recover from that?

Firstly we can detect that the system is idle (by noticing that it has
been long time since a keypress, for example), and reduce the CPU
clock speed until we next see a key. This might be enough to remove
the problem. Perhaps we should add some sort of feature to console to
record the time of last key input to facilitate that. There are lots
of ways to do it.

Secondly, when the system warms up we can display a warning on the
console, and perhaps reduce CPU speed further.

Thirdly, when the system starts to melt, we can power it off.


 Would it not make much more sense to bring up the system in such a
 mode of operation that no overheating will happen?

Yes, but perhaps only by running very slowly. In the normal case we
are only in U-Boot for a short period so want to run at full speed.


  This needs a lot of additional thought, and major changes to the
  implementation.

 Perhaps add a new idle function in common code which can be called
 from various places (including console), and itself calls
 board_poll_devices()? That is cosmetic, but does at least detach the
 code from the console.

 No.  This is crap.  If we need a periodic service, we should implement
 one, and not add hooks here and there at random.  We already did this
 once (for the watchdog triggering), and look what a crap it is. We
 should not repeat this.

Yes I'm not a big fan of putting calls everywhere, but in a sense this
is pointing us towards an idle loop, something that we declare must be
called periodically for U-Boot to function. A timer doesn't
necessarily suit the watchdog, since we may have locked up in an
infinite loop somewhere due to a s/w or h/w problem - in that case we
don't want to kick the watchdog on an interval, only when we know that
the system is happy.

So it seems that some sort of timer hook might be good for the patch
under discussion, but for the watchdog we need an idle loop or
similar. The timer hook does open a bit of a can of worms for other
reasons - e.g. you are in the middle of an i2c transaction, the timer
fires, you jump to the temperature monitor which wants to use i2c to
find out the temperature. I thought we wanted to avoid this sort of
thing in U-Boot so long as possible.

We could perhaps add an 'idle hook' so that callers can register themselves:

int idle_register_handler(int (*callback_fn)(void), void *priv);
int 

Re: [U-Boot] One basic U-boot question

[Scott Wood]

On 12/12/2012 02:11:46 AM, Martin Peevski wrote:
Hello, I have the following question. It is about the adresses  
where the U-boot and  Linux Kernel are copyed in the SDRAM from NAND.


In my board config file I have:
#define CONFIG_SYS_LOAD_ADDR0x2200/* load address  
*/

Is that the load address of the U-boot?


No, it's the default address to load the kernel (or other image).  Note  
that this is where the uImage goes, not where the kernel gets  
uncompressed to (which is specified in the uImage header).


U-Boot is loaded near the top of SDRAM (or the portion of SDRAM that  
U-Boot has mapped).


BTW, you should use a subject line that is more specific to your  
question, such as What is CONFIG_SYS_LOAD_ADDR? or Where does the  
kernel get loaded with command name?.  One basic U-Boot question  
doesn't give any clues to people skimming the list to see if it's the  
sort of question they might have the answer to.


Also where is defined the load address of the Kernel because may  
be I need to leave more free space about the Kernel and RootFS?


CONFIG_SYS_LOAD_ADDR is the default, but you can and should override it  
in the arguments to the command doing the loading.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup

[Marek Vasut]

Dear Lukasz Majewski,

 Hi Pantelis,
 
  Tomorrow I will prepare output of USB Ellisys analizer on my side, so
  we could get clue what is going on.
 
 Please find attached output from USB ellisys analizer.
 
 (It is possible to download WinXP based program to view logs without
 USB analizer box).
 
 What I see in the current implementation stalls on GetDescriptor
 (Class: 0x21),but afterwards transmission is performed.

Or run u-boot in qemu and tunnel it through usbmon :p

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup

[Marek Vasut]

Dear Robert P. J. Day,

 On Tue, 11 Dec 2012, Lukasz Majewski wrote:
  Hi Pantelis,
  
   Tomorrow I will prepare output of USB Ellisys analizer on my side, so
   we could get clue what is going on.
  
  Please find attached output from USB ellisys analizer.
 
   is it really appropriate to post 8M of output to a mailing
 list?  what's wrong with pastebin?

:rageface:

http://www.ietf.org/rfc/rfc1855.txt

 rday

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 1/7] Tegra30: Add arch-tegra30 include files

[Stephen Warren]

On 12/12/2012 09:23 AM, Tom Warren wrote:
 Stephen,
 
 On Tue, Dec 11, 2012 at 5:36 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 12/11/2012 04:34 PM, Tom Warren wrote:
 Common Tegra files are in arch-tegra, shared between T20 and T30.
 Tegra30-specific headers are in arch-tegra30. Note that some of
 these will be filled in as more T30 support is added (drivers,
 WB/LP0 support, etc.). A couple of Tegra20 files were changed
 to support common headers in arch-tegra, also.

 diff --git a/arch/arm/include/asm/arch-tegra/tegra.h 
 b/arch/arm/include/asm/arch-tegra/tegra.h

 + TEGRA_SOC2_SLOW,/* T2x needs to run at slow clock initially */

 I don't think that's used anywhere; drop it?
 
 This is a series to add T30 support. I've done some changes to
 combine/commonize shared files, etc., but I've tried to avoid any
 T20-only changes whenever possible.
 
 I'll add this as a note in my to-do cleanup patch list for T20.

My point here was that this patch adds that unused enum. I think you can
just drop the addition from the patch, and it'll never need to be
cleaned up?

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 4/7] Tegra30: Add common CPU (shared) files

[Stephen Warren]

On 12/12/2012 09:14 AM, Tom Warren wrote:
 Allen,
 
 On Tue, Dec 11, 2012 at 5:45 PM, Allen Martin amar...@nvidia.com wrote:
 On Tue, Dec 11, 2012 at 03:34:15PM -0800, Tom Warren wrote:
 These files are used by both SPL and main U-Boot.
 Also made minor changes to shared Tegra code to support
 T30 differences.

 Signed-off-by: Tom Warren twar...@nvidia.com
 ---
 V2:
 * Differentiate between T20 and T30 in ODMDATA and query_sdram_size.
 * Fix numerous func entries in pingroup table as per Stephen.
 * Added warning about LOCK bit in pinmux_set_lock.
 V3:
 * Always program PLLP to 408MHz
 * Use generic SoC string in print_cpuinfo

 snip

 -   bct_start = readl(AP20_BASE_PA_SRAM + NVBOOTINFOTABLE_BCTPTR);
 +   bct_start = readl(NV_PA_BASE_SRAM + NVBOOTINFOTABLE_BCTPTR);
 odmdata = readl(bct_start + BCT_ODMDATA_OFFSET);

 return odmdata;
 @@ -127,5 +137,5 @@ void s_init(void)
 orrr0, r0, #0x41\n
 mcrp15, 0, r0, c1, c0, 1\n);

 -   /* FIXME: should have ap20's L2 disabled too? */
 +   /* FIXME: should have SoC's L2 disabled too? */

 We should probably just remove this README, I don't believe it applies
 any more.
 
 By README, you mean FIXME? It can be removed, but only if I'm forced
 to do a V4 patchset for more substantive changes. Otherwise I'll put
 it in my list of 'cleanup' items.

In my opinion at least, for very minor stuff like this, you can just
implement the review feedback and apply the patches without the need to
actually repost it. Anything much more than editing a comment, removing
a stale comment or removing some added lines from the patch that
shouldn't be added would warrant a repost though.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 4/7] Tegra30: Add common CPU (shared) files

[Stephen Warren]

On 12/11/2012 04:34 PM, Tom Warren wrote:
 These files are used by both SPL and main U-Boot.
 Also made minor changes to shared Tegra code to support
 T30 differences.

Reviewed-by: Stephen Warren swar...@nvidia.com

(briefly!)

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 5/7] Tegra30: Cardhu: Add DT files

[Stephen Warren]

On 12/11/2012 04:34 PM, Tom Warren wrote:
 These are stripped down for bringup, They'll be filled out later
 to match-up with the kernel DT contents, and/or as devices are
 brought up (mmc, usb, spi, etc.).

 diff --git a/board/nvidia/dts/tegra30-cardhu.dts 
 b/board/nvidia/dts/tegra30-cardhu.dts

 +/memreserve/ 0x1c00 0x0400;

We should drop that line. Aside from that,

Reviewed-by: Stephen Warren swar...@nvidia.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

Dear Simon Glass,

In message CAPnjgZ0bmsJAx4MAk-+GLo+QLC-6zbgp24N=BNqO=2fsuik...@mail.gmail.com 
you wrote:
 
  Also, this should not be considered as somethin board specific as the
  name board polling function might suggest.  What is being discussed
  here is not more and not less than support for periodic, asynchronous
  services.  So let's call it that, so everybody understand what it's
  about.
 
 Well that means interrupts. Are you suggesting that we implement
 generic timers and allow drivers to register a timer callback function
 to be called periodically? That seems like a bold move, but we could
 do it.

Which architectures do not use interrupts for the timer services?

  How would one recover from that?
 
 Firstly we can detect that the system is idle (by noticing that it has
 been long time since a keypress, for example), and reduce the CPU
 clock speed until we next see a key. This might be enough to remove
 the problem. Perhaps we should add some sort of feature to console to

No, this is just a crappy design.

Assume you load some big image and write it to NAND (or you do other
operations that take some time; eventually in a loop).  Your keyboard
dependet code would not trigger here, and you would just overheat the
system.

I mean, what good is such protection when a simple while : ; do : ;
done will just toast your box?

 record the time of last key input to facilitate that. There are lots
 of ways to do it.

Sorry, but keyboard activity has _nothing_ to do ith it and is the
totally wrong place to attach such functionality to.

 Secondly, when the system warms up we can display a warning on the
 console, and perhaps reduce CPU speed further.
 
 Thirdly, when the system starts to melt, we can power it off.

Would you ever buy such a design?  I wouldn't.  And any competing
company would probably have excellent arguments for their own
marketing material.

 So it seems that some sort of timer hook might be good for the patch
 under discussion, but for the watchdog we need an idle loop or

I don;t understand your arguments here.  You are aware that we don;t
really have watchdog support in U-Boot (not in the sense that we
monitor U-Boot's operation) - we only make sure to trigger it
periodically.

 similar. The timer hook does open a bit of a can of worms for other
 reasons - e.g. you are in the middle of an i2c transaction, the timer
 fires, you jump to the temperature monitor which wants to use i2c to
 find out the temperature. I thought we wanted to avoid this sort of
 thing in U-Boot so long as possible.

Yes, we definitely do want to avoid this, which is the reson why I
insist on asking of we actually need such a feature in U-Boot.  If the
hardware cannot protect itself sufficiently and relies on software
support, you are doomed anyway, because somebody will always just do
some stupid things and find out that he detected a HCF macro...

 We could perhaps add an 'idle hook' so that callers can register themselves:

Where exactly would you hook that to, if not to some timer interrupt?

ANd please tink about this again - if you talk about an 'idle hook',
you actually are talking about an idle task, i. e. about introducing
a multi-task concept (even if it's just a simple one).

This is not exactly a small can of worms, and I guess these worms have
a smell ...

 and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.

Oh.  Cooperative multitasking...

Are you really, really sure we want to do that?

 We could perhaps have a flags parameter to permit selection of what
 sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog
 reset, IDLE_POLL_ALL to call all the registered handlers).
 
 The hooks could then be generalised to support timers, with the
 proviso that timers are only ever invoked from the idle loop so that

Yes, we can do all that.  We can actually implement a full-blown OS.

Are you really, really sure we want to do that?

 Any of the above is much more radical than this patch.

But the patch as submitted here is not even functional...

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
Weekends were made for programming. - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 6/7] Tegra30: Add generic Tegra30 build support

[Stephen Warren]

On 12/11/2012 04:34 PM, Tom Warren wrote:
 This patch adds basic Tegra30 (T30) build support - no specific
 board is targeted.

Reviewed-by: Stephen Warren swar...@nvidia.com

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 7/7] Tegra30: Add/enable Cardhu build (T30 reference board)

[Stephen Warren]

On 12/11/2012 04:34 PM, Tom Warren wrote:
 This build is stripped down. It boots to the command prompt.
 GPIO is the only peripheral supported. Others TBD.
 
 include/configs/tegra-common.h now holds common config options
 for Tegra SoCs.

Reviewed-by: Stephen Warren swar...@nvidia.com

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] sf: Add print message on flash read function

[Simon Glass]

On Wed, Dec 12, 2012 at 6:46 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:03 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch adds a print message on spi_flash_cmd_read_fast()
 to make sure that how many bytes read from flash device.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com

 I have the same verbosity comment on this patch, BTW.

 This is also needs to put it on cmd_sf,c?

I would say so, yes.


 Thanks,
 Jagan.


 Regards,
 Simon

 ---
  drivers/mtd/spi/spi_flash.c |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 464c2ab..800ed8b 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -139,12 +139,17 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, 
 u32 offset,
 size_t len, void *data)
  {
 u8 cmd[5];
 +   int ret;

 cmd[0] = CMD_READ_ARRAY_FAST;
 spi_flash_addr(offset, cmd);
 cmd[4] = 0x00;

 -   return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
 +   ret = spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
 +   printf(SF: re-program %s %zu bytes @ %#x\n,
 +   ret ? failure : success, len, offset);
 +
 +   return ret;
  }

  int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
 --
 1.7.0.4

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sf: Add configuration register writing

[Simon Glass]

Hi Jagan,

On Wed, Dec 12, 2012 at 8:21 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 8:53 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Wed, Dec 12, 2012 at 7:20 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:05 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash config register.

 Configuration register contains the control bits used to configure
 the different configurations and security features of a device.

 User need to set these bits through spi_flash_cmd_write_config()
 based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
  drivers/mtd/spi/spi_flash.c  |   27 +++
  drivers/mtd/spi/spi_flash_internal.h |3 +++
  2 files changed, 30 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 800ed8b..a8f0af0 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -274,6 +274,33 @@ int spi_flash_cmd_write_status(struct spi_flash 
 *flash, u8 sr)
 return 0;
  }

 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr)
 +{
 +   u8 cmd;
 +   int ret;
 +
 +   ret = spi_flash_cmd_write_enable(flash);
 +   if (ret  0) {
 +   debug(SF: enabling write failed\n);
 +   return ret;
 +   }
 +
 +   cmd = CMD_WRITE_STATUS;
 +   ret = spi_flash_cmd_write(flash-spi, cmd, 1, cr, 2);

 Does this assume a particular endianness? Perhaps should put the
 values into a byte array instead?

 Yes it follows the endianness.

 My concern was more that u16 is being used to send two bytes. How about:

 u8 data[2];

 Means I need to send status on data[1] and config on data[0].?


 put_unaligned_le16(cr, data)

 I couldn't understand this, may be for endianness.?

Yes that's right. Just checking that your code will work correctly on
a big-endian machine. Will it? It is normally not a good idea to cast
a short into a char[2].

Regards,
Simon


 Thanks,
 Jagan.



 On my QPP patch,
 ret = spi_flash_cmd_write_config(flash, 0x0200);

 where 02 is config and 00 is status register
 WRR have CMD+status+config = for CMD+16 data format.

 Let me know if you need any info.

 OK.

 Regards,
 Simon


 Thanks,
 Jagan.


 +   if (ret) {
 +   debug(SF: fail to write config register\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
 +   if (ret  0) {
 +   debug(SF: write config register timed out\n);
 +   return ret;
 +   }
 +
 +   return 0;
 +}
 +
  /*
   * The following table holds all device probe functions
   *
 diff --git a/drivers/mtd/spi/spi_flash_internal.h 
 b/drivers/mtd/spi/spi_flash_internal.h
 index 141cfa8..9287778 100644
 --- a/drivers/mtd/spi/spi_flash_internal.h
 +++ b/drivers/mtd/spi/spi_flash_internal.h
 @@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
 spi_flash *flash)
  /* Program the status register. */
  int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);

 +/* Program the config register. */
 +int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr);
 +
  /*
   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
   * bus. Used as common part of the -read() operation.
 --
 1.7.0.4

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

 Regards,
 Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] sf: Add Quad-input Page Program(32h) instruction support

[Simon Glass]

Hi Jagan,

On Wed, Dec 12, 2012 at 8:52 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:11 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash using
 Quad-input Page Program(32h) instruction.

 This will effectively increases the data transfer rate
 by up to four times, as compared to the Page Program(PP) instruction.

 Respective flash drivers need to use spi_flash_cmd_write_multi_qpp()
 based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com

 It's great to have this support. A few comments below.

 Thanks.


 ---
  README   |1 +
  common/cmd_sf.c  |   12 +++-
  drivers/mtd/spi/spi_flash.c  |  108 
 ++
  drivers/mtd/spi/spi_flash_internal.h |   13 
  include/spi_flash.h  |   12 
  5 files changed, 144 insertions(+), 2 deletions(-)

 diff --git a/README b/README
 index 5a86ae9..a01de13 100644
 --- a/README
 +++ b/README
 @@ -869,6 +869,7 @@ The following options need to be configured:
 CONFIG_CMD_SETGETDCR  Support for DCR Register access
   (4xx only)
 CONFIG_CMD_SF   * Read/write/erase SPI NOR flash
 +   CONFIG_CMD_SF_QPP   * Program SPI flash using 
 Quad-input Page Program
 CONFIG_CMD_SHA1SUMprint sha1 memory digest
   (requires CONFIG_CMD_MEMORY)
 CONFIG_CMD_SOURCE source command Support
 diff --git a/common/cmd_sf.c b/common/cmd_sf.c
 index 5ac1d0c..a449d2c 100644
 --- a/common/cmd_sf.c
 +++ b/common/cmd_sf.c
 @@ -228,6 +228,10 @@ static int do_spi_flash_read_write(int argc, char * 
 const argv[])
 ret = spi_flash_update(flash, offset, len, buf);
 else if (strcmp(argv[0], read) == 0)
 ret = spi_flash_read(flash, offset, len, buf);
 +#ifdef CONFIG_CMD_SF_QPP
 +   else if (strcmp(argv[0], write.qpp) == 0)
 +   ret = spi_flash_write_qpp(flash, offset, len, buf);
 +#endif
 else
 ret = spi_flash_write(flash, offset, len, buf);

 @@ -300,7 +304,7 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int 
 argc, char * const argv[
 }

 if (strcmp(cmd, read) == 0 || strcmp(cmd, write) == 0 ||
 -   strcmp(cmd, update) == 0)
 +   strcmp(cmd, update) == 0 || strcmp(cmd, write.qpp) == 0)
 ret = do_spi_flash_read_write(argc, argv);
 else if (strcmp(cmd, erase) == 0)
 ret = do_spi_flash_erase(argc, argv);
 @@ -327,5 +331,9 @@ U_BOOT_CMD(
 sf erase offset [+]len - erase `len' bytes from `offset'\n
  `+len' round up `len' to block 
 size\n
 sf update addr offset len  - erase and write `len' bytes from 
 memory\n
 -at `addr' to flash at `offset'
 +at `addr' to flash at `offset'\n
 +#ifdef CONFIG_CMD_SF_QPP
 +   sf write.qpp addr offset len   - write `len' bytes from memory\n
 +at `addr' to flash at `offset' 
 using Quad-input Page Program(32h)
 +#endif
  );
 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index a8f0af0..3545f59 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -122,6 +122,114 @@ int spi_flash_cmd_write_multi(struct spi_flash 
 *flash, u32 offset,
 return ret;
  }

 +#ifdef CONFIG_CMD_SF_QPP
 +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
 +{
 +   u8 cmd = CMD_READ_CONFIG;
 +   u8 data = 0;
 +   int ret;
 +
 +   ret = spi_flash_read_common(flash,
 +   cmd, sizeof(cmd), data, sizeof(data));
 +   if (ret  0) {
 +   debug(SF: fail to read config register\n);
 +   return ret;
 +   }
 +
 +   if (data  0x2) {

 Can we have defines/enums for this please?

 Yes I will do.


 +   debug(SF: quad enable bit is already set.\n);
 +   return ret;
 +   } else {
 +   debug(SF: need to set quad enable bit\n);
 +
 +   ret = spi_flash_cmd_write_config(flash, 0x0200);

 and here?

 Ok.


 +   if (ret  0) {
 +   debug(SF: fail to write quad enable bit\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_read_common(flash,
 +   cmd, sizeof(cmd), data, sizeof(data));
 +   if (ret  0) {
 +   debug(SF: fail to read config register\n);
 +   return ret;
 +   }

 It almost seems like you could have a loop here: read it, 

Re: [U-Boot] [PATCH V3 0/7] Add support for NVIDIA Tegra30 SoC

[Simon Glass]

Hi Tom,

On Tue, Dec 11, 2012 at 7:05 PM, Allen Martin amar...@nvidia.com wrote:
 On Tue, Dec 11, 2012 at 03:34:11PM -0800, Tom Warren wrote:
 This patch series adds basic (boot to cmd prompt) support for Tegra30.
 This is based on the Tegra20 SPL, which initializes the AVP (ARM7TDMI)
 boot proc) first, then control is transferred to the CPU (A9 quad cluster).
 It is based on current u-boot-tegra/next. Some Tegra20 files were
 changed or moved to enable use of common code/headers.

 Future patches will add support/drivers for MMC, USB, I2C, SPI, NAND
 and other peripherals. The Cardhu T30 boards is supported initially.


 Booted to command prompt on cardhu with the series, so:

 Tested-by: Allen Martin amar...@nvidia.com

I read through the series fairly briefly and it looks good to me -
less duplication and should be a good base for the near future. Aside
from the nits already mentioned by Tom/Allen, the series:

Acked-by: Simon Glass s...@chromium.org

Regards,
Simon


 --
 nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imls: Add support to list images in NAND device

[Scott Wood]

On 12/12/2012 03:20:24 AM, Vipin Kumar wrote:
imls does not list the images in NAND devices. This patch implements  
this

support for legacy type images.

Signed-off-by: Vipin Kumar vipin.ku...@st.com
---
Hello Scott,

There has been sometime since you reviewed the first version of this  
patch.

http://lists.denx.de/pipermail/u-boot/2012-November/139631.html

I am sorry for a late response on this. I was waiting for other  
comments if any

on the whole patch-set

Regards
Vipin

 README |   3 +-
 common/cmd_bootm.c | 133  
-

 2 files changed, 134 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 2077c3b..ec5c31e 100644
--- a/README
+++ b/README
@@ -831,7 +831,8 @@ The following options need to be configured:
CONFIG_CMD_I2C  * I2C serial bus support
CONFIG_CMD_IDE  * IDE harddisk support
CONFIG_CMD_IMIiminfo
-   CONFIG_CMD_IMLS   List all found images
+   CONFIG_CMD_IMLS   List all images found in flash
+		CONFIG_CMD_IMLS_NAND	  List all images found in NAND  
device


s/in flash/in NOR flash/
s/in NAND device/in NAND flash/

Or better, just have one CONFIG_CMD_IMLS and have it operate on  
whatever flash types are configured into U-Boot.



CONFIG_CMD_IMMAP* IMMR dump support
CONFIG_CMD_IMPORTENV* import an environment
 		CONFIG_CMD_INI		* import data from an ini file  
into the env

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d256ddf..8ee562a 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -83,6 +83,9 @@ extern flash_info_t flash_info[]; /* info for FLASH  
chips */
 static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char *  
const argv[]);

 #endif

+#include linux/err.h
+#include nand.h
+
 #ifdef CONFIG_SILENT_CONSOLE
 static void fixup_silent_linux(void);
 #endif
@@ -1175,7 +1178,7 @@ U_BOOT_CMD(
 /* imls - list all images found in flash */
 /***/
 #if defined(CONFIG_CMD_IMLS)
-static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char *  
const argv[])

+static void do_imls_flash(void)


s/flash/nor/


 {
flash_info_t *info;
int i, j;
@@ -1224,6 +1227,134 @@ next_sector:;
}
 next_bank: ;
}
+}
+#endif
+
+#if defined(CONFIG_CMD_IMLS_NAND)
+static void do_imls_nand(void)
+{
+   nand_info_t *nand;
+   int nand_dev = nand_curr_device;
+   size_t read_size;
+   loff_t off;
+   u8 buffer[512];


Why 512?


+   const image_header_t *header = (const image_header_t *)buffer;
+
+   /* the following commands operate on the current device */
+   if (nand_dev  0 || nand_dev = CONFIG_SYS_MAX_NAND_DEVICE) {
+   puts(\nNo NAND devices available\n);
+   return;
+   }


following commands, plural?

And this command seems to operate on all devices, not just the current  
one.



+
+   printf(\n);
+
+	for (nand_dev = 0; nand_dev  CONFIG_SYS_MAX_NAND_DEVICE;  
nand_dev++) {

+


Don't put a blank line inside braces at the beginning/end of blocks.


+   nand = nand_info[nand_dev];
+   if (!nand-name || !nand-size)
+   continue;
+
+		for (off = 0; off  nand-size; off += nand-erasesize)  
{

+   int ret;
+   void *imgdata;
+
+   if (nand_block_isbad(nand, off))
+   goto next_block;
+
+   read_size = sizeof(buffer);
+
+   ret = nand_read(nand, off, read_size, buffer);
+   if (ret  0  ret != -EUCLEAN)
+   goto next_block;


s/goto next_block/continue/


+   header = (const image_header_t *)buffer;
+
+   switch (genimg_get_format(buffer)) {
+   case IMAGE_FORMAT_LEGACY:
+   if (!image_check_hcrc(header))
+   goto next_block;
+
+read_size =  
image_get_image_size(header);

+
+   imgdata = malloc(read_size);
+   if (!imgdata) {
+	printf(Not able to list all  
images  \

+   (Low memory)\n);


Don't line-wrap error strings.


+   goto next_block;
+   }
+
+ret = nand_read_skip_bad(nand, off,  
read_size,

+   imgdata);
+   if (ret  0  ret != -EUCLEAN) {
+   free(imgdata);
+   goto next_block;
+   }


s/goto next_block/break/g

...or better, factor the switch out to its own function.


+
+

Re: [U-Boot] [PATCH V3 1/7] Tegra30: Add arch-tegra30 include files

[Tom Warren]

Stephen,

On Wed, Dec 12, 2012 at 3:02 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 12/12/2012 09:23 AM, Tom Warren wrote:
 Stephen,

 On Tue, Dec 11, 2012 at 5:36 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 12/11/2012 04:34 PM, Tom Warren wrote:
 Common Tegra files are in arch-tegra, shared between T20 and T30.
 Tegra30-specific headers are in arch-tegra30. Note that some of
 these will be filled in as more T30 support is added (drivers,
 WB/LP0 support, etc.). A couple of Tegra20 files were changed
 to support common headers in arch-tegra, also.

 diff --git a/arch/arm/include/asm/arch-tegra/tegra.h 
 b/arch/arm/include/asm/arch-tegra/tegra.h

 + TEGRA_SOC2_SLOW,/* T2x needs to run at slow clock initially 
 */

 I don't think that's used anywhere; drop it?

 This is a series to add T30 support. I've done some changes to
 combine/commonize shared files, etc., but I've tried to avoid any
 T20-only changes whenever possible.

 I'll add this as a note in my to-do cleanup patch list for T20.

 My point here was that this patch adds that unused enum. I think you can
 just drop the addition from the patch, and it'll never need to be
 cleaned up?

OK, good point. I had thought TEGRA_SOC2_SLOW was there originally in
the Tegra20 codebase, but you are right - it looks like I brought it
in, probably from our internal repo. I'll drop it. Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot