Re: [U-Boot] [PATCH 1/7] USB: Some cleanup prior to USB 3.0 interface addition

2013-04-01 Thread Vivek Gautam
Hi,


On Tue, Apr 2, 2013 at 12:16 PM, Marek Vasut  wrote:
> Dear Vivek Gautam,
>
>> On Tue, Apr 2, 2013 at 11:56 AM, Marek Vasut  wrote:
>> > Dear Vivek Gautam,
>> >
>> >> Hi Marek,
>> >>
>> >> On Thu, Mar 28, 2013 at 7:56 PM, Marek Vasut  wrote:
>> >> > Dear Vivek Gautam,
>> >> >
>> >> >> Some cleanup in usb framework, nothing much on feature side.
>> >> >>
>> >> >> Signed-off-by: Vikas C Sajjan 
>> >> >> Signed-off-by: Vivek Gautam 
>> >> >> ---
>> >> >>
>> >> >>  common/usb.c |   18 ++
>> >> >>  common/usb_storage.c |   30 --
>> >> >>  include/usb_defs.h   |2 +-
>> >> >>  3 files changed, 27 insertions(+), 23 deletions(-)
>> >> >>
>> >> >> diff --git a/common/usb.c b/common/usb.c
>> >> >> index 6fc0fc1..40c1547 100644
>> >> >> --- a/common/usb.c
>> >> >> +++ b/common/usb.c
>> >> >> @@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device
>> >> >> *dev,
>> >> >>
>> >> >>   int index, ifno, epno, curr_if_num;
>> >> >>   int i;
>> >> >>   u16 ep_wMaxPacketSize;
>> >> >>
>> >> >> + struct usb_interface *if_desc = NULL;
>> >> >>
>> >> >>   ifno = -1;
>> >> >>   epno = -1;
>> >> >>
>> >> >> @@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device
>> >> >> *dev,
>> >> >>
>> >> >>&buffer[index])->bInterfaceNumber !=
>> >> >>curr_if_num) {
>> >> >>
>> >> >>   /* this is a new interface, copy new
>> >> >>   desc */ ifno = dev->config.no_of_if;
>> >> >>
>> >> >> + if_desc = &dev->config.if_desc[ifno];
>> >> >>
>> >> >>   dev->config.no_of_if++;
>> >> >>
>> >> >> - memcpy(&dev->config.if_desc[ifno],
>> >> >> - &buffer[index], buffer[index]);
>> >> >> - dev->config.if_desc[ifno].no_of_ep = 0;
>> >> >> -
>> >> >> dev->config.if_desc[ifno].num_altsetting = 1; +
>> >> >>memcpy(if_desc, &buffer[index], buffer[index]); +
>> >> >> if_desc->no_of_ep = 0; +
>> >> >> if_desc->num_altsetting = 1;
>> >> >>
>> >> >>   curr_if_num =
>> >> >>
>> >> >> -  dev-
>> >> >>
>> >> >>config.if_desc[ifno].desc.bInterfaceNumber;
>> >> >>
>> >> >> +  if_desc->desc.bInterfaceNumber;
>> >> >>
>> >> >>   } else {
>> >> >>
>> >> >>   /* found alternate setting for the
>> >> >>   interface */
>> >> >>
>> >> >> -
>> >> >> dev->config.if_desc[ifno].num_altsetting++; +
>> >> >>
>> >> >>   if_desc->num_altsetting++;
>> >> >
>> >> > This will crash as if_desc is set in the if() branch above and it will
>> >> > be NULL in the else{} branch.
>> >>
>> >> True, will add here
>> >> if_desc = &dev->config.if_desc[ifno];
>> >
>> > Yea ;-)
>> >
>> >> One more thing actually i could notice, "ifno = -1" in this else
>> >> section. Is this what we want it here ?
>> >
>> > Maybe I don't see it ?
>>
>> ifno is initailized to -1.
>> Now when descriptor is 'Interface type' (case USB_DT_INTERFACE) ifno
>> is update in if part only as below:
>> ifno = dev->config.no_of_if;
>>
>> This would not be reaching else part, right ?
>
> Ah I see, yep, indexing the array with -1 is no good. You can add a 
> safety-check
> there , but the -1 should never reach that place indeed.
>

Ok, will amend this as required and update.


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


Re: [U-Boot] [PATCH 1/7] USB: Some cleanup prior to USB 3.0 interface addition

2013-04-01 Thread Marek Vasut
Dear Vivek Gautam,

> On Tue, Apr 2, 2013 at 11:56 AM, Marek Vasut  wrote:
> > Dear Vivek Gautam,
> > 
> >> Hi Marek,
> >> 
> >> On Thu, Mar 28, 2013 at 7:56 PM, Marek Vasut  wrote:
> >> > Dear Vivek Gautam,
> >> > 
> >> >> Some cleanup in usb framework, nothing much on feature side.
> >> >> 
> >> >> Signed-off-by: Vikas C Sajjan 
> >> >> Signed-off-by: Vivek Gautam 
> >> >> ---
> >> >> 
> >> >>  common/usb.c |   18 ++
> >> >>  common/usb_storage.c |   30 --
> >> >>  include/usb_defs.h   |2 +-
> >> >>  3 files changed, 27 insertions(+), 23 deletions(-)
> >> >> 
> >> >> diff --git a/common/usb.c b/common/usb.c
> >> >> index 6fc0fc1..40c1547 100644
> >> >> --- a/common/usb.c
> >> >> +++ b/common/usb.c
> >> >> @@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device
> >> >> *dev,
> >> >> 
> >> >>   int index, ifno, epno, curr_if_num;
> >> >>   int i;
> >> >>   u16 ep_wMaxPacketSize;
> >> >> 
> >> >> + struct usb_interface *if_desc = NULL;
> >> >> 
> >> >>   ifno = -1;
> >> >>   epno = -1;
> >> >> 
> >> >> @@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device
> >> >> *dev,
> >> >> 
> >> >>&buffer[index])->bInterfaceNumber !=
> >> >>curr_if_num) {
> >> >>
> >> >>   /* this is a new interface, copy new
> >> >>   desc */ ifno = dev->config.no_of_if;
> >> >> 
> >> >> + if_desc = &dev->config.if_desc[ifno];
> >> >> 
> >> >>   dev->config.no_of_if++;
> >> >> 
> >> >> - memcpy(&dev->config.if_desc[ifno],
> >> >> - &buffer[index], buffer[index]);
> >> >> - dev->config.if_desc[ifno].no_of_ep = 0;
> >> >> -
> >> >> dev->config.if_desc[ifno].num_altsetting = 1; + 
> >> >>memcpy(if_desc, &buffer[index], buffer[index]); +
> >> >> if_desc->no_of_ep = 0; +
> >> >> if_desc->num_altsetting = 1;
> >> >> 
> >> >>   curr_if_num =
> >> >> 
> >> >> -  dev-
> >> >>
> >> >>config.if_desc[ifno].desc.bInterfaceNumber;
> >> >>
> >> >> +  if_desc->desc.bInterfaceNumber;
> >> >> 
> >> >>   } else {
> >> >>   
> >> >>   /* found alternate setting for the
> >> >>   interface */
> >> >> 
> >> >> -
> >> >> dev->config.if_desc[ifno].num_altsetting++; +
> >> >> 
> >> >>   if_desc->num_altsetting++;
> >> > 
> >> > This will crash as if_desc is set in the if() branch above and it will
> >> > be NULL in the else{} branch.
> >> 
> >> True, will add here
> >> if_desc = &dev->config.if_desc[ifno];
> > 
> > Yea ;-)
> > 
> >> One more thing actually i could notice, "ifno = -1" in this else
> >> section. Is this what we want it here ?
> > 
> > Maybe I don't see it ?
> 
> ifno is initailized to -1.
> Now when descriptor is 'Interface type' (case USB_DT_INTERFACE) ifno
> is update in if part only as below:
> ifno = dev->config.no_of_if;
> 
> This would not be reaching else part, right ?

Ah I see, yep, indexing the array with -1 is no good. You can add a 
safety-check 
there , but the -1 should never reach that place indeed.

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/7] usb: hub: Fix enumration timeout

2013-04-01 Thread Marek Vasut
Dear Vivek Gautam,

> On Tue, Apr 2, 2013 at 11:04 AM, Vivek Gautam  
wrote:
> > Hi Marek,
> > 
> > On Tue, Apr 2, 2013 at 10:42 AM, Marek Vasut  wrote:
> >> Dear Vivek Gautam,
> >> 
> >>> Hi,
> >>> 
> >>> On Tue, Apr 2, 2013 at 1:43 AM, Tom Rini  wrote:
> >>> > On Wed, Mar 27, 2013 at 02:59:00PM +0530, Vivek Gautam wrote:
> >>> >> Patch b6d7852c increases timeout for enumeration, taking
> >>> >> worst case to be 10 sec.
> >>> >> get_timer() api returns timestamp in micro-seconds, which is
> >>> >> what we are checking in the do-while() loop in usb_hub_configure()
> >>> >> (get_timer(start) < CONFIG_SYS_HZ * 10).
> >>> >> This should give us a required check for 10 seconds, and thereby
> >>> >> we don't need to add additional mdelay of 100 microseconds in
> >>> >> each cycle.
> >>> > 
> >>> > The wording here is not correct.  get_timer operates in milliseconds
> >>> > not microseconds.
> >>> 
> >>> Oops!! Yes of course, my mistake. Thanks
> >> 
> >> I have the patches queued in usb/next, you can send me a fix and I'll
> >> squash it with what's already in there.
> > 
> > Sure,  i shall send a fix for this.
> > Should it be good actually to respin the complete patch-series with
> > the changes you have suggested ??
> 
> I was out on weekend, so couldn't update the patch-series.

No problem, I'll drop it from next then, please send the whole series.

Thanks!

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


[U-Boot] [PATCH 4/4 V4] CONFIG: EXYNOS5: Enable silent console

2013-04-01 Thread Rajeshwari Shinde
This patch enables CONFIG_SILENT_CONSOLE for EXYNOS5.

Signed-off-by: Rajeshwari Shinde 
Acked-by: Simon Glass 
---
Changes in V2:
- None
Changes in V3:
- None
Changes in V4:
- None
 include/configs/exynos5250-dt.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 496a194..b648d6b 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -90,6 +90,8 @@
"stdout=serial,lcd\0" \
"stderr=serial,lcd\0"
 
+#define CONFIG_SILENT_CONSOLE
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
EXYNOS_DEVICE_SETTINGS
 
-- 
1.7.4.4

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


[U-Boot] [PATCH 3/4 V4] S5P: Serial: Add fdt support to driver

2013-04-01 Thread Rajeshwari Shinde
This patch adds FDT support to the serial s5p driver.
At present disabling the serial console (from the device tree) crashes
U-Boot. Add checks for this case, so that execution can continue without
a serial console.
It also enables the serial_s5p driver recognize the silent_console option.

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Gabe Black 
Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- None
Changes in V3:
- Moved driver config structure to data section. 
- Changed silent_console to silent-console.
- Did put a check for base address before doing fdt decoding.
Changes in V4
- None
 drivers/serial/serial_s5p.c |   78 +++
 1 files changed, 78 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index 3c41242..55ef2bf 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -24,16 +24,28 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/* Information about a serial port */
+struct fdt_serial {
+   u32 base_addr;  /* address of registers in physical memory */
+   u8 port_id; /* uart port number */
+   u8 enabled; /* 1 if enabled, 0 if disabled */
+} config __attribute__ ((section(".data")));
+
 static inline struct s5p_uart *s5p_get_base_uart(int dev_index)
 {
+#ifdef CONFIG_OF_CONTROL
+   return (struct s5p_uart *)(config.base_addr);
+#else
u32 offset = dev_index * sizeof(struct s5p_uart);
return (struct s5p_uart *)(samsung_get_base_uart() + offset);
+#endif
 }
 
 /*
@@ -69,6 +81,9 @@ void serial_setbrg_dev(const int dev_index)
u32 baudrate = gd->baudrate;
u32 val;
 
+   if (!config.enabled)
+   return;
+
val = uclk / baudrate;
 
writel(val / 16 - 1, &uart->ubrdiv);
@@ -87,6 +102,16 @@ int serial_init_dev(const int dev_index)
 {
struct s5p_uart *const uart = s5p_get_base_uart(dev_index);
 
+#if defined(CONFIG_SILENT_CONSOLE) && \
+   defined(CONFIG_OF_CONTROL) && \
+   !defined(CONFIG_SPL_BUILD)
+   if (fdtdec_get_config_int(gd->fdt_blob, "silent_console", 0))
+   gd->flags |= GD_FLG_SILENT;
+#endif
+
+   if (!config.enabled)
+   return 0;
+
/* reset and enable FIFOs, set triggers to the maximum */
writel(0, &uart->ufcon);
writel(0, &uart->umcon);
@@ -129,6 +154,9 @@ int serial_getc_dev(const int dev_index)
 {
struct s5p_uart *const uart = s5p_get_base_uart(dev_index);
 
+   if (!config.enabled)
+   return 0;
+
/* wait for character to arrive */
while (!(readl(&uart->utrstat) & 0x1)) {
if (serial_err_check(dev_index, 0))
@@ -145,6 +173,9 @@ void serial_putc_dev(const char c, const int dev_index)
 {
struct s5p_uart *const uart = s5p_get_base_uart(dev_index);
 
+   if (!config.enabled)
+   return;
+
/* wait for room in the tx FIFO */
while (!(readl(&uart->utrstat) & 0x2)) {
if (serial_err_check(dev_index, 1))
@@ -165,6 +196,9 @@ int serial_tstc_dev(const int dev_index)
 {
struct s5p_uart *const uart = s5p_get_base_uart(dev_index);
 
+   if (!config.enabled)
+   return 0;
+
return (int)(readl(&uart->utrstat) & 0x1);
 }
 
@@ -207,8 +241,51 @@ DECLARE_S5P_SERIAL_FUNCTIONS(3);
 struct serial_device s5p_serial3_device =
INIT_S5P_SERIAL_STRUCTURE(3, "s5pser3");
 
+#ifdef CONFIG_OF_CONTROL
+int fdtdec_decode_console(int *index, struct fdt_serial *uart)
+{
+   const void *blob = gd->fdt_blob;
+   int node;
+
+   node = fdt_path_offset(blob, "console");
+   if (node < 0)
+   return node;
+
+   uart->base_addr = fdtdec_get_addr(blob, node, "reg");
+   if (uart->base_addr == FDT_ADDR_T_NONE)
+   return -FDT_ERR_NOTFOUND;
+
+   uart->port_id = fdtdec_get_int(blob, node, "id", -1);
+   uart->enabled = fdtdec_get_is_enabled(blob, node);
+
+   return 0;
+}
+#endif
+
 __weak struct serial_device *default_serial_console(void)
 {
+#ifdef CONFIG_OF_CONTROL
+   int index = 0;
+
+   if ((!config.base_addr) && (fdtdec_decode_console(&index, &config))) {
+   debug("Cannot decode default console node\n");
+   return NULL;
+   }
+
+   if (config.port_id == 0)
+   return &s5p_serial0_device;
+   else if (config.port_id == 1)
+   return &s5p_serial1_device;
+   else if (config.port_id == 2)
+   return &s5p_serial2_device;
+   else if (config.port_id == 3)
+   return &s5p_serial3_device;
+   else
+   debug("Unknown config.port_id: %d", config.port_id);
+
+   return NULL;
+#else
+   config.enabled = 1;
 #if defined(CONFIG_SERIAL0)
return &s5p_serial0_device;
 #elif defined(CONFI

[U-Boot] [PATCH 2/4 V4] EXYNOS5: FDT: Add serial device node values

2013-04-01 Thread Rajeshwari Shinde
This patch adds the device node required for serial driver

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- Changed the compatible string to "samsung,exynos4210-uart"
Changes in V3:
- Added a alias console as we will support one at any point of time.
Changes in V4:
- Rebased on latest u-boot-samsung tree.
 arch/arm/dts/exynos5250.dtsi  |   28 
 board/samsung/dts/exynos5250-smdk5250.dts |2 ++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index df4b231..125cb35 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -169,4 +169,32 @@
#address-cells = <1>;
#size-cells = <1>;
};
+
+   serial@12C0 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x12C0 0x100>;
+   interrupts = <0 51 0>;
+   id = <0>;
+   };
+
+   serial@12C1 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x12C1 0x100>;
+   interrupts = <0 52 0>;
+   id = <1>;
+   };
+
+   serial@12C2 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x12C2 0x100>;
+   interrupts = <0 53 0>;
+   id = <2>;
+   };
+
+   serial@12C3 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x12C3 0x100>;
+   interrupts = <0 54 0>;
+   id = <3>;
+   };
 };
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts 
b/board/samsung/dts/exynos5250-smdk5250.dts
index 8da973b..b9181ef 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -30,6 +30,8 @@
spi2 = "/spi@12d4";
spi3 = "/spi@131a";
spi4 = "/spi@131b";
+   serial0 = "/serial@12C3";
+   console = "/serial@12C3";
};
 
sromc@1225 {
-- 
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/4 V4] EXYNOS5: FDT: Add compatible strings for Serial

2013-04-01 Thread Rajeshwari Shinde
Add required compatible information for s5p serial driver

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Rajeshwari Shinde 
Acked-by: Simon Glass 
---
Changes in V2:
- Changed the compatible string to "samsung,exynos4210-uart"
Changes in V3:
- Rebased on latest u-boot-samsung
Changes in V4:
- Rebased on latest u-boot-samsung
- Changed to COMPAT_SAMSUNG_EXYNOS5_SERIAL to 
COMPAT_SAMSUNG_EXYNOS_SERIAL 
 include/fdtdec.h |1 +
 lib/fdtdec.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index a83b160..0721c00 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -89,6 +89,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS5_DP,  /* Exynos Display port controller */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
COMPAT_MAXIM_98095_CODEC,   /* MAX98095 Codec */
+   COMPAT_SAMSUNG_EXYNOS_SERIAL,   /* Exynos UART */
 
COMPAT_COUNT,
 };
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 0f34bdc..825a41d 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -64,6 +64,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS5_DP, "samsung,exynos5-dp"),
COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
COMPAT(MAXIM_98095_CODEC, "maxim,max98095-codec"),
+   COMPAT(SAMSUNG_EXYNOS_SERIAL, "samsung,exynos4210-uart"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
-- 
1.7.4.4

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


[U-Boot] [PATCH 0/4 V4] SMDK5250: FDT: Add device tree support for console

2013-04-01 Thread Rajeshwari Shinde
Enabled fdt support for default console on SMDK5250.

Changes in V2:
- Changed the compatible string to "samsung,exynos4210-uart"
Changes in V3:
- Rebased the patchset on latest u-boot-samsung branch.
- Added a alias console as we will support one at any point of time.
- Moved driver config structure to data section.
- Changed silent_console to silent-console.
- Did put a check for base address before doing fdt decoding.
Changes in V4:
- Rebased the patchset on latest u-boot-samsung branch.
- Changed to COMPAT_SAMSUNG_EXYNOS5_SERIAL to 
COMPAT_SAMSUNG_EXYNOS_SERIAL 

Rajeshwari Shinde (4):
  EXYNOS5: FDT: Add compatible strings for Serial
  EXYNOS5: FDT: Add serial device node values
  S5P: Serial: Add fdt support to driver
  CONFIG: EXYNOS5: Enable silent console

 arch/arm/dts/exynos5250.dtsi  |   28 ++
 board/samsung/dts/exynos5250-smdk5250.dts |2 +
 drivers/serial/serial_s5p.c   |   78 +
 include/configs/exynos5250-dt.h   |2 +
 include/fdtdec.h  |1 +
 lib/fdtdec.c  |1 +
 6 files changed, 112 insertions(+), 0 deletions(-)

-- 
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 1/7] USB: Some cleanup prior to USB 3.0 interface addition

2013-04-01 Thread Vivek Gautam
On Tue, Apr 2, 2013 at 11:56 AM, Marek Vasut  wrote:
> Dear Vivek Gautam,
>
>> Hi Marek,
>>
>> On Thu, Mar 28, 2013 at 7:56 PM, Marek Vasut  wrote:
>> > Dear Vivek Gautam,
>> >
>> >> Some cleanup in usb framework, nothing much on feature side.
>> >>
>> >> Signed-off-by: Vikas C Sajjan 
>> >> Signed-off-by: Vivek Gautam 
>> >> ---
>> >>
>> >>  common/usb.c |   18 ++
>> >>  common/usb_storage.c |   30 --
>> >>  include/usb_defs.h   |2 +-
>> >>  3 files changed, 27 insertions(+), 23 deletions(-)
>> >>
>> >> diff --git a/common/usb.c b/common/usb.c
>> >> index 6fc0fc1..40c1547 100644
>> >> --- a/common/usb.c
>> >> +++ b/common/usb.c
>> >> @@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device *dev,
>> >>
>> >>   int index, ifno, epno, curr_if_num;
>> >>   int i;
>> >>   u16 ep_wMaxPacketSize;
>> >>
>> >> + struct usb_interface *if_desc = NULL;
>> >>
>> >>   ifno = -1;
>> >>   epno = -1;
>> >>
>> >> @@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device
>> >> *dev,
>> >>
>> >>&buffer[index])->bInterfaceNumber !=
>> >>curr_if_num) {
>> >>
>> >>   /* this is a new interface, copy new desc
>> >>   */ ifno = dev->config.no_of_if;
>> >>
>> >> + if_desc = &dev->config.if_desc[ifno];
>> >>
>> >>   dev->config.no_of_if++;
>> >>
>> >> - memcpy(&dev->config.if_desc[ifno],
>> >> - &buffer[index], buffer[index]);
>> >> - dev->config.if_desc[ifno].no_of_ep = 0;
>> >> - dev->config.if_desc[ifno].num_altsetting =
>> >> 1; + memcpy(if_desc, &buffer[index],
>> >> buffer[index]); + if_desc->no_of_ep = 0;
>> >> + if_desc->num_altsetting = 1;
>> >>
>> >>   curr_if_num =
>> >>
>> >> -  dev-
>> >>
>> >>config.if_desc[ifno].desc.bInterfaceNumber;
>> >>
>> >> +  if_desc->desc.bInterfaceNumber;
>> >>
>> >>   } else {
>> >>
>> >>   /* found alternate setting for the
>> >>   interface */
>> >>
>> >> -
>> >> dev->config.if_desc[ifno].num_altsetting++; +
>> >>   if_desc->num_altsetting++;
>> >
>> > This will crash as if_desc is set in the if() branch above and it will be
>> > NULL in the else{} branch.
>>
>> True, will add here
>> if_desc = &dev->config.if_desc[ifno];
>
> Yea ;-)
>
>> One more thing actually i could notice, "ifno = -1" in this else section.
>> Is this what we want it here ?
>
> Maybe I don't see it ?

ifno is initailized to -1.
Now when descriptor is 'Interface type' (case USB_DT_INTERFACE) ifno
is update in if part only as below:
ifno = dev->config.no_of_if;

This would not be reaching else part, right ?

>
>> >>   }
>> >>   break;
>> >>
>> >>   case USB_DT_ENDPOINT:
>> >>   epno = dev->config.if_desc[ifno].no_of_ep;
>> >>
>> >> + if_desc = &dev->config.if_desc[ifno];
>> >>
>> >>   /* found an endpoint */
>> >>
>> >> - dev->config.if_desc[ifno].no_of_ep++;
>> >> - memcpy(&dev->config.if_desc[ifno].ep_desc[epno],
>> >> + if_desc->no_of_ep++;
>> >> + memcpy(&if_desc->ep_desc[epno],
>> >>
>> >>   &buffer[index], buffer[index]);
>> >>
>> >>   ep_wMaxPacketSize = get_unaligned(&dev->config.\
>> >>
>> >>   if_desc[ifno].\
>> >>
>> >> diff --git a/common/usb_storage.c b/common/usb_storage.c
>> >> index fb322b4..475c218 100644
>> >> --- a/common/usb_storage.c
>> >> +++ b/common/usb_storage.c
>> >> @@ -278,10 +278,10 @@ int usb_stor_scan(int mode)
>> >>
>> >>lun++) {
>> >>
>> >>   usb_dev_desc[usb_max_devs].lun = lun;
>> >>   if (usb_stor_get_info(dev,
>> >>   &usb_stor[start],
>> >>
>> >> -
>> >
>> > &usb_dev_desc[usb_max_devs]) == 1) {
>>
>> Do we really need this brace here? We just have one statement under this
>> if.
>
> If the condition is multi-line, then we use brace, yes.

Alright, will amend this. :-)

>
>> >> - usb_max_devs++;
>> >> - }
>> >> + &usb_dev_desc[usb_max_devs]) == 1)
>> >> + usb_max_devs++;
>> >>
>> >>   }
>> >>
>> >> +
>> >
>> > What is this change here doing?
>>
>> There were these unaligned braces for if part, which we removed.
>>
>> >>   }

[U-Boot] Warning messages in latest u-boot-samsung

2013-04-01 Thread Rajeshwari Birje
Hi Minkyu Kang,

I am getting the following warning messages in the latest  u-boot-samsung tree.

/usr/local/arm/arm-2011.09/bin/arm-none-eabi-ld: warning:
/usr/local/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/libgcc.a(bpabi.o)
uses variable-size enums yet the output is to use 32-bit enums; use of
enum values across objects may fail
/usr/local/arm/arm-2011.09/bin/arm-none-eabi-ld: warning:
/usr/local/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/libgcc.a(_divdi3.o)
uses variable-size enums yet the output is to use 32-bit enums; use of
enum values across objects may fail
/usr/local/arm/arm-2011.09/bin/arm-none-eabi-ld: warning:
/usr/local/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/libgcc.a(_udivdi3.o)
uses variable-size enums yet the output is to use 32-bit enums; use of
enum values across objects may fail

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


Re: [U-Boot] [PATCH 1/7] USB: Some cleanup prior to USB 3.0 interface addition

2013-04-01 Thread Marek Vasut
Dear Vivek Gautam,

> Hi Marek,
> 
> On Thu, Mar 28, 2013 at 7:56 PM, Marek Vasut  wrote:
> > Dear Vivek Gautam,
> > 
> >> Some cleanup in usb framework, nothing much on feature side.
> >> 
> >> Signed-off-by: Vikas C Sajjan 
> >> Signed-off-by: Vivek Gautam 
> >> ---
> >> 
> >>  common/usb.c |   18 ++
> >>  common/usb_storage.c |   30 --
> >>  include/usb_defs.h   |2 +-
> >>  3 files changed, 27 insertions(+), 23 deletions(-)
> >> 
> >> diff --git a/common/usb.c b/common/usb.c
> >> index 6fc0fc1..40c1547 100644
> >> --- a/common/usb.c
> >> +++ b/common/usb.c
> >> @@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device *dev,
> >> 
> >>   int index, ifno, epno, curr_if_num;
> >>   int i;
> >>   u16 ep_wMaxPacketSize;
> >> 
> >> + struct usb_interface *if_desc = NULL;
> >> 
> >>   ifno = -1;
> >>   epno = -1;
> >> 
> >> @@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device
> >> *dev,
> >> 
> >>&buffer[index])->bInterfaceNumber !=
> >>curr_if_num) {
> >>
> >>   /* this is a new interface, copy new desc
> >>   */ ifno = dev->config.no_of_if;
> >> 
> >> + if_desc = &dev->config.if_desc[ifno];
> >> 
> >>   dev->config.no_of_if++;
> >> 
> >> - memcpy(&dev->config.if_desc[ifno],
> >> - &buffer[index], buffer[index]);
> >> - dev->config.if_desc[ifno].no_of_ep = 0;
> >> - dev->config.if_desc[ifno].num_altsetting =
> >> 1; + memcpy(if_desc, &buffer[index],
> >> buffer[index]); + if_desc->no_of_ep = 0;
> >> + if_desc->num_altsetting = 1;
> >> 
> >>   curr_if_num =
> >> 
> >> -  dev-
> >>
> >>config.if_desc[ifno].desc.bInterfaceNumber;
> >>
> >> +  if_desc->desc.bInterfaceNumber;
> >> 
> >>   } else {
> >>   
> >>   /* found alternate setting for the
> >>   interface */
> >> 
> >> -
> >> dev->config.if_desc[ifno].num_altsetting++; +  
> >>   if_desc->num_altsetting++;
> > 
> > This will crash as if_desc is set in the if() branch above and it will be
> > NULL in the else{} branch.
> 
> True, will add here
> if_desc = &dev->config.if_desc[ifno];

Yea ;-)

> One more thing actually i could notice, "ifno = -1" in this else section.
> Is this what we want it here ?

Maybe I don't see it ?

> >>   }
> >>   break;
> >>   
> >>   case USB_DT_ENDPOINT:
> >>   epno = dev->config.if_desc[ifno].no_of_ep;
> >> 
> >> + if_desc = &dev->config.if_desc[ifno];
> >> 
> >>   /* found an endpoint */
> >> 
> >> - dev->config.if_desc[ifno].no_of_ep++;
> >> - memcpy(&dev->config.if_desc[ifno].ep_desc[epno],
> >> + if_desc->no_of_ep++;
> >> + memcpy(&if_desc->ep_desc[epno],
> >> 
> >>   &buffer[index], buffer[index]);
> >>   
> >>   ep_wMaxPacketSize = get_unaligned(&dev->config.\
> >>   
> >>   if_desc[ifno].\
> >> 
> >> diff --git a/common/usb_storage.c b/common/usb_storage.c
> >> index fb322b4..475c218 100644
> >> --- a/common/usb_storage.c
> >> +++ b/common/usb_storage.c
> >> @@ -278,10 +278,10 @@ int usb_stor_scan(int mode)
> >> 
> >>lun++) {
> >>
> >>   usb_dev_desc[usb_max_devs].lun = lun;
> >>   if (usb_stor_get_info(dev,
> >>   &usb_stor[start],
> >> 
> >> -
> > 
> > &usb_dev_desc[usb_max_devs]) == 1) {
> 
> Do we really need this brace here? We just have one statement under this
> if.

If the condition is multi-line, then we use brace, yes.

> >> - usb_max_devs++;
> >> - }
> >> + &usb_dev_desc[usb_max_devs]) == 1)
> >> + usb_max_devs++;
> >> 
> >>   }
> >> 
> >> +
> > 
> > What is this change here doing?
> 
> There were these unaligned braces for if part, which we removed.
> 
> >>   }
> >>   /* if storage device */
> >>   if (usb_max_devs == USB_MAX_STOR_DEV) {
> > 
> > [..]
> > 
> > Best regards,
> > Marek Vasut
> > ___
> > 

Re: [U-Boot] [PATCH 1/7] USB: Some cleanup prior to USB 3.0 interface addition

2013-04-01 Thread Vivek Gautam
On Tue, Apr 2, 2013 at 11:24 AM, Vivek Gautam  wrote:
> Hi Marek,
>
>
> On Thu, Mar 28, 2013 at 7:56 PM, Marek Vasut  wrote:
>> Dear Vivek Gautam,
>>
>>> Some cleanup in usb framework, nothing much on feature side.
>>>
>>> Signed-off-by: Vikas C Sajjan 
>>> Signed-off-by: Vivek Gautam 
>>> ---
>>>  common/usb.c |   18 ++
>>>  common/usb_storage.c |   30 --
>>>  include/usb_defs.h   |2 +-
>>>  3 files changed, 27 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/common/usb.c b/common/usb.c
>>> index 6fc0fc1..40c1547 100644
>>> --- a/common/usb.c
>>> +++ b/common/usb.c
>>> @@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device *dev,
>>>   int index, ifno, epno, curr_if_num;
>>>   int i;
>>>   u16 ep_wMaxPacketSize;
>>> + struct usb_interface *if_desc = NULL;
>>>
>>>   ifno = -1;
>>>   epno = -1;
>>> @@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device *dev,
>>>&buffer[index])->bInterfaceNumber != 
>>> curr_if_num) {
>>>   /* this is a new interface, copy new desc */
>>>   ifno = dev->config.no_of_if;
>>> + if_desc = &dev->config.if_desc[ifno];
>>>   dev->config.no_of_if++;
>>> - memcpy(&dev->config.if_desc[ifno],
>>> - &buffer[index], buffer[index]);
>>> - dev->config.if_desc[ifno].no_of_ep = 0;
>>> - dev->config.if_desc[ifno].num_altsetting = 1;
>>> + memcpy(if_desc, &buffer[index], 
>>> buffer[index]);
>>> + if_desc->no_of_ep = 0;
>>> + if_desc->num_altsetting = 1;
>>>   curr_if_num =
>>> -  dev-
>>>config.if_desc[ifno].desc.bInterfaceNumber;
>>> +  if_desc->desc.bInterfaceNumber;
>>>   } else {
>>>   /* found alternate setting for the interface 
>>> */
>>> - dev->config.if_desc[ifno].num_altsetting++;
>>> + if_desc->num_altsetting++;
>>
>> This will crash as if_desc is set in the if() branch above and it will be 
>> NULL
>> in the else{} branch.
>
> True, will add here
> if_desc = &dev->config.if_desc[ifno];
>
> One more thing actually i could notice, "ifno = -1" in this else section.
> Is this what we want it here ?
>
>>
>>>   }
>>>   break;
>>>   case USB_DT_ENDPOINT:
>>>   epno = dev->config.if_desc[ifno].no_of_ep;
>>> + if_desc = &dev->config.if_desc[ifno];
>>>   /* found an endpoint */
>>> - dev->config.if_desc[ifno].no_of_ep++;
>>> - memcpy(&dev->config.if_desc[ifno].ep_desc[epno],
>>> + if_desc->no_of_ep++;
>>> + memcpy(&if_desc->ep_desc[epno],
>>>   &buffer[index], buffer[index]);
>>>   ep_wMaxPacketSize = get_unaligned(&dev->config.\
>>>   if_desc[ifno].\
>>> diff --git a/common/usb_storage.c b/common/usb_storage.c
>>> index fb322b4..475c218 100644
>>> --- a/common/usb_storage.c
>>> +++ b/common/usb_storage.c
>>> @@ -278,10 +278,10 @@ int usb_stor_scan(int mode)
>>>lun++) {
>>>   usb_dev_desc[usb_max_devs].lun = lun;
>>>   if (usb_stor_get_info(dev, &usb_stor[start],
>>> -
>> &usb_dev_desc[usb_max_devs]) == 1) {
>
> Do we really need this brace here? We just have one statement under this if.
>
>>> - usb_max_devs++;
>>> - }
>>> + &usb_dev_desc[usb_max_devs]) == 1)
>>> + usb_max_devs++;
>>>   }
>>> +
>>
>>
>> What is this change here doing?
>
> There were these unaligned braces for if part, which we removed.

Please ignore above comment. It was meant for change prior to this, above.
Will remove this extra line here.

>
>>
>>>   }
>>>   /* if storage device */
>>>   if (usb_max_devs == USB_MAX_STOR_DEV) {
>>
>> [..]
>>
>> Best regards,
>> Marek Vasut
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
> --
> Thanks & Regards
> Vivek



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


Re: [U-Boot] [PATCH 1/7] USB: Some cleanup prior to USB 3.0 interface addition

2013-04-01 Thread Vivek Gautam
Hi Marek,


On Thu, Mar 28, 2013 at 7:56 PM, Marek Vasut  wrote:
> Dear Vivek Gautam,
>
>> Some cleanup in usb framework, nothing much on feature side.
>>
>> Signed-off-by: Vikas C Sajjan 
>> Signed-off-by: Vivek Gautam 
>> ---
>>  common/usb.c |   18 ++
>>  common/usb_storage.c |   30 --
>>  include/usb_defs.h   |2 +-
>>  3 files changed, 27 insertions(+), 23 deletions(-)
>>
>> diff --git a/common/usb.c b/common/usb.c
>> index 6fc0fc1..40c1547 100644
>> --- a/common/usb.c
>> +++ b/common/usb.c
>> @@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device *dev,
>>   int index, ifno, epno, curr_if_num;
>>   int i;
>>   u16 ep_wMaxPacketSize;
>> + struct usb_interface *if_desc = NULL;
>>
>>   ifno = -1;
>>   epno = -1;
>> @@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device *dev,
>>&buffer[index])->bInterfaceNumber != curr_if_num) 
>> {
>>   /* this is a new interface, copy new desc */
>>   ifno = dev->config.no_of_if;
>> + if_desc = &dev->config.if_desc[ifno];
>>   dev->config.no_of_if++;
>> - memcpy(&dev->config.if_desc[ifno],
>> - &buffer[index], buffer[index]);
>> - dev->config.if_desc[ifno].no_of_ep = 0;
>> - dev->config.if_desc[ifno].num_altsetting = 1;
>> + memcpy(if_desc, &buffer[index], buffer[index]);
>> + if_desc->no_of_ep = 0;
>> + if_desc->num_altsetting = 1;
>>   curr_if_num =
>> -  dev-
>>config.if_desc[ifno].desc.bInterfaceNumber;
>> +  if_desc->desc.bInterfaceNumber;
>>   } else {
>>   /* found alternate setting for the interface */
>> - dev->config.if_desc[ifno].num_altsetting++;
>> + if_desc->num_altsetting++;
>
> This will crash as if_desc is set in the if() branch above and it will be NULL
> in the else{} branch.

True, will add here
if_desc = &dev->config.if_desc[ifno];

One more thing actually i could notice, "ifno = -1" in this else section.
Is this what we want it here ?

>
>>   }
>>   break;
>>   case USB_DT_ENDPOINT:
>>   epno = dev->config.if_desc[ifno].no_of_ep;
>> + if_desc = &dev->config.if_desc[ifno];
>>   /* found an endpoint */
>> - dev->config.if_desc[ifno].no_of_ep++;
>> - memcpy(&dev->config.if_desc[ifno].ep_desc[epno],
>> + if_desc->no_of_ep++;
>> + memcpy(&if_desc->ep_desc[epno],
>>   &buffer[index], buffer[index]);
>>   ep_wMaxPacketSize = get_unaligned(&dev->config.\
>>   if_desc[ifno].\
>> diff --git a/common/usb_storage.c b/common/usb_storage.c
>> index fb322b4..475c218 100644
>> --- a/common/usb_storage.c
>> +++ b/common/usb_storage.c
>> @@ -278,10 +278,10 @@ int usb_stor_scan(int mode)
>>lun++) {
>>   usb_dev_desc[usb_max_devs].lun = lun;
>>   if (usb_stor_get_info(dev, &usb_stor[start],
>> -
> &usb_dev_desc[usb_max_devs]) == 1) {

Do we really need this brace here? We just have one statement under this if.

>> - usb_max_devs++;
>> - }
>> + &usb_dev_desc[usb_max_devs]) == 1)
>> + usb_max_devs++;
>>   }
>> +
>
>
> What is this change here doing?

There were these unaligned braces for if part, which we removed.

>
>>   }
>>   /* if storage device */
>>   if (usb_max_devs == USB_MAX_STOR_DEV) {
>
> [..]
>
> Best regards,
> Marek Vasut
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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


Re: [U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout

2013-04-01 Thread Vivek Gautam
On Tue, Apr 2, 2013 at 11:04 AM, Vivek Gautam  wrote:
> Hi Marek,
>
>
> On Tue, Apr 2, 2013 at 10:42 AM, Marek Vasut  wrote:
>> Dear Vivek Gautam,
>>
>>> Hi,
>>>
>>> On Tue, Apr 2, 2013 at 1:43 AM, Tom Rini  wrote:
>>> > On Wed, Mar 27, 2013 at 02:59:00PM +0530, Vivek Gautam wrote:
>>> >> Patch b6d7852c increases timeout for enumeration, taking
>>> >> worst case to be 10 sec.
>>> >> get_timer() api returns timestamp in micro-seconds, which is
>>> >> what we are checking in the do-while() loop in usb_hub_configure()
>>> >> (get_timer(start) < CONFIG_SYS_HZ * 10).
>>> >> This should give us a required check for 10 seconds, and thereby
>>> >> we don't need to add additional mdelay of 100 microseconds in
>>> >> each cycle.
>>> >
>>> > The wording here is not correct.  get_timer operates in milliseconds not
>>> > microseconds.
>>>
>>> Oops!! Yes of course, my mistake. Thanks
>>
>> I have the patches queued in usb/next, you can send me a fix and I'll squash 
>> it
>> with what's already in there.
>
> Sure,  i shall send a fix for this.
> Should it be good actually to respin the complete patch-series with
> the changes you have suggested ??

I was out on weekend, so couldn't update the patch-series.

> The patches i could see in the 'next' are the originally posted ones.
>
>>
>> Best regards,
>> Marek Vasut
>
>
>
> --
> Thanks & Regards
> Vivek



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


Re: [U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout

2013-04-01 Thread Vivek Gautam
Hi Marek,


On Tue, Apr 2, 2013 at 10:42 AM, Marek Vasut  wrote:
> Dear Vivek Gautam,
>
>> Hi,
>>
>> On Tue, Apr 2, 2013 at 1:43 AM, Tom Rini  wrote:
>> > On Wed, Mar 27, 2013 at 02:59:00PM +0530, Vivek Gautam wrote:
>> >> Patch b6d7852c increases timeout for enumeration, taking
>> >> worst case to be 10 sec.
>> >> get_timer() api returns timestamp in micro-seconds, which is
>> >> what we are checking in the do-while() loop in usb_hub_configure()
>> >> (get_timer(start) < CONFIG_SYS_HZ * 10).
>> >> This should give us a required check for 10 seconds, and thereby
>> >> we don't need to add additional mdelay of 100 microseconds in
>> >> each cycle.
>> >
>> > The wording here is not correct.  get_timer operates in milliseconds not
>> > microseconds.
>>
>> Oops!! Yes of course, my mistake. Thanks
>
> I have the patches queued in usb/next, you can send me a fix and I'll squash 
> it
> with what's already in there.

Sure,  i shall send a fix for this.
Should it be good actually to respin the complete patch-series with
the changes you have suggested ??
The patches i could see in the 'next' are the originally posted ones.

>
> Best regards,
> Marek Vasut



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


Re: [U-Boot] [PATCH 3/4] power: Explicitly select pmic device's bus

2013-04-01 Thread Rajeshwari Birje
Hi Simon,

Just had one following comment

On Tue, Apr 2, 2013 at 5:34 AM, Simon Glass  wrote:
> From: Aaron Durbin 
>
> The current pmic i2c code assumes the current i2c bus is
> the same as the pmic device's bus. There is nothing ensuring
> that to be true. Therefore, select the proper bus before performing
> a transaction.
>
> Signed-off-by: Aaron Durbin 
> Signed-off-by: Simon Glass 
> Reviewed-by: Simon Glass 
> ---
>  drivers/power/power_i2c.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> index 3e5a784..ec9701e 100644
> --- a/drivers/power/power_i2c.c
> +++ b/drivers/power/power_i2c.c
> @@ -39,6 +39,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> if (check_reg(p, reg))
> return -1;
>
> +   I2C_SET_BUS(p->bus);
> +

Do we need to set I2C bus for each register read and write?
> switch (pmic_i2c_tx_num) {
> case 3:
> if (p->sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG) {
> @@ -82,6 +84,8 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
> if (check_reg(p, reg))
> return -1;
>
> +   I2C_SET_BUS(p->bus);
> +
> if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
> return -1;
>
> --
> 1.8.1.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
-- 
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] exynos: change indentation of defines in cpu.h

2013-04-01 Thread Minkyu Kang
Fix the indentation of some defines by tab.

Signed-off-by: Minkyu Kang 
---
 arch/arm/include/asm/arch-exynos/cpu.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index 2a20558..f76e489 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -93,9 +93,9 @@
 #define EXYNOS4X12_ADC_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_DP_BASE DEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_MODEM_BASE  DEVICE_NOT_AVAILABLE
-#define EXYNOS4X12_I2S_BASEDEVICE_NOT_AVAILABLE
-#define EXYNOS4X12_SPI_BASEDEVICE_NOT_AVAILABLE
-#define EXYNOS4X12_SPI_ISP_BASEDEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_I2S_BASEDEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_SPI_BASEDEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_SPI_ISP_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_ACE_SFR_BASEDEVICE_NOT_AVAILABLE
 
 /* EXYNOS5 Common*/
-- 
1.7.9.5
-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4 V3] EXYNOS5: FDT: Add compatible strings for Serial

2013-04-01 Thread Rajeshwari Birje
Hi Minkyu Kang,

Thank you for comment

On Fri, Mar 29, 2013 at 11:44 AM, Minkyu Kang  wrote:
> Dear Rajeshwari Shinde,
>
> On 15/03/13 19:38, Rajeshwari Shinde wrote:
>> Add required compatible information for s5p serial driver
>>
>> Signed-off-by: Abhilash Kesavan 
>> Signed-off-by: Rajeshwari Shinde 
>> Acked-by: Simon Glass 
>> ---
>> Changes in V2:
>> - Changed the compatible string to "samsung,exynos4210-uart"
>> Chnages in V3:
>>   - Rebased on latest u-boot-samsung
>>  include/fdtdec.h |1 +
>>  lib/fdtdec.c |1 +
>>  2 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> index 6552942..9f9cb4f 100644
>> --- a/include/fdtdec.h
>> +++ b/include/fdtdec.h
>> @@ -83,6 +83,7 @@ enum fdt_compat_id {
>>   COMPAT_SAMSUNG_EXYNOS_TMU,  /* Exynos TMU */
>>   COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
>>   COMPAT_MAXIM_98095_CODEC,   /* MAX98095 Codec */
>> + COMPAT_SAMSUNG_EXYNOS5_SERIAL,  /* Exynos5 UART */
>
> Is it exynos5 only?
> I think, we can use it to all of exynos series.
Will correct the same to  COMPAT_SAMSUNG_EXYNOS_SERIAL and resend the patch.
>
>>
>>   COMPAT_COUNT,
>>  };
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>> index 88f6b68..ee98e0e 100644
>> --- a/lib/fdtdec.c
>> +++ b/lib/fdtdec.c
>> @@ -58,6 +58,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>>   COMPAT(SAMSUNG_EXYNOS_TMU, "samsung,exynos-tmu"),
>>   COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
>>   COMPAT(MAXIM_98095_CODEC, "maxim,max98095-codec"),
>> + COMPAT(SAMSUNG_EXYNOS5_SERIAL, "samsung,exynos4210-uart"),
>>  };
>>
>>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
>>
>
> Thanks,
> Minkyu Kang.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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


Re: [U-Boot] [PATCH 1/3 V4] EXYNOS5: Add gpio pin numbering feature

2013-04-01 Thread Minkyu Kang
Dear Rajeshwari Birje,

On 02/04/13 14:08, Rajeshwari Birje wrote:
> Hi Minkyu Kang,
> 
> Thank you for comments.
> 
> On Mon, Apr 1, 2013 at 5:27 PM, Minkyu Kang  wrote:
>> On 21/03/13 20:33, Rajeshwari Shinde wrote:
>>> This patch adds support for gpio pin numbering support on
>>> EXYNOS5250
>>> To have consistent 0..n-1 GPIO numbering the banks are divided
>>> into different parts where ever they have holes in them.
>>>
>>> Signed-off-by: Leela Krishna Amudala 
>>> Signed-off-by: Rajeshwari Shinde 
>>> ---
>>> Changes in V2:
>>> - none.
>>> Changes in V3:
>>> - none.
>>> Changes in V4:
>>>   - To have consistent 0..n-1 GPIO numbering the banks are divided
>>>   into different parts where ever they have holes in them.
>>>   - Combined previous patch 1 and 2 into single patch.
>>>  arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +---
>>>  arch/arm/include/asm/arch-exynos/cpu.h  |   10 +-
>>>  arch/arm/include/asm/arch-exynos/gpio.h |  376 
>>> ++-
>>>  board/samsung/smdk5250/smdk5250.c   |   24 +--
>>>  drivers/gpio/s5p_gpio.c |   65 ++-
>>>  5 files changed, 508 insertions(+), 115 deletions(-)
>>>
>>> diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
>>> index 656bf4a..1b882cb 100644
>>> --- a/drivers/gpio/s5p_gpio.c
>>> +++ b/drivers/gpio/s5p_gpio.c
>>> @@ -36,6 +36,27 @@
>>>  #define RATE_MASK(x) (0x1 << (x + 16))
>>>  #define RATE_SET(x)  (0x1 << (x + 16))
>>>
>>> +
>>> +struct gpio_info {
>>> + unsigned int reg_addr;  /* Address of register for this part */
>>> + unsigned int max_gpio;  /* Maximum GPIO in this part */
>>> +};
>>> +
>>> +#ifdef CONFIG_EXYNOS5
>>
>> I think, this ifdef is unnecessary.
> I had put this #ifdef as EXYNOS4 will also have a gpio_data structure.

Exynos doesn't allow ifdefs on own drivers.
Please don't use it.

>>
>>> +static const struct gpio_info gpio_data[EXYNOS5_GPIO_NUM_PARTS] = {
>>
>> maybe it should be exynos5_gpio_data?
> No kept it as gpio_data as it would b easy to call the same from
> s5p_gpio_get_bank function and exynos4 will also have a separate
> structure.

I suggest that make two structure exynos5_gpio_data and exynos4_gpio_data,
and please remove ifdef.

>>
>>> + { EXYNOS5_GPIO_PART1_BASE, EXYNOS5_GPIO_MAX_PORT_PART_1 },
>>> + { EXYNOS5_GPIO_PART2_BASE, EXYNOS5_GPIO_MAX_PORT_PART_2 },
>>> + { EXYNOS5_GPIO_PART3_BASE, EXYNOS5_GPIO_MAX_PORT_PART_3 },
>>> + { EXYNOS5_GPIO_PART4_BASE, EXYNOS5_GPIO_MAX_PORT_PART_4 },
>>> + { EXYNOS5_GPIO_PART5_BASE, EXYNOS5_GPIO_MAX_PORT_PART_5 },
>>> + { EXYNOS5_GPIO_PART6_BASE, EXYNOS5_GPIO_MAX_PORT_PART_6 },
>>> + { EXYNOS5_GPIO_PART7_BASE, EXYNOS5_GPIO_MAX_PORT_PART_7 },
>>> + { EXYNOS5_GPIO_PART8_BASE, EXYNOS5_GPIO_MAX_PORT },
>>> +};
>>> +
>>> +#define HAVE_GENERIC_GPIO
>>> +#endif
>>> +
>>>  void s5p_gpio_cfg_pin(struct s5p_gpio_bank *bank, int gpio, int cfg)
>>>  {
>>>   unsigned int value;
>>> @@ -141,7 +162,30 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int 
>>> gpio, int mode)
>>>
>>>   writel(value, &bank->drv);
>>>  }
>>> -
>>> +#ifdef HAVE_GENERIC_GPIO
>>> +static struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned int gpio)
>>
>> please consider exynos4 also.
> Yes will update the same for exynos4 and send as soon as possible.

So, please modify this function and resend.

>>
>>> +{
>>> + const struct gpio_info *data;
>>> + unsigned int upto;
>>> + int i;
>>> +
>>> + for (i = upto = 0, data = gpio_data; i < EXYNOS5_GPIO_NUM_PARTS;

here. EXYNOS5 stuff.

>>> + i++, upto = data->max_gpio, data++) {
>>> + debug("i=%d, upto=%d\n", i, upto);
>>> + if (gpio < data->max_gpio) {
>>> + struct s5p_gpio_bank *bank;
>>> + bank = (struct s5p_gpio_bank *)data->reg_addr;
>>> + bank += (gpio - upto) / GPIO_PER_BANK;
>>> + debug("   gpio=%d, bank=%p\n", gpio, bank);
>>> + return bank;
>>> + }
>>> + }
>>> +#ifndef CONFIG_SPL_BUILD
>>> + assert(gpio < EXYNOS5_GPIO_MAX_PORT);   /* ...which it will not be */
>>> +#endif
>>> + return NULL;
>>> +}
>>> +#else
>>>  struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio)
>>>  {
>>>   int bank;
>>> @@ -151,6 +195,7 @@ struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio)
>>>   bank *= sizeof(struct s5p_gpio_bank);
>>>   return (struct s5p_gpio_bank *) (s5p_gpio_base(gpio) + bank);
>>>  }
>>> +#endif
>>>
>>>  int s5p_gpio_get_pin(unsigned gpio)
>>>  {
>>> @@ -196,3 +241,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),
>>> 

Re: [U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout

2013-04-01 Thread Marek Vasut
Dear Vivek Gautam,

> Hi,
> 
> On Tue, Apr 2, 2013 at 1:43 AM, Tom Rini  wrote:
> > On Wed, Mar 27, 2013 at 02:59:00PM +0530, Vivek Gautam wrote:
> >> Patch b6d7852c increases timeout for enumeration, taking
> >> worst case to be 10 sec.
> >> get_timer() api returns timestamp in micro-seconds, which is
> >> what we are checking in the do-while() loop in usb_hub_configure()
> >> (get_timer(start) < CONFIG_SYS_HZ * 10).
> >> This should give us a required check for 10 seconds, and thereby
> >> we don't need to add additional mdelay of 100 microseconds in
> >> each cycle.
> > 
> > The wording here is not correct.  get_timer operates in milliseconds not
> > microseconds.
> 
> Oops!! Yes of course, my mistake. Thanks

I have the patches queued in usb/next, you can send me a fix and I'll squash it 
with what's already in there.

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 1/3 V4] EXYNOS5: Add gpio pin numbering feature

2013-04-01 Thread Rajeshwari Birje
Hi Minkyu Kang,

Thank you for comments.

On Mon, Apr 1, 2013 at 5:27 PM, Minkyu Kang  wrote:
> On 21/03/13 20:33, Rajeshwari Shinde wrote:
>> This patch adds support for gpio pin numbering support on
>> EXYNOS5250
>> To have consistent 0..n-1 GPIO numbering the banks are divided
>> into different parts where ever they have holes in them.
>>
>> Signed-off-by: Leela Krishna Amudala 
>> Signed-off-by: Rajeshwari Shinde 
>> ---
>> Changes in V2:
>> - none.
>> Changes in V3:
>> - none.
>> Changes in V4:
>>   - To have consistent 0..n-1 GPIO numbering the banks are divided
>>   into different parts where ever they have holes in them.
>>   - Combined previous patch 1 and 2 into single patch.
>>  arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +---
>>  arch/arm/include/asm/arch-exynos/cpu.h  |   10 +-
>>  arch/arm/include/asm/arch-exynos/gpio.h |  376 
>> ++-
>>  board/samsung/smdk5250/smdk5250.c   |   24 +--
>>  drivers/gpio/s5p_gpio.c |   65 ++-
>>  5 files changed, 508 insertions(+), 115 deletions(-)
>>
>> diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
>> index 656bf4a..1b882cb 100644
>> --- a/drivers/gpio/s5p_gpio.c
>> +++ b/drivers/gpio/s5p_gpio.c
>> @@ -36,6 +36,27 @@
>>  #define RATE_MASK(x) (0x1 << (x + 16))
>>  #define RATE_SET(x)  (0x1 << (x + 16))
>>
>> +
>> +struct gpio_info {
>> + unsigned int reg_addr;  /* Address of register for this part */
>> + unsigned int max_gpio;  /* Maximum GPIO in this part */
>> +};
>> +
>> +#ifdef CONFIG_EXYNOS5
>
> I think, this ifdef is unnecessary.
I had put this #ifdef as EXYNOS4 will also have a gpio_data structure.
>
>> +static const struct gpio_info gpio_data[EXYNOS5_GPIO_NUM_PARTS] = {
>
> maybe it should be exynos5_gpio_data?
No kept it as gpio_data as it would b easy to call the same from
s5p_gpio_get_bank function and exynos4 will also have a separate
structure.
>
>> + { EXYNOS5_GPIO_PART1_BASE, EXYNOS5_GPIO_MAX_PORT_PART_1 },
>> + { EXYNOS5_GPIO_PART2_BASE, EXYNOS5_GPIO_MAX_PORT_PART_2 },
>> + { EXYNOS5_GPIO_PART3_BASE, EXYNOS5_GPIO_MAX_PORT_PART_3 },
>> + { EXYNOS5_GPIO_PART4_BASE, EXYNOS5_GPIO_MAX_PORT_PART_4 },
>> + { EXYNOS5_GPIO_PART5_BASE, EXYNOS5_GPIO_MAX_PORT_PART_5 },
>> + { EXYNOS5_GPIO_PART6_BASE, EXYNOS5_GPIO_MAX_PORT_PART_6 },
>> + { EXYNOS5_GPIO_PART7_BASE, EXYNOS5_GPIO_MAX_PORT_PART_7 },
>> + { EXYNOS5_GPIO_PART8_BASE, EXYNOS5_GPIO_MAX_PORT },
>> +};
>> +
>> +#define HAVE_GENERIC_GPIO
>> +#endif
>> +
>>  void s5p_gpio_cfg_pin(struct s5p_gpio_bank *bank, int gpio, int cfg)
>>  {
>>   unsigned int value;
>> @@ -141,7 +162,30 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int 
>> gpio, int mode)
>>
>>   writel(value, &bank->drv);
>>  }
>> -
>> +#ifdef HAVE_GENERIC_GPIO
>> +static struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned int gpio)
>
> please consider exynos4 also.
Yes will update the same for exynos4 and send as soon as possible.
>
>> +{
>> + const struct gpio_info *data;
>> + unsigned int upto;
>> + int i;
>> +
>> + for (i = upto = 0, data = gpio_data; i < EXYNOS5_GPIO_NUM_PARTS;
>> + i++, upto = data->max_gpio, data++) {
>> + debug("i=%d, upto=%d\n", i, upto);
>> + if (gpio < data->max_gpio) {
>> + struct s5p_gpio_bank *bank;
>> + bank = (struct s5p_gpio_bank *)data->reg_addr;
>> + bank += (gpio - upto) / GPIO_PER_BANK;
>> + debug("   gpio=%d, bank=%p\n", gpio, bank);
>> + return bank;
>> + }
>> + }
>> +#ifndef CONFIG_SPL_BUILD
>> + assert(gpio < EXYNOS5_GPIO_MAX_PORT);   /* ...which it will not be */
>> +#endif
>> + return NULL;
>> +}
>> +#else
>>  struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio)
>>  {
>>   int bank;
>> @@ -151,6 +195,7 @@ struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio)
>>   bank *= sizeof(struct s5p_gpio_bank);
>>   return (struct s5p_gpio_bank *) (s5p_gpio_base(gpio) + bank);
>>  }
>> +#endif
>>
>>  int s5p_gpio_get_pin(unsigned gpio)
>>  {
>> @@ -196,3 +241,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);
>> +}
>>
>
> Thanks,
> Minkyu Kang.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
Regards,
Rajeshwari Shinde

Re: [U-Boot] [PATCH 2/2] samsung: trats2: add support for new board Trats2

2013-04-01 Thread Minkyu Kang
Dear Piotr Wilczek,

On 25/03/13 18:58, Piotr Wilczek wrote:
> This patch add support for a new Samsung board Trats2.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Minkyu Kang 
> 
> ---
>  board/samsung/trats2/Makefile |   50 +
>  board/samsung/trats2/trats2.c |  465 
> +
>  boards.cfg|1 +
>  include/configs/trats2.h  |  291 ++
>  4 files changed, 807 insertions(+)
>  create mode 100644 board/samsung/trats2/Makefile
>  create mode 100644 board/samsung/trats2/trats2.c
>  create mode 100644 include/configs/trats2.h

missing MAINTAINER entry.

> 
> diff --git a/board/samsung/trats2/Makefile b/board/samsung/trats2/Makefile
> new file mode 100644
> index 000..7f507cc
> --- /dev/null
> +++ b/board/samsung/trats2/Makefile
> @@ -0,0 +1,50 @@
> +#
> +# Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd. All rights 
> reserved.
> +# Sanghee Kim 
> +#
> +# 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 $(TOPDIR)/config.mk
> +
> +LIB  = $(obj)lib$(BOARD).o
> +
> +COBJS-y  := trats2.o
> +
> +SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +
> +
> +$(LIB):  $(obj).depend $(OBJS)
> + $(call cmd_link_o_target, $(OBJS))
> +
> +clean:
> + rm -f $(OBJS)
> +
> +distclean:   clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
> new file mode 100644
> index 000..a60fb1a
> --- /dev/null
> +++ b/board/samsung/trats2/trats2.c
> @@ -0,0 +1,465 @@
> +/*
> + * Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd. All rights 
> reserved.

2013 please.

> + * Sanghee Kim 

Is author Sanghee?

> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static struct exynos4x12_gpio_part1 *gpio1;
> +static struct exynos4x12_gpio_part2 *gpio2;
> +
> +static unsigned int board_rev = -1;
> +
> +static inline u32 get_model_rev(void);
> +
> +static void check_hw_revision(void)
> +{
> + int modelrev = 0;
> + int i;
> +
> + /*
> +  * GPM1[1:0]: MODEL_REV[1:0]
> +  * Don't set as pull-none for these N/C pin.
> +  * TRM say that it may cause unexcepted state and leakage current.
> +  * and pull-none is only for output function.
> +  */
> + for (i = 0; i < 2; i++)
> + s5p_gpio_cfg_pin(&gpio2->m1, i, GPIO_INPUT);
> +
> + /* GPM1[5:2]: HW_REV[3:0] */
> + for (i = 2; i < 6; i++) {
> + s5p_gpio_cfg_pin(&gpio2->m1, i, GPIO_INPUT);
> + s5p_gpio_set_pull(&gpio2->m1, i, GPIO_PULL_NONE);
> + }
> +
> + udelay(1);
> +
> + /* GPM1[1:0]: MODEL_REV[1:0] */
> + for (i = 0; i < 2; i++)
> + modelrev |= (s5p_gpio_get_value(&gpio2->m1, i) << i);
> +
> + /* board_rev[15:8] = model */
> + board_rev = model

Re: [U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout

2013-04-01 Thread Vivek Gautam
Hi,


On Tue, Apr 2, 2013 at 1:43 AM, Tom Rini  wrote:
> On Wed, Mar 27, 2013 at 02:59:00PM +0530, Vivek Gautam wrote:
>
>> Patch b6d7852c increases timeout for enumeration, taking
>> worst case to be 10 sec.
>> get_timer() api returns timestamp in micro-seconds, which is
>> what we are checking in the do-while() loop in usb_hub_configure()
>> (get_timer(start) < CONFIG_SYS_HZ * 10).
>> This should give us a required check for 10 seconds, and thereby
>> we don't need to add additional mdelay of 100 microseconds in
>> each cycle.
>
> The wording here is not correct.  get_timer operates in milliseconds not
> microseconds.

Oops!! Yes of course, my mistake. Thanks

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



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


Re: [U-Boot] [PATCH] video: bcm2835: fix build issues

2013-04-01 Thread Anatolij Gustschin
On Mon, 01 Apr 2013 20:54:25 -0600
Stephen Warren  wrote:
...
> FYI, I just tested these patches as they exist in u-boot/master, and the
> RPi "LCD" support still works fine after these patches. Thanks.

Thanks for testing!

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


Re: [U-Boot] [PATCH] Add initial support for mx6slevk board

2013-04-01 Thread Vikram Narayanan

On 4/2/2013 3:45 AM, Fabio Estevam wrote:

On Mon, Apr 1, 2013 at 2:44 PM, Fabio Estevam  wrote:

On Mon, Apr 1, 2013 at 2:26 PM, Vikram Narayanan  wrote:


Is the above same for all the variants of i.Mx?
Can we put this into a common header file?


Ok, I can try to put this into a common location.


+#define IOMUX_CONFIG_SION 0x10
+#define NO_MUX_I0
+#define NO_PAD_I0
+enum {
+   MX6_PAD_AUD_MCLK__AUDMUX_AUDIO_CLK_OUT  =
IOMUX_PAD(0x02A4, 0x004C, 0, 0x, 0, 0),
+   MX6_PAD_AUD_MCLK__PWM4_PWMO =
IOMUX_PAD(0x02A4, 0x004C, 1, 0x, 0, 0),
+   MX6_PAD_AUD_MCLK__ECSPI3_RDY=
IOMUX_PAD(0x02A4, 0x004C, 2, 0x06B4, 0, 0),
+   MX6_PAD_AUD_MCLK__FEC_MDC   =
IOMUX_PAD(0x02A4, 0x004C, 3, 0x, 0, 0),



Is the mx6slevk using all the pins defined here?


No, I put all pins for completion.


I meant completeness, here.


If not please take off the unused IOMUX pins so that we don't add dead code.


I thought it was common practice to provide the complete IOMUX pin file.


Looking at mx6q_pins.h I see that the IOMUX table is complete, but
mx6dl_pins.h is not, so just want to get a confirmation  first before
doing v2.


Please refer the mx6dl discussion here.
http://www.mail-archive.com/u-boot@lists.denx.de/msg94194.html

It was Troy's idea, to include only the necessary pins.

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


Re: [U-Boot] [PATCH] video: bcm2835: fix build issues

2013-04-01 Thread Stephen Warren
On 03/29/2013 07:34 AM, Anatolij Gustschin wrote:
> On Fri, 29 Mar 2013 14:10:09 +0100
> Anatolij Gustschin  wrote:
> 
>> After merging LCD patches for v2013.04 the bcm2835 video
>> driver building is broken due to removal of many global
>> variables. Fix the driver.
>>
>> Signed-off-by: Anatolij Gustschin 
>> Cc: Stephen Warren 
>> ---
>>  common/lcd.c|   12 
>>  drivers/video/bcm2835.c |   11 ---
>>  2 files changed, 12 insertions(+), 11 deletions(-)
> 
> applied to u-boot-video/master.

FYI, I just tested these patches as they exist in u-boot/master, and the
RPi "LCD" support still works fine after these patches. Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/3] mx6qsabrelite: Remove duplicate 'mmc dev'

2013-04-01 Thread Fabio Estevam
From: Fabio Estevam 

No need to call 'mmc dev' twice.

Signed-off-by: Fabio Estevam 
---
 include/configs/mx6qsabrelite.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index fb58265..6d4b837 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -216,7 +216,6 @@
"fi;\0"
 
 #define CONFIG_BOOTCOMMAND \
-  "mmc dev ${mmcdev};" \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
   "if run loadbootscript; then " \
   "run bootscript; " \
-- 
1.7.9.5

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


[U-Boot] [PATCH 3/3] wandboard: Remove CONFIG_SYS_FSL_USDHC_NUM

2013-04-01 Thread Fabio Estevam
From: Fabio Estevam 

CONFIG_SYS_FSL_USDHC_NUM is not used for wandboard.

Signed-off-by: Fabio Estevam 
---
 include/configs/wandboard.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 00c656e..120e3f6 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -58,7 +58,6 @@
 #define CONFIG_FSL_ESDHC
 #define CONFIG_FSL_USDHC
 #define CONFIG_SYS_FSL_ESDHC_ADDR  0
-#define CONFIG_SYS_FSL_USDHC_NUM   2
 
 #define CONFIG_MMC
 #define CONFIG_CMD_MMC
-- 
1.7.9.5

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


[U-Boot] [PATCH 1/3] wandboard: Remove duplicate 'mmc dev'

2013-04-01 Thread Fabio Estevam
From: Fabio Estevam 

No need to call 'mmc dev' twice. 

Signed-off-by: Fabio Estevam 
---
 include/configs/wandboard.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index c4fb704..00c656e 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -150,7 +150,6 @@
"fi;\0"
 
 #define CONFIG_BOOTCOMMAND \
-  "mmc dev ${mmcdev};" \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
   "if run loadbootscript; then " \
   "run bootscript; " \
-- 
1.7.9.5

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


[U-Boot] [PATCH 3/4] power: Explicitly select pmic device's bus

2013-04-01 Thread Simon Glass
From: Aaron Durbin 

The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.

Signed-off-by: Aaron Durbin 
Signed-off-by: Simon Glass 
Reviewed-by: Simon Glass 
---
 drivers/power/power_i2c.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index 3e5a784..ec9701e 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -39,6 +39,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
if (check_reg(p, reg))
return -1;
 
+   I2C_SET_BUS(p->bus);
+
switch (pmic_i2c_tx_num) {
case 3:
if (p->sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG) {
@@ -82,6 +84,8 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
if (check_reg(p, reg))
return -1;
 
+   I2C_SET_BUS(p->bus);
+
if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
return -1;
 
-- 
1.8.1.3

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


[U-Boot] [PATCH 0/4] Add support for TI TPS65090

2013-04-01 Thread Simon Glass
This series adds support for the TPS65090 PMIC as used on the Samsung
ARM Chromebook. It is plumbed into smdk5250 for now, while we await
the exynos5-dt board being applied upstream.


Aaron Durbin (3):
  exynos5: Enable tps65090 on smdk5250
  power: Explicitly select pmic device's bus
  exynos5: support tps65090 pmic

Tom Wai-Hong Tam (1):
  power: Add support for TPS65090 PMU chip.

 board/samsung/smdk5250/smdk5250.c   |  33 +++-
 doc/device-tree-bindings/power/tps65090.txt |  21 ++
 drivers/power/pmic/Makefile |   1 +
 drivers/power/pmic/pmic_tps65090.c  | 296 
 drivers/power/power_i2c.c   |   4 +
 include/configs/exynos5250-dt.h |   1 +
 include/fdtdec.h|   1 +
 include/power/tps65090_pmic.h   |  83 
 lib/fdtdec.c|   1 +
 9 files changed, 433 insertions(+), 8 deletions(-)
 create mode 100644 doc/device-tree-bindings/power/tps65090.txt
 create mode 100644 drivers/power/pmic/pmic_tps65090.c
 create mode 100644 include/power/tps65090_pmic.h

-- 
1.8.1.3

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


Re: [U-Boot] [PATCH v2 0/45] Verified boot implementation based on FIT

2013-04-01 Thread Kim Phillips
On Mon, 18 Mar 2013 16:51:20 -0700
Simon Glass  wrote:

> I have received a number of off-list comments - please do copy the list when
> replying so that everyone can see your comments.

I don't have time to fully review 45 patches, let alone the subject
matter (e.g., no support for RSA in h/w, eh? ;), but I did notice
some things that bugged me:

Re: "[PATCH v2 04/45] libfdt: Add fdt_next_subnode() to permit easy subnode 
iteration":

- Where's our libfdt maintainer?  libfdt patches should be submitted
to the dtc project first.  It appears "[PATCH v2 40/45] libfdt: Add
fdt_find_regions()" also suffers from this problem.

- can we improve on the readability of that for loop - the improved
one the patch gives us is this:

> for (ndepth = 0,
>   noffset = fdt_next_subnode(fit, image_noffset, &ndepth);
>   noffset >= 0;
>   noffset = fdt_next_subnode(fit, noffset, &ndepth)) {

whereas perhaps something like this:

ndepth = 0;
noffset = fdt_next_subnode(fit, image_noffset, &ndepth);
while (noffset >= 0) {
// body
noffset = fdt_next_subnode(fit, noffset, &ndepth);
}

would be much easier to quickly visually parse?

this would also affect:

Re: "[PATCH v2 12/45] image: Move hash checking into its own function":
- which also adds lines like these:

> + *err_msgp = " error!\nCan't get hash algo "
> + "property";

upon which a subsequent patch ("[PATCH v2 13/45] image: Move error!
string to common place", if I'm not mistaken) corrects.  Are you
intentionally trying to make people review the same code twice??

Re: "[PATCH v2 07/45] image: Split FIT code into new image-fit.c"
- after the code is split, it appears the rest of the patchseries
works on improving image-fit.c instead of updating equivalent code
still existing in image.c, IIRC, "[PATCH v2 13/45] image: Move error!
string to common place"
- I also found it odd that git format-patch -M on this doesn't
produce a shorter patch with "% equivalent" statistics: what else
changed?

Re: "[PATCH v2 22/45] env: Fix minor comment typos in cmd_nvedit":
- I personally appreciate it when authors of such large patchseries
put the trivial stuff first, as if to follow the logical progression
of the complexity (and therefore acceptability) of the patches in
the series.  Make things like this the first patch in the series -
that way maintainers can be tempted to start applying obvious
patches from early patchseries versions.  This also applies to
patches like [PATCH v2 24/45] Revert "fdt- Tell the FDT library
where the device tree is", and:

Re: "[PATCH v2 25/45] Add stdarg to vsprintf.h":
- which contains the text "TODO: Probably should drop this patch?".
Well?  Did you mean this series to be an RFC?

I'm stopping my already brief review here - please clean this up.

Kim

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


Re: [U-Boot] [PATCH v2 4/7] patman: Provide option to ignore bad aliases

2013-04-01 Thread Doug Anderson
Simon,

On Tue, Mar 26, 2013 at 4:09 PM, Simon Glass  wrote:
> Often it happens that patches include tags which don't have aliases. It
> is annoying that patman fails in this case, and provides no option to
> continue other than adding empty tags to the .patman file.
>
> Correct this by adding a '-t' option to ignore tags that don't exist.
> Print a warning instead.
>
> Since running the tests is not a common operation, move this to --test
> instead, to reserve -t for this new option.
>
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Add comment about meaning of raise_on_error=False
> - Remove 'ignore_errors' and just use 'raise_on_error' everywhere
> - Use keyword args for raise_on_error

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


Re: [U-Boot] [PATCH v2 6/7] patman: Add Series-process-log tag to sort/uniq change logs

2013-04-01 Thread Doug Anderson
Simon,

On Tue, Mar 26, 2013 at 4:09 PM, Simon Glass  wrote:
> For some series with lots of changes it is annoying that duplicate change
> log items are not caught. It is also helpful sometimes to sort the change
> logs.
>
> Add a Series-process-log tag to enable this, which can be placed in a
> commit to control this.
>
> The change to the Cc: line is to fix a checkpatch warning.
>
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Require sort, uniq tags to be comma-separated
>
>  tools/patman/README | 9 -
>  tools/patman/patchstream.py | 2 +-
>  tools/patman/series.py  | 9 +++--
>  3 files changed, 16 insertions(+), 4 deletions(-)

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


[U-Boot] [PATCH 4/4] exynos5: support tps65090 pmic

2013-04-01 Thread Simon Glass
From: Aaron Durbin 

The TSP65090 is a PMIC on some exynos5 boards. The init function is
called for the TPS65090 pmic. If that device is not a part of the device
tree (returns -ENODEV) then continue. Otherwise return a failure.

Signed-off-by: Aaron Durbin 
Signed-off-by: Simon Glass 
Reviewed-by: Simon Glass 
---
 board/samsung/smdk5250/smdk5250.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/board/samsung/smdk5250/smdk5250.c 
b/board/samsung/smdk5250/smdk5250.c
index 217c6df..06f9ea6 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -155,17 +156,10 @@ static int pmic_reg_update(struct pmic *p, int reg, uint 
regval)
return 0;
 }
 
-int power_init_board(void)
+int max77686_init(void)
 {
struct pmic *p;
 
-   set_ps_hold_ctrl();
-
-   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
-
-   if (pmic_init(I2C_PMIC))
-   return -1;
-
p = pmic_get("MAX77686_PMIC");
if (!p)
return -ENODEV;
@@ -250,6 +244,29 @@ int power_init_board(void)
 
return 0;
 }
+
+int power_init_board(void)
+{
+   int ret;
+
+   set_ps_hold_ctrl();
+
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+
+   if (pmic_init(I2C_PMIC))
+   return -1;
+
+   if (max77686_init())
+   return -1;
+
+   /* The TPS65090 may not be in the device tree. If so, it is not
+* an error. */
+   ret = tps65090_init();
+   if (ret == 0 || ret == -ENODEV)
+   return 0;
+
+   return -1;
+}
 #endif
 
 void dram_init_banksize(void)
-- 
1.8.1.3

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


[U-Boot] [PATCH 1/4] power: Add support for TPS65090 PMU chip.

2013-04-01 Thread Simon Glass
From: Tom Wai-Hong Tam 

This adds driver support for the TPS65090 PMU. Support includes
hooking into the pmic infrastructure  so that the pmic commands
can be used on the console. The TPS65090 supports the following
functionality:

- fet enable/disable/querying
- getting and setting of charge state

Even though it is connected to the pmic infrastructure it does
not hook into the pmic charging charging infrastructure.

Signed-off-by: Tom Wai-Hong Tam 
Signed-off-by: Simon Glass 
Signed-off-by: Hatim Ali 
Signed-off-by: Katie Roberts-Hoffman 
Signed-off-by: Rong Chang 
Signed-off-by: Sean Paul 
Signed-off-by: Vincent Palatin 
Signed-off-by: Aaron Durbin 
---
 doc/device-tree-bindings/power/tps65090.txt |  21 ++
 drivers/power/pmic/Makefile |   1 +
 drivers/power/pmic/pmic_tps65090.c  | 296 
 include/fdtdec.h|   1 +
 include/power/tps65090_pmic.h   |  83 
 lib/fdtdec.c|   1 +
 6 files changed, 403 insertions(+)
 create mode 100644 doc/device-tree-bindings/power/tps65090.txt
 create mode 100644 drivers/power/pmic/pmic_tps65090.c
 create mode 100644 include/power/tps65090_pmic.h

diff --git a/doc/device-tree-bindings/power/tps65090.txt 
b/doc/device-tree-bindings/power/tps65090.txt
new file mode 100644
index 000..6a8a884
--- /dev/null
+++ b/doc/device-tree-bindings/power/tps65090.txt
@@ -0,0 +1,21 @@
+TPSchrome binding
+=
+
+The device tree node which describes the operation of the Texas Instrument
+TPS65090 power regulator chip is as follows:
+
+Required properties :
+- compatible : "ti,tps65090"
+- reg : slave address on the i2c bus
+
+The tps65090 node should appear as a subnode of the i2c bus that connects it.
+
+Example
+===
+
+   i2c@12ca {
+   power-regulator@48 {
+   compatible = "ti,tps65090"
+   reg = <0x48>;
+   };
+   };
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 14d426f..a66d940 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -29,6 +29,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/power/pmic/pmic_tps65090.c 
b/drivers/power/pmic/pmic_tps65090.c
new file mode 100644
index 000..ef9f911
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090.c
@@ -0,0 +1,296 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_NAME "TPS65090_PMIC"
+
+/* TPS65090 register addresses */
+enum {
+   REG_CG_CTRL0 = 4,
+   REG_CG_STATUS1 = 0xa,
+   REG_FET1_CTRL = 0x0f,
+   REG_FET2_CTRL,
+   REG_FET3_CTRL,
+   REG_FET4_CTRL,
+   REG_FET5_CTRL,
+   REG_FET6_CTRL,
+   REG_FET7_CTRL,
+   TPS65090_NUM_REGS,
+};
+
+enum {
+   CG_CTRL0_ENC_MASK   = 0x01,
+
+   MAX_FET_NUM = 7,
+   MAX_CTRL_READ_TRIES = 5,
+
+   /* TPS65090 FET_CTRL register values */
+   FET_CTRL_TOFET  = 1 << 7,  /* Timeout, startup, overload */
+   FET_CTRL_PGFET  = 1 << 4,  /* Power good for FET status */
+   FET_CTRL_WAIT   = 3 << 2,  /* Overcurrent timeout max */
+   FET_CTRL_ADENFET= 1 << 1,  /* Enable output auto discharge */
+   FET_CTRL_ENFET  = 1 << 0,  /* Enable FET */
+};
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id   FET number to check
+ * @return 0 if ok, -1 if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+   if (fet_id == 0 || fet_id > MAX_FET_NUM) {
+   debug("parameter fet_id is out of range, %u not in 1 ~ %u\n",
+ fet_id, MAX_FET_NUM);
+   return -1;
+   }
+
+   return 0;
+}
+
+/**
+ * Set the power state for a FET
+ *
+ * @param pmic pmic structure for the tps65090
+ * @param fet_id   Fet number to set (1..MAX_FET_NUM)
+ * @param set  1 to power on FET, 0 to power off
+ * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if the
+ * FET failed to change state. If all is ok, returns 0.
+ */
+static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
+{
+   int retry;
+   u32 reg, value;
+
+   value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
+   if (set)
+  

[U-Boot] [PATCH 2/4] exynos5: Enable tps65090 on smdk5250

2013-04-01 Thread Simon Glass
From: Aaron Durbin 

The TPS65090 pmic chip can be on exynos5250 boards. Therefore,
select the appropriate config option for TPS65090 devices.

This commit should really use exynos5-dt.c, when it is available.

Signed-off-by: Simon Glass 
Reviewed-by: Simon Glass 
---
 include/configs/exynos5250-dt.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 2b9d6ac..4ae5b27 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -261,6 +261,7 @@
 #define CONFIG_POWER
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_MAX77686
+#define CONFIG_POWER_TPS65090
 
 /* SPI */
 #define CONFIG_ENV_IS_IN_SPI_FLASH
-- 
1.8.1.3

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


Re: [U-Boot] [PATCH v2 2/7] patman: Don't allow spaces in tags

2013-04-01 Thread Doug Anderson
Simon,

On Tue, Mar 26, 2013 at 4:09 PM, Simon Glass  wrote:
> At present something like:
>
>Revert "arm: Add cache operations"
>
> will try to use
>
>Revert "arm
>
> as a tag. Clearly this is wrong, so fix it.
>
> If the revert is intended to be tagged, then the tag can come before
> the revert, perhaps. Alternatively the 'Cc' tag can be used in the commit
> messages.
>
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Adjust to not allow any spaces in tags, change commit title
>
>  tools/patman/commit.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 1/7] patman: Fix up checkpatch parsing to deal with 'CHECK' lines

2013-04-01 Thread Doug Anderson
Simon,

On Tue, Mar 26, 2013 at 4:09 PM, Simon Glass  wrote:
> checkpatch has a new type of warning, a 'CHECK'. At present patman fails
> with these, which makes it less than useful.
>
> Add support for checks, making it backwards compatible with the old
> checkpatch.
>
> At the same time, clean up formatting of the CheckPatches() output,
> fix erroneous "internal error" if multiple patches have warnings and
> be more robust to new types of problems.
>
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Update code to remove match_count
> - Update commit message to add detail on what is changing
> - Update tests to check the 'checks' value, and add a new test
> - Use namedtuple to hold the return value from CheckPatch() function
>
>  tools/patman/checkpatch.py | 110 
> -
>  tools/patman/test.py   |  64 +-
>  2 files changed, 112 insertions(+), 62 deletions(-)

Thanks for fixing and for fixing up the tests as well.

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


Re: [U-Boot] AM3517_EVM, MLO not booting

2013-04-01 Thread James Chandler
Hello,

I was able to snag a BDI3000 and debug the issue.  It turns out that the 
NS16550 driver contains a while loop that waits for register or some other 
value to be set during the SPL's serial_init() function.  This condition was 
not being met, causing serial_init() to hang.  The solution was to add #define 
CONFIG_SYS_NS16550_BROKEN_TEMT to the AM3517_EVM configuration.  I tried to 
push this back into the git repository but get unexpected hang-up errors (new 
to git as well).

Thanks,
James

From: James Chandler
Sent: Monday, April 01, 2013 11:29 AM
To: u-boot@lists.denx.de
Subject: AM3517_EVM, MLO not booting

Hello,

I am new to *nix/open-source mailing lists, so please provide any feedback 
about my post that would make future posts cleaner or easier to respond to.

I am trying to build the u-boot-arm tree/fork from denx.de (new to git so the 
correct terminology escapes me) for a AM3517_EV LogicPD evaluation board.  I 
cloned the git repository, built the MLO and u-boot.img files and then placed 
them on the first partition of my SD card (fat32, active, correct #of cylinders 
and heads).  When I switch the power on I get two characters on my serial 
console ( the first is a checker-board block from extended ascii of 170ish and 
the other is a 't') and then no output follows.

I am switching to the u-boot-arm tree/fork from the u-boot-am33x tree/fork at 
the Arago project, because the u-boot-am33x code from there doesn't have 
functional fatwrite and ext4write commands (I can build with them in place, but 
fatwrite causes mmc errors and timeout errors while ext4write does not give an 
error but does not create a file).  If I use the MLO from u-boot-am33x but the 
u-boot.img from u-boot-arm, I can boot into the u-boot environment and into 
Linux.  The fatwrite and the ext4write commands on u-boot-arm also work unlike 
those in u-boot-am33x.

I also have a custom board based on the AM3517_EVM (same CPU and RAM just no 
flash).  I copied the AM35117_EVM configuration and board/* files and made only 
changes related to removing flash support (since the custom board does not have 
it) and the custom board does boot using both MLO and u-boot.img from 
u-boot-arm.

Has anyone else had issues with MLO on the AM3517_EVM?  If so, are there any 
workable solutions?

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


Re: [U-Boot] [PATCH] Add initial support for mx6slevk board

2013-04-01 Thread Fabio Estevam
On Mon, Apr 1, 2013 at 2:44 PM, Fabio Estevam  wrote:
> On Mon, Apr 1, 2013 at 2:26 PM, Vikram Narayanan  wrote:
>
>> Is the above same for all the variants of i.Mx?
>> Can we put this into a common header file?
>
> Ok, I can try to put this into a common location.
>
>>> +#define IOMUX_CONFIG_SION 0x10
>>> +#define NO_MUX_I0
>>> +#define NO_PAD_I0
>>> +enum {
>>> +   MX6_PAD_AUD_MCLK__AUDMUX_AUDIO_CLK_OUT  =
>>> IOMUX_PAD(0x02A4, 0x004C, 0, 0x, 0, 0),
>>> +   MX6_PAD_AUD_MCLK__PWM4_PWMO =
>>> IOMUX_PAD(0x02A4, 0x004C, 1, 0x, 0, 0),
>>> +   MX6_PAD_AUD_MCLK__ECSPI3_RDY=
>>> IOMUX_PAD(0x02A4, 0x004C, 2, 0x06B4, 0, 0),
>>> +   MX6_PAD_AUD_MCLK__FEC_MDC   =
>>> IOMUX_PAD(0x02A4, 0x004C, 3, 0x, 0, 0),
>>
>>
>> Is the mx6slevk using all the pins defined here?
>
> No, I put all pins for completion.

I meant completeness, here.

>> If not please take off the unused IOMUX pins so that we don't add dead code.
>
> I thought it was common practice to provide the complete IOMUX pin file.

Looking at mx6q_pins.h I see that the IOMUX table is complete, but
mx6dl_pins.h is not, so just want to get a confirmation  first before
doing v2.

Regards,

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


[U-Boot] [PATCH] mmc: don't allow extra cmdline arguments

2013-04-01 Thread Stephen Warren
From: Stephen Warren 

The "mmc rescan" command takes no arguments. However, executing
"mmc rescan 1" succeeds, leading the user to believe that MMC device 1
has been rescanned. In fact, the "current" MMC device has been
rescanned, and the current device may well not be 1. Add error-checking
to the "mmc" command to explicitly reject any extra command-line
arguments so that it's more obvious when U-Boot isn't doing what the
user thought they asked it to.

Signed-off-by: Stephen Warren 
---
 common/cmd_mmc.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 8c53a10..9f3d6c5 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -164,8 +164,12 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 
if (strcmp(argv[1], "rescan") == 0) {
-   struct mmc *mmc = find_mmc_device(curr_device);
+   struct mmc *mmc;
 
+   if (argc != 2)
+   return CMD_RET_USAGE;
+
+   mmc = find_mmc_device(curr_device);
if (!mmc) {
printf("no mmc device at slot %x\n", curr_device);
return 1;
@@ -179,8 +183,12 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return 0;
} else if (strncmp(argv[1], "part", 4) == 0) {
block_dev_desc_t *mmc_dev;
-   struct mmc *mmc = find_mmc_device(curr_device);
+   struct mmc *mmc;
+
+   if (argc != 2)
+   return CMD_RET_USAGE;
 
+   mmc = find_mmc_device(curr_device);
if (!mmc) {
printf("no mmc device at slot %x\n", curr_device);
return 1;
@@ -196,6 +204,8 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
puts("get mmc type error!\n");
return 1;
} else if (strcmp(argv[1], "list") == 0) {
+   if (argc != 2)
+   return CMD_RET_USAGE;
print_mmc_devices('\n');
return 0;
} else if (strcmp(argv[1], "dev") == 0) {
-- 
1.7.10.4

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


Re: [U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout

2013-04-01 Thread Tom Rini
On Wed, Mar 27, 2013 at 02:59:00PM +0530, Vivek Gautam wrote:

> Patch b6d7852c increases timeout for enumeration, taking
> worst case to be 10 sec.
> get_timer() api returns timestamp in micro-seconds, which is
> what we are checking in the do-while() loop in usb_hub_configure()
> (get_timer(start) < CONFIG_SYS_HZ * 10).
> This should give us a required check for 10 seconds, and thereby
> we don't need to add additional mdelay of 100 microseconds in
> each cycle.

The wording here is not correct.  get_timer operates in milliseconds not
microseconds.

-- 
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 V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-01 Thread Tom Rini
On Mon, Apr 01, 2013 at 09:22:41PM +0530, Sricharan R wrote:

> Now with kernel moving to all device tree, the default
> boot command is changed to pass the device tree blob.
> Also, adding the findfdt command to get the dt-blob
> based on the board.
> 
> Thanks to Tom Rini  for suggesting this.
> 
> Signed-off-by: Sricharan R 
[snip]
> @@ -145,6 +149,10 @@
>   "loadaddr=0x8200\0" \
>   "console=ttyO2,115200n8\0" \
>   "fdt_high=0x\0" \
> + "fdtaddr=0x80f8\0" \
> + "bootpart=0:1\0" \
> + "bootdir=\0" \
> + "bootfile=uImage\0" \

What about 0:2 and /boot, ala am335x_evm as well?  I'm not aware of any
distributions being really clever and mounting the FAT partition to
/boot and I know some that have been expecting and using their
ext*-located kernels for a while for various TI platforms.  And wer're
moving in that latter direction too :)  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] Patches for this merge window

2013-04-01 Thread Simon Glass
Hi Tom,

On Wed, Mar 20, 2013 at 1:07 PM, Tom Rini  wrote:

> On Wed, Mar 20, 2013 at 12:53:06PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > [sorry I wrote this yesterday and didn't send]
> >
> > On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini  wrote:
> > > [take 2 for me, gmail defaults to reply not reply-all]
> > >
> > > On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass  wrote:
> > [..]
> > >> Generic board is also a big change, but since it is sort-of parallel
> > >> to existing code and only turned on on a board-by-board basis the risk
> > >> is lower - it just need some weeks of review time IMO.
> > >
> > > Sounds good, thanks!
> >
> > And generic board is in also now, which is a big step. Thanks for all
> > your effort on that.
> >
> > I am about to rev the verified boot series, and FIT image series base
> > on feedback.
> >
> > Also, what is happening on the TPM side? I think we have all the
> > pieces for making the TPM work properly in U-Boot, as previously
> > discussed. Along with verified boot we have a pretty solid
> > implementation now.
>
> So, I really want Wolfgang to weigh in on the verified boot side of
> things (and I need to review it harder and think myself).  On a related
> note, have you seen
>
> http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html
> yet?  It almost looks like easy enough that I could get that wired up
> here but is also another real life case we should take into account and
> make easy enough to handle and support in mainline.


Yes it would be good to get Wolfgang's feedback. I will also update the
follow-on 'image' series.

I had a good look through this, after doing a rough rebase to master.

The main parts are:

- RSA
- A move comprehensive TPM library
- Plumbing to call tpm_extend when there is user data loaded (environment,
kernel, ramdisk, command line...)

It brings in some additional code from the Chromium tree, which we have
been upstreaming.

The first two (RSA and TPM library) are mostly covered by my vboot series
and Che-Liang's TPM work. I suggest that the TPM additions in sboot could
be done by adding the missing features on top of Che-Liang's work. For the
third part (the plumbing), this could become a CONFIG option I think.

The two verified boot implementations use similar infrastructure, but are
somewhat different. My one works around FIT images, assuming a read-only
root of trust, and is intended to use the TPM for rollback protection only
so far. Images within the FIT are verified with a public key, and image
verification can be chained.

The sboot implementation also requires some trusted read-only code, but
then uses tpm_extend on each new chunk of user data/code loaded. It
requires the chain of tpm_extends to be played back and stored in the TPM,
then the TPM is locked and future boots must replay with the same code. So
it is not quite as easy to upgrade images (e.g. move to a new kernel)
although I'm sure this problem could be solved using a suitable mechanism.

It would be possible to support much of the functionality of the sboot
implementation within FIT, and certainly the fact that both need similar
infrastructure means that I think the FIT-based verified boot is a good
basis for upstreaming the sboot implementation when this is ready.

If you are interested I pushed my rebased branch to the x86 tree (branch is
try-sboot) - this is missing some code since I didn't do a proper rebase,
but if is much easier to diff against master.

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


Re: [U-Boot] [RFC] MAKEALL: Fix case substitution for old bash

2013-04-01 Thread York Sun
On 03/30/2013 03:30 PM, Simon Glass wrote:
> +U-Boot
> 
> Hi Allen, York,
> 
> On Fri, Mar 29, 2013 at 11:05 AM, Allen Martin  > wrote:
> 
> On Fri, Mar 29, 2013 at 10:56:33AM -0700, York Sun wrote:
> > On 03/29/2013 10:52 AM, Allen Martin wrote:
> > > On Fri, Mar 29, 2013 at 10:49:06AM -0700, York Sun wrote:
> > >> On 03/29/2013 10:29 AM, Allen Martin wrote:
> > >>> On Fri, Mar 29, 2013 at 09:56:41AM -0700, York Sun wrote:
> >  On 03/27/2013 12:55 PM, Tom Rini wrote:
> > > On Thu, Mar 21, 2013 at 01:38:37PM -0700, York Sun wrote:
> > >> On 03/21/2013 01:28 PM, Allen Martin wrote:
> > > [snip]
> > >>> PS: What happened with your bool fixup patch?  I'm a big
> fan of that
> > >>> patch :^)
> > >>>
> > >>
> > >> Tom asked on March 4th. I think he will accept it.
> > >
> > > I never got the expected acks on v7 that I thought would be
> forthcoming.
> > >
> > 
> >  Allen,
> > 
> >  Can you ack the v7 of the bool fixup patch? Tom seems waiting
> for you.
> > >>>
> > >>> Oh sorry, I didn't realize there was a newer version of the
> patch I
> > >>> hadn't ack'ed yet.  I'll take a look today.  Do you know if it
> still
> > >>> applies cleanly to TOT u-boot/master, or will it need to be
> rebased?
> > >>>
> > >>
> > >> It almost applies cleanly.
> > >>
> > >> Checking patch board/xilinx/common/xbasic_types.h...
> > >> error: board/xilinx/common/xbasic_types.h: does not exist in index
> > >>
> > >> due to commit
> > >>
> > >> commit 151eeeb2754da4b2d26bb878206d45ce58276fe0
> > >> Author: Michal Simek  >
> > >> Date:   Wed Jan 23 14:11:50 2013 +0100
> > >>
> > >> board: xilinx: Remove common folder
> > >>
> > >> All these files was used for ancient xilinx drivers
> > >> which are finally gone.
> > >>
> > >> Signed-off-by: Michal Simek  >
> > >> Tested-by: Rommel Custodio  >
> > >>
> > >>  board/xilinx/common/xbasic_types.c |  165 
> > >>  board/xilinx/common/xbasic_types.h |  283 --
> > >>  board/xilinx/common/xbuf_descriptor.h  |  252 --
> > >>  board/xilinx/common/xdma_channel.c |  738 
> > >>  board/xilinx/common/xdma_channel.h |  291 --
> > >>  board/xilinx/common/xdma_channel_i.h   |  110 ---
> > >>  board/xilinx/common/xdma_channel_sg.c  | 1317
> > >> 
> > >>  board/xilinx/common/xio.h  |   81 --
> > >>  board/xilinx/common/xipif_v1_23_b.c|  331 ---
> > >>  board/xilinx/common/xipif_v1_23_b.h|  746 
> > >>  board/xilinx/common/xpacket_fifo_v1_00_b.c |  448 --
> > >>  board/xilinx/common/xpacket_fifo_v1_00_b.h |  306 ---
> > >>  board/xilinx/common/xstatus.h  |  347 
> > >>  board/xilinx/common/xversion.c |  350 
> > >>  board/xilinx/common/xversion.h |   97 --
> > >>  board/xilinx/zynq/Makefile |3 -
> > >>  16 files changed, 5865 deletions(-)
> > >>
> > >>
> > >> Do I need to send a newer version?
> > >>
> > >
> > > Tom will probably make you send a newer one anyway.  I'll fix it up
> > > locally and start testing in the mean time.
> > >
> >
> > Allen,
> >
> > I didn't change anything for the version, only removed "RFC" from the
> > subject. I have been there for quite a while. I thought Tom was
> going to
> > pick it up.
> 
> Yeah sorry, I would have re-acked it if I saw there was a new
> version.  Since it no longer applies cleanly I'm pretty sure he'll ask
> you to send a new version that does even if there are no other
> differences.
> 
> Maybe we can talk Simon Glass into testing it out with his super fast
> multi-arch u-boot builder.  It's way fancier than the perl script I
> use.  Adding Simon.
> 
> The patch in question is:
> http://patchwork.ozlabs.org/patch/217088/
> 
> 
> Yes, it needs a rebase, but the change is minor - I hope we can get this
> in. York can you do a rebase?
> 
> Here are the boards that seem to fail: EVB64260 ZUMA EVB64260_750CX P3G4
> 

Thanks, Simon. I will rebase the patch and address those failure.

York



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


Re: [U-Boot] [PATCH] Exynos: uart: s5p: enabling the uart tx/rx fifo

2013-04-01 Thread Simon Glass
On Sun, Mar 31, 2013 at 11:52 PM, Akshay Saraswat wrote:

> Hi Simon,
>
> >Hi Akshay
> >
> >
> >>On Thu, Mar 21, 2013 at 11:33 PM, Akshay Saraswat 
> wrote:
> >>
> >>This patch enables the uart tx/rx fifo. Now that fifo is enabled,
> >>the uart read/write functions are modfied to check the UFSTAT register
> >>for fifo status instead of UTRSTAT (as required with fifo's enabled).
> >>Tested by booting linux kernel. Before enabling tx/rx fifo
> >>"Uncompressing linux" message is garbled and after enabling it is proper.
> >
> >Is this because Linux enables the FIFOs?
> >
> >Anyway this seems fine to me, but I have a question below.
> >
> >>Signed-off-by: Alim Akhtar 
> >>Signed-off-by: Akshay Saraswat 
> >>---
> >> drivers/serial/serial_s5p.c | 13 +
> >> 1 file changed, 9 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
> >>index 3c41242..e65125c 100644
> >>--- a/drivers/serial/serial_s5p.c
> >>+++ b/drivers/serial/serial_s5p.c
> >>@@ -30,6 +30,10 @@
> >>
> >> DECLARE_GLOBAL_DATA_PTR;
> >>
> >>+#define RX_FIFO_COUNT_MASK 0xff
> >>+#define RX_FIFO_FULL_MASK  (1 << 8)
> >>+#define TX_FIFO_FULL_MASK  (1 << 24)
> >>+
> >> static inline struct s5p_uart *s5p_get_base_uart(int dev_index)
> >> {
> >>u32 offset = dev_index * sizeof(struct s5p_uart);
> >>@@ -87,8 +91,8 @@ int serial_init_dev(const int dev_index)
> >> {
> >>struct s5p_uart *const uart = s5p_get_base_uart(dev_index);
> >>
> >>-   /* reset and enable FIFOs, set triggers to the maximum */
> >>-   writel(0, &uart->ufcon);
> >>+   /* enable FIFOs */
> >>+   writel(0x1, &uart->ufcon);
> >>
> >
> >It is odd that you seem to be saying that the old code did not enable
> FIFOs, but this code does? Or should you update your comment?
> >
>
> Actually old comment was inapt because we were resetting FIFO's but not
> enabling FIFO.
> As per manual, for enabling FIFO we need to set LSB of UFCON register,
> which was missing.
> But now we are setting this bit and it works as expected.
> This could be verified by noticing that before applying this patch
> "Uncompressing linux"
> message printed garbled/not readable on console but after applying this
> patch characters
> appear well in place.
> Please suggest if this comment needs edit.
>

This is fine IMO.

Acked-by: Simon Glass 

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


Re: [U-Boot] [PATCH] Add initial support for mx6slevk board

2013-04-01 Thread Vikram Narayanan

On 3/31/2013 2:38 AM, Fabio Estevam wrote:

From: Fabio Estevam 



diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h 
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
new file mode 100644
index 000..cd974d8
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -0,0 +1,1374 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * 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.
+ */
+
+#ifndef __ASM_ARCH_MX6_MX6SL_PINS_H__
+#define __ASM_ARCH_MX6_MX6SL_PINS_H__
+
+#include 
+
+/* Use to set PAD control */
+#define PAD_CTL_HYS(1 << 16)
+#define PAD_CTL_PUS_100K_DOWN  (0 << 14)
+#define PAD_CTL_PUS_47K_UP (1 << 14)
+#define PAD_CTL_PUS_100K_UP(2 << 14)
+#define PAD_CTL_PUS_22K_UP (3 << 14)
+
+#define PAD_CTL_PUE(1 << 13)
+#define PAD_CTL_PKE(1 << 12)
+#define PAD_CTL_ODE(1 << 11)
+#define PAD_CTL_SPEED_LOW  (1 << 6)
+#define PAD_CTL_SPEED_MED  (2 << 6)
+#define PAD_CTL_SPEED_HIGH (3 << 6)
+#define PAD_CTL_DSE_DISABLE(0 << 3)
+#define PAD_CTL_DSE_240ohm (1 << 3)
+#define PAD_CTL_DSE_120ohm (2 << 3)
+#define PAD_CTL_DSE_80ohm  (3 << 3)
+#define PAD_CTL_DSE_60ohm  (4 << 3)
+#define PAD_CTL_DSE_48ohm  (5 << 3)
+#define PAD_CTL_DSE_40ohm  (6 << 3)
+#define PAD_CTL_DSE_34ohm  (7 << 3)
+#define PAD_CTL_SRE_FAST   (1 << 0)
+#define PAD_CTL_SRE_SLOW   (0 << 0)
+


Is the above same for all the variants of i.Mx?
Can we put this into a common header file?


+#define IOMUX_CONFIG_SION 0x10
+#define NO_MUX_I0
+#define NO_PAD_I0
+enum {
+   MX6_PAD_AUD_MCLK__AUDMUX_AUDIO_CLK_OUT  = 
IOMUX_PAD(0x02A4, 0x004C, 0, 0x, 0, 0),
+   MX6_PAD_AUD_MCLK__PWM4_PWMO = 
IOMUX_PAD(0x02A4, 0x004C, 1, 0x, 0, 0),
+   MX6_PAD_AUD_MCLK__ECSPI3_RDY= 
IOMUX_PAD(0x02A4, 0x004C, 2, 0x06B4, 0, 0),
+   MX6_PAD_AUD_MCLK__FEC_MDC   = 
IOMUX_PAD(0x02A4, 0x004C, 3, 0x, 0, 0),


Is the mx6slevk using all the pins defined here?
If not please take off the unused IOMUX pins so that we don't add dead code.

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


[U-Boot] AM3517_EVM, MLO not booting

2013-04-01 Thread James Chandler
Hello,

I am new to *nix/open-source mailing lists, so please provide any feedback 
about my post that would make future posts cleaner or easier to respond to.

I am trying to build the u-boot-arm tree/fork from denx.de (new to git so the 
correct terminology escapes me) for a AM3517_EV LogicPD evaluation board.  I 
cloned the git repository, built the MLO and u-boot.img files and then placed 
them on the first partition of my SD card (fat32, active, correct #of cylinders 
and heads).  When I switch the power on I get two characters on my serial 
console ( the first is a checker-board block from extended ascii of 170ish and 
the other is a 't') and then no output follows.

I am switching to the u-boot-arm tree/fork from the u-boot-am33x tree/fork at 
the Arago project, because the u-boot-am33x code from there doesn't have 
functional fatwrite and ext4write commands (I can build with them in place, but 
fatwrite causes mmc errors and timeout errors while ext4write does not give an 
error but does not create a file).  If I use the MLO from u-boot-am33x but the 
u-boot.img from u-boot-arm, I can boot into the u-boot environment and into 
Linux.  The fatwrite and the ext4write commands on u-boot-arm also work unlike 
those in u-boot-am33x.

I also have a custom board based on the AM3517_EVM (same CPU and RAM just no 
flash).  I copied the AM35117_EVM configuration and board/* files and made only 
changes related to removing flash support (since the custom board does not have 
it) and the custom board does boot using both MLO and u-boot.img from 
u-boot-arm.

Has anyone else had issues with MLO on the AM3517_EVM?  If so, are there any 
workable solutions?

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


Re: [U-Boot] [PATCH] Add initial support for mx6slevk board

2013-04-01 Thread Fabio Estevam
On Mon, Apr 1, 2013 at 2:26 PM, Vikram Narayanan  wrote:

> Is the above same for all the variants of i.Mx?
> Can we put this into a common header file?

Ok, I can try to put this into a common location.

>> +#define IOMUX_CONFIG_SION 0x10
>> +#define NO_MUX_I0
>> +#define NO_PAD_I0
>> +enum {
>> +   MX6_PAD_AUD_MCLK__AUDMUX_AUDIO_CLK_OUT  =
>> IOMUX_PAD(0x02A4, 0x004C, 0, 0x, 0, 0),
>> +   MX6_PAD_AUD_MCLK__PWM4_PWMO =
>> IOMUX_PAD(0x02A4, 0x004C, 1, 0x, 0, 0),
>> +   MX6_PAD_AUD_MCLK__ECSPI3_RDY=
>> IOMUX_PAD(0x02A4, 0x004C, 2, 0x06B4, 0, 0),
>> +   MX6_PAD_AUD_MCLK__FEC_MDC   =
>> IOMUX_PAD(0x02A4, 0x004C, 3, 0x, 0, 0),
>
>
> Is the mx6slevk using all the pins defined here?

No, I put all pins for completion.

> If not please take off the unused IOMUX pins so that we don't add dead code.

I thought it was common practice to provide the complete IOMUX pin file.

Stefano, please advise.

Regards,

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


Re: [U-Boot] Pull request: u-boot-staging

2013-04-01 Thread Tom Rini
On Fri, Mar 29, 2013 at 02:26:15PM +0100, Anatolij Gustschin wrote:

> Hello Tom,
> 
> The following changes since commit 009d75ccc11d27b9a083375a88bb93cb746b4800:
> 
>   Merge branch 'u-boot/master' into 'u-boot-arm/master' (2013-03-28 18:50:01 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-staging.git ag...@denx.de
> 
> Anatolij Gustschin (1):
>   menu: export menu_default_choice() function
> 
> Pali Roh??r (3):
>   menu: Add support for user defined item choice function
>   New command bootmenu: ANSI terminal boot menu support
>   RX-51: Add support for bootmenu
> 
>  board/ait/cam_enc_4xx/cam_enc_4xx.c |3 +-
>  common/Makefile |1 +
>  common/cmd_bootmenu.c   |  517 
> +++
>  common/cmd_pxe.c|3 +-
>  common/menu.c   |   44 +++-
>  doc/README.bootmenu |  115 
>  doc/README.menu |9 +-
>  include/ansi.h  |   42 +++
>  include/configs/nokia_rx51.h|   40 +++-
>  include/menu.h  |5 +-
>  10 files changed, 760 insertions(+), 19 deletions(-)
>  create mode 100644 common/cmd_bootmenu.c
>  create mode 100644 doc/README.bootmenu
>  create mode 100644 include/ansi.h

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 v9 18/30] nand: mxc: Switch NAND SPL to generic SPL

2013-04-01 Thread Albert ARIBAUD
Hi Benoît,

On Mon, 1 Apr 2013 15:13:05 +0200 (CEST), Benoît Thébaudeau
 wrote:

> OK, then it's probably better if I send v10 ASAP. I may not have access to my
> repo before this date, and I have not kept my v9 bundle in my outbox, so can 
> you
> just send me back this bundle please? I will try to send a v10 during this 
> week.

Sent off-list as this bundle is V9 and thus should not be tested by
people, only V10 should.

> Best regards,
> Benoît

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


[U-Boot] [PATCH V4 0/5] ARM: OMAP4/5: Add support to boot with device tree as default

2013-04-01 Thread Sricharan R
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.

Nishanth Menon (1):
  omap5: Allow use of a plain text env file

Sricharan R (4):
  ARM: OMAP5: Rename omap5_evm to omap5_uevm
  ARM: OMAP5: Set fdt_high to enable booting with Device tree
  ARM: OMAP4/5: Change the default boot command to work with device
tree
  ARM: OMAP4/5: Make bootz as the default boot command

 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/omap4_common.h|   22 +---
 include/configs/omap5_common.h|   35 +
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 7 files changed, 50 insertions(+), 9 deletions(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

-- 
1.7.9.5

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


[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-01 Thread Sricharan R
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.

Thanks to Tom Rini  for suggesting this.

Signed-off-by: Sricharan R 
---
[V4] Added environment variables bootdir, bootpart
 and added loadimage, loadfdt commands as per
 Tom's suggestion.

 include/configs/omap4_common.h |   22 +++---
 include/configs/omap5_common.h |   20 +---
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..18cd98f 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +149,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:1\0" \
+   "bootdir=\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -160,12 +168,19 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = panda; then " \
+   "setenv fdtfile omap4-panda-es.dtb; fi\0" \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadbootscript; then " \
@@ -179,7 +194,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt;" \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..24c9ecc 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +148,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:1\0" \
+   "bootdir=\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -159,12 +167,17 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
@@ -177,7 +190,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt; " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

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


[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-04-01 Thread Sricharan R
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.

Acked-by: Nishanth Menon 
Signed-off-by: Sricharan R 
Tested-by: Nishanth Menon 
---
 include/configs/omap4_common.h |4 ++--
 include/configs/omap5_common.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 18cd98f..5ad606e 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:1\0" \
"bootdir=\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -171,7 +171,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 24c9ecc..44c35b1 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:1\0" \
"bootdir=\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -170,7 +170,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
-- 
1.7.9.5

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


[U-Boot] [PATCH V4 3/5] omap5: Allow use of a plain text env file

2013-04-01 Thread Sricharan R
From: Nishanth Menon 

For production systems it is better to use script images since
they are protected by checksums and carry valuable information
like name and timestamp. Also, you can't validate the content
passed to env import.

But for development, it is easier to use the env import command and
plain text files instead of script-images.

Since both OMAP5evm/uevm boards are used primarily for development,
we allow U-Boot to load env var from a text file in case that an
boot.scr script-image is not present.

The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.

Inspired by commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)

Signed-off-by: Sricharan R 
Signed-off-by: Nishanth Menon 
Tested-by: Sricharan R 
---
 include/configs/omap5_common.h |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index f0416df..6d7aa7b 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
+   "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+   "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,9 +169,16 @@
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "fi; " \
+   "if run loadbootenv; then " \
+   "run importbootenv; " \
+   "fi;" \
+   "if test -n ${uenvcmd}; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "fi;" \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
"fi; " \
"fi"
 
-- 
1.7.9.5

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


[U-Boot] [PATCH V4 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm

2013-04-01 Thread Sricharan R
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.

Acked-by: Nishanth Menon 
Signed-off-by: Sricharan R 
Tested-by: Nishanth Menon 
---
 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 5 files changed, 1 insertion(+), 1 deletion(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister  arm armv7   
twister technex
 nokia_rx51   arm armv7   rx51nokia 
 omap3
 omap4_panda  arm armv7   panda   ti
 omap4
 omap4_sdp4430arm armv7   sdp4430 ti
 omap4
-omap5_evmarm armv7   omap5_evm   ti
omap5
+omap5_uevm   arm armv7   omap5_uevm  ti
omap5
 dra7xx_evm  arm armv7   dra7xx  ti 
omap5
 s5p_goni arm armv7   goni
samsungs5pc1xx
 smdkc100 arm armv7   smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.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 V4 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-04-01 Thread Sricharan R
While booting with dt blob, if fdt_high is not set to
0x, the dt blob gets relocated to a high ram address,
which the kernel is not able to use without HIGHMEM.

So set it to 0x to avoid the issue.

Acked-by: Nishanth Menon 
Signed-off-by: Sricharan R 
Tested-by: Nishanth Menon 
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdt_high=0x\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
-- 
1.7.9.5

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


[U-Boot] Potential issue with recent OMAP PRCM struct unification

2013-04-01 Thread Michael Cashwell
Greetings,

I think  or something related to it 
has confused OMAP4 clock init. I haven't entirely unraveled the onion but 
wanted to ping the list to see if this is known or I'm off in the weeds.

Using u-boot master at commit a268170 in DEBUG mode the SPL says (in part):

Enable clock module - 4a008e20
Enable clock module - 4a008e28
Enable clock module - 4a008e40  << later builds omit
Enable clock module - 4a009338  << these two clocks
Enable clock module - 4a004528
Enable clock module - 4a004530
Enable clock module - 4a004538

That build works. But by commit 417c558 the 2 clocks noted are omitted and the 
later call to get_ram_size() hangs.

In tracing this I found that the prcm structure initializes one field 
(cm_l3instr_intrconn_wp1_clkct) but then enable_non_essential_clocks() passes 
an array populated using a different field (cm_l3instr_intrconn_wp1_clkctrl) to 
do_enable_clocks(). That latter uninitialized field is zero which terminates 
that clock init array and results in the two clock omissions above.

Searching for this and leaving out omap5 for clarity I see:

cashwell.ubuntu:u-boot$ rgrep cm_l3instr_intrconn_wp1_clkct | grep -v omap5
./arch/arm/cpu/armv7/omap4/prcm-regs.c: .cm_l3instr_intrconn_wp1_clkct = 
0x4a008e40,
./arch/arm/cpu/armv7/omap4/hw_data.c:   
(*prcm)->cm_l3instr_intrconn_wp1_clkctrl,
./arch/arm/include/asm/omap_common.h:   u32 cm_l3instr_intrconn_wp1_clkctrl;
./arch/arm/include/asm/omap_common.h:   u32 cm_l3instr_intrconn_wp1_clkct;

On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and 
cm_l3instr_intrconn_wp1_clkctrl is a mistake.

If that's true can anyone say which should be eliminated and whether or not the 
order of fields in struct prcm_regs matters?

Thanks,
-Mike Cashwell

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


[U-Boot] [PATCH] OMAP5: Enable USB Ethernet support with LAN9730

2013-04-01 Thread Lubomir Popov
Added the LAN9730 to list of supported devices. This chip is used
in the sEVM, uEVM and som5_evb. Tested on the som5_evb with dhcp
and ping.

Signed-off-by: Lubomir Popov 

---

NOTE: For things to work, 'usb start' must be executed first, and
we must have the Ethernet device found. Otherwise any Ethernet
command shall cause a Data Abort (to be fixed ;) ).

 drivers/usb/eth/smsc95xx.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index fd8f8a7..685702e 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -798,6 +798,7 @@ struct smsc95xx_dongle {
 static const struct smsc95xx_dongle smsc95xx_dongles[] = {
{ 0x0424, 0xec00 }, /* LAN9512/LAN9514 Ethernet */
{ 0x0424, 0x9500 }, /* LAN9500 Ethernet */
+   { 0x0424, 0x9730 }, /* LAN9730 Ethernet (HSIC) */
{ 0x, 0x }  /* END - Do not remove */
 };
 
-- 
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] OMAP4/5: Add USB EHCI support

2013-04-01 Thread Lubomir Popov
Prerequisites (apart from proper config):

1. The HSUSBTLL clock has to be enabled along with the other
   HW_AUTO essentials, that is, cm_l3init_hsusbtll_clkctrl has
   to reside in the clk_modules_hw_auto_essential[] array and
   not in clk_modules_explicit_en_essential[]. Please see
   related patch to hw_data.c.

2. Other functional clocks have to be enabled prior to starting
   USB (and, possibly, disabled upon stopping). The proper place
   for this would be the board file, in the ehci_hcd_init() and
   ehci_hcd_stop() functions. Please see som5_evb.c as example.

3. If we have HSIC devices on some OMAP5 ports, they shall work
   only if the design employs reset capability via GPIO. This is
   performed by the ehci-hcd driver upon applying port power, and
   requires that we have defined CONFIG_OMAP_HSIC_PORTx_RESET_GPIO
   in the board config header as appropriate. Please see
   omap5_som5_evb.h as an example.
   Note that this additional reset is not needed for OMAP4 HSIC
   (tested on OMAP4460 and 4470).

4. Can somebody explain why arch/arm/include/asm/arch-omap5/ehci.h
   has disappeared? It is in fact needed for EHCI USB. Adding it.

Signed-off-by: Lubomir Popov 
---
 arch/arm/include/asm/arch-omap5/ehci.h |   44 +
 drivers/usb/host/ehci-hcd.c|6 +++
 drivers/usb/host/ehci-omap.c   |   83 +---
 drivers/usb/host/ehci.h|9 
 4 files changed, 135 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h

diff --git a/arch/arm/include/asm/arch-omap5/ehci.h 
b/arch/arm/include/asm/arch-omap5/ehci.h
new file mode 100644
index 000..49197f2
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/ehci.h
@@ -0,0 +1,44 @@
+/*
+ * OMAP EHCI port support
+ * Based on LINUX KERNEL
+ * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com*
+ * Author: Govindraj R 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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, see .
+ */
+
+#ifndef _EHCI_H
+#define _EHCI_H
+
+#define OMAP_EHCI_BASE (OMAP54XX_L4_CORE_BASE + 
0x64C00)
+#define OMAP_UHH_BASE  (OMAP54XX_L4_CORE_BASE + 
0x64000)
+#define OMAP_USBTLL_BASE   (OMAP54XX_L4_CORE_BASE + 
0x62000)
+
+/* TLL Register Set */
+#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE(1 << 3)
+#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP(1 << 2)
+#define OMAP_USBTLL_SYSCONFIG_SOFTRESET(1 << 1)
+#define OMAP_USBTLL_SYSCONFIG_CACTIVITY(1 << 8)
+#define OMAP_USBTLL_SYSSTATUS_RESETDONE1
+
+#define OMAP_UHH_SYSCONFIG_SOFTRESET   1
+#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE  (1 << 2)
+#define OMAP_UHH_SYSCONFIG_NOIDLE  (1 << 2)
+#define OMAP_UHH_SYSCONFIG_NOSTDBY (1 << 4)
+
+#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_NOIDLE | \
+   OMAP_UHH_SYSCONFIG_NOSTDBY)
+
+#endif /* _EHCI_H */
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c816878..33d954d 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -750,6 +750,12 @@ ehci_submit_root(struct usb_device *dev, unsigned long 
pipe, void *buffer,
if (HCS_PPC(ehci_readl(&ctrl->hccr->cr_hcsparams))) {
reg |= EHCI_PS_PP;
ehci_writel(status_reg, reg);
+   /*
+* OMAP5: Reset device for 'fail to connect'
+* workaround. Compiled only for OMAP5, and
+* only if we have ports in HSIC mode.
+*/
+   
omap5_ehci_hsic_reset_device(le16_to_cpu(req->index));
}
break;
case USB_PORT_FEAT_RESET:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 086c697..07f3774 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -92,12 +92,15 @@ static void omap_usbhs_hsic_init(int port)
 
 static void omap_ehci_soft_phy_reset(int port)
 {
+   /* This requires proper configs: */
+#if defined(CONFIG_USB_ULPI) && defined(CONFIG_USB_ULPI_VIEWPORT_OMAP)
struct ulpi_viewport u

Re: [U-Boot] Banner -> git co target?

2013-04-01 Thread Tom Rini
On Mon, Apr 01, 2013 at 04:07:56PM +0200, Anatolij Gustschin wrote:
> Hello,
> 
> On Mon, 1 Apr 2013 09:16:06 -0400
> Michael Cashwell  wrote:
> 
> > Greetings,
> > 
> > My u-boot work area got messed up recently when I pulled from master. I'm 
> > having trouble figuring out what's wrong.
> > 
> > I have this banner "U-Boot SPL 2013.04-rc1-00024-ga268170-dirty (Mar 15 
> > 2013 - 10:24:41)" from a recently working state. A corresponding banner 
> > that's broken for me is "U-Boot SPL 2013.04-rc1-00292-g417c558-dirty (Apr 
> > 01 2013 - 08:10:25)"

Note that in both of these cases "-dirty" means that you have
uncommitted local changes.

> > I'd like to go through and methodically compare these two but I can't 
> > figure out what git command would rewind the work area back to a state that 
> > corresponds to a known u-boot banner.
> > 
> > I assume the key bits are "00024-ga268170" but I expect I need a commit ID 
> > or branch name and that doesn't seem to be either.
> > 
> > Any pointers?
> 
> Commit ID is "a268170" (remove 'g'), with 24 new patches committed
> after v2013.04-rc1 tag. So
> 
>   git checkout -b working-state a268170
> 
> should work.

And to try and track things do you can do:
$ git stash save "My changes to do..."
$ git bisect start
$ git bisect good a268170
$ git bisect bad

And then 'git bisect good' or 'git bisect bad' as a particular revision
works or fails.  If you need the local changes to boot your platform,
you can do a git stash pop to apply your local changes on top of the new
rev, build, git stash save (without a "describe the changes string" git
stash still saves your changes, it just doesn't have a helpful a month
later string telling you what you did, just what rev you have stashed
changes on top of).

-- 
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] Banner -> git co target?

2013-04-01 Thread Anatolij Gustschin
Hello,

On Mon, 1 Apr 2013 09:16:06 -0400
Michael Cashwell  wrote:

> Greetings,
> 
> My u-boot work area got messed up recently when I pulled from master. I'm 
> having trouble figuring out what's wrong.
> 
> I have this banner "U-Boot SPL 2013.04-rc1-00024-ga268170-dirty (Mar 15 2013 
> - 10:24:41)" from a recently working state. A corresponding banner that's 
> broken for me is "U-Boot SPL 2013.04-rc1-00292-g417c558-dirty (Apr 01 2013 - 
> 08:10:25)"
> 
> I'd like to go through and methodically compare these two but I can't figure 
> out what git command would rewind the work area back to a state that 
> corresponds to a known u-boot banner.
> 
> I assume the key bits are "00024-ga268170" but I expect I need a commit ID or 
> branch name and that doesn't seem to be either.
> 
> Any pointers?

Commit ID is "a268170" (remove 'g'), with 24 new patches committed
after v2013.04-rc1 tag. So

  git checkout -b working-state a268170

should work.

Thanks,

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


[U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)

2013-04-01 Thread Lubomir Popov
Signed-off-by: Lubomir Popov 

---

The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system
On a Module) designed by MMS and manufactured under license by Jorjin 
Technologies.

 arch/arm/include/asm/mach-types.h   |   13 ++
 board/mms/som5_evb/Makefile |   49 +
 board/mms/som5_evb/s5evb_mux_data.h |  376 +++
 board/mms/som5_evb/som5_evb.c   |  200 +++
 boards.cfg  |1 +
 include/configs/omap5_som5_evb.h|  336 +++
 6 files changed, 975 insertions(+)
 create mode 100644 board/mms/som5_evb/Makefile
 create mode 100644 board/mms/som5_evb/s5evb_mux_data.h
 create mode 100644 board/mms/som5_evb/som5_evb.c
 create mode 100644 include/configs/omap5_som5_evb.h

diff --git a/arch/arm/include/asm/mach-types.h 
b/arch/arm/include/asm/mach-types.h
index a676b6d..236fa17 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
 #define MACH_TYPE_OMAP5_SEVM   3777
 #define MACH_TYPE_ARMADILLO_800EVA 3863
 #define MACH_TYPE_KZM9G4140
+#define MACH_TYPE_SOM5_EVB 4545
 
 #ifdef CONFIG_ARCH_EBSA110
 # ifdef machine_arch_type
@@ -14248,6 +14249,18 @@ extern unsigned int __machine_arch_type;
 # define machine_is_kzm9g()(0)
 #endif
 
+#ifdef CONFIG_MACH_SOM5_EVB
+# ifdef machine_arch_type
+#  undef machine_arch_type
+#  define machine_arch_type __machine_arch_type
+# else
+#  define machine_arch_type MACH_TYPE_SOM5_EVB
+# endif
+# define machine_is_som5_evb()  (machine_arch_type == MACH_TYPE_SOM5_EVB)
+#else
+# define machine_is_som5_evb()  (0)
+#endif
+
 /*
  * These have not yet been registered
  */
diff --git a/board/mms/som5_evb/Makefile b/board/mms/som5_evb/Makefile
new file mode 100644
index 000..248e5cc
--- /dev/null
+++ b/board/mms/som5_evb/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := som5_evb.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+clean:
+   rm -f $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/mms/som5_evb/s5evb_mux_data.h 
b/board/mms/som5_evb/s5evb_mux_data.h
new file mode 100644
index 000..791a4ad
--- /dev/null
+++ b/board/mms/som5_evb/s5evb_mux_data.h
@@ -0,0 +1,376 @@
+/*
+ * Copyright (C) 2013 MM Solutions AD, 
+ *
+ * Lubomir Popov   
+ *
+ * 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 _SOM5_EVB_MUX_DATA_H
+#define _SOM5_EVB_MUX_DATA_H
+
+#include 
+
+const struct pad_conf_entry core_padconf_array_essential[] = {
+
+   {EMMC_CLK, (PTU | IEN | M0)}, /* EMMC_CLK  */
+   {EMMC_CMD, (PTU | IEN | M0)}, /* EMMC_CMD  */
+   {EMMC_DATA0, (PTU | IEN | M0)},   /* EMMC_DATA0*/
+   {EMMC_DATA1, (PTU | IEN | M0)},   /* EMMC_DATA1*/
+   {EMMC_DATA2, (PTU | IEN | M0)},   /* EMMC_DATA2*/

[U-Boot] [PATCH] OMAP5: Power: Added more functionality to twl6035 driver

2013-04-01 Thread Lubomir Popov
Signed-off-by: Lubomir Popov 

---

This patch adds some new functions that were used for the SOM5_EVB bringup,
but might be useful for other OMAP5 designs as well.

 drivers/power/twl6035.c |  140 +++
 include/twl6035.h   |   83 ++--
 2 files changed, 206 insertions(+), 17 deletions(-)

diff --git a/drivers/power/twl6035.c b/drivers/power/twl6035.c
index d3de698..5fc517b 100644
--- a/drivers/power/twl6035.c
+++ b/drivers/power/twl6035.c
@@ -2,6 +2,8 @@
  * (C) Copyright 2012
  * Texas Instruments, 
  *
+ * 02/2013 Modified by Lubomir Popov 
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -21,9 +23,12 @@
  * MA 02111-1307 USA
  */
 #include 
+
+#ifdef CONFIG_TWL6035_POWER
+
 #include 
 
-/* Functions to read and write from TWL6030 */
+/* Functions to read and write from TWL6035 */
 int twl6035_i2c_write_u8(u8 chip_no, u8 val, u8 reg)
 {
return i2c_write(chip_no, reg, 1, &val, 1);
@@ -47,28 +52,141 @@ static inline int palmas_read_u8(u8 chip_no, u8 reg, u8 
*val)
 
 void twl6035_init_settings(void)
 {
-   return;
+#ifdef CONFIG_TWL6035_SMPS7_FPWM
+   int err;
+   /* Set SMPS7 (1.8 V I/O supply) to forced PWM mode */
+   u8 val = SMPS_MODE_SLP_FPWM | SMPS_MODE_ACT_FPWM;
+   if ((err = palmas_write_u8(TWL6035_CHIP_P1, SMPS7_CTRL, val)))
+   printf("twl6035: Could not force PWM for SMPS7: err = %d\n", 
err);
+#endif
+}
+
+/* On some hardware the SD card socket and LDO9_IN are powered by an
+ * external 3.3 V regulator. Therefore VDDS_SDCARD should be 3.3 V
+ * as well for 3 V cards. This requires that LDO9 is set to 'bypass'
+ * mode for such cases.
+ *
+ * NOTE: Switching LDOs between the 0.9 - 2.1 V and 2.15 - 3.3 V ranges
+ *   cannot be done on the fly and requires restart (off - change
+ *   voltage - on). This should be taken care of at a higher level.
+ */
+int twl6035_mmc1_set_ldo9(u8 vsel)
+{
+   u8 cval=0, vval=0;  /* Off by default */
+   int err;
+
+   if (vsel) {
+   /* Turn on */
+   if (vsel > LDO_VOLT_3V3) {
+   /* Put LDO9 in bypass */
+   cval = LDO9_BYP_EN | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+   vval = LDO_VOLT_3V3;
+   }
+   else {
+   cval = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+   vval = vsel & 0x3f;
+   }
+   }
+   if ((err = palmas_write_u8(TWL6035_CHIP_P1, LDO9_VOLTAGE, vval))) {
+   printf("twl6035: could not set LDO9 %s: err = %d\n", 
+   vsel > LDO_VOLT_3V3 ? "bypass" : "voltage", err);
+   return err;
+   }
+   if ((err = palmas_write_u8(TWL6035_CHIP_P1, LDO9_CTRL, cval)))
+   printf("twl6035: could not turn on LDO9: err = %d\n", err);
+   return err;
 }
 
 int twl6035_mmc1_poweron_ldo(void)
 {
u8 val = 0;
 
-   /* set LDO9 TWL6035 to 3V */
-   val = 0x2b; /* (3 -.9)*28 +1 */
-
-   if (palmas_write_u8(0x48, LDO9_VOLTAGE, val)) {
+   /* Set TWL6035 LDO9 to 3.0 V */
+   val = LDO_VOLT_3V0;
+   if (palmas_write_u8(TWL6035_CHIP_P1, LDO9_VOLTAGE, val)) {
printf("twl6035: could not set LDO9 voltage.\n");
return 1;
}
-
/* TURN ON LDO9 */
-   val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
-
-   if (palmas_write_u8(0x48, LDO9_CTRL, val)) {
+   val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+   if (palmas_write_u8(TWL6035_CHIP_P1, LDO9_CTRL, val)) {
printf("twl6035: could not turn on LDO9.\n");
return 1;
}
-
return 0;
 }
+
+int twl6035_usb_poweron_ldo(void)
+{
+   u8 val = 0;
+   int err;
+
+   /* Enable external VCC_3v3_AUX supply on the sEVM (SYSEN2) */
+   val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+   if ((err = palmas_write_u8(TWL6035_CHIP_P1, SYSEN2_CTRL, val))) {
+   printf("twl6035: could not set SYSEN2: err = %d\n", err);
+   return err;
+   }
+
+   /* TURN ON LDO's needed */
+
+   /* Set LDOUSB to 3.3 V */
+   val = LDO_VOLT_3V3;
+   if ((err = palmas_write_u8(TWL6035_CHIP_P1, LDOUSB_VOLTAGE, val))) {
+   printf("twl6035: could not set LDOUSB voltage: err = %d\n", 
err);
+   return err;
+   }
+
+   /* Enable LDOUSB */
+val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+   if ((err = palmas_write_u8(TWL6035_CHIP_P1, LDOUSB_CTRL, val)))
+   printf("twl6035: could not turn on LDOUSB: err = %d\n", err);
+   return err;
+}
+
+/* Turn audio codec power and 32 kHz clock on/off
+ */
+int twl6035_audio_power(u8 on)
+{
+   u8 cval=0, vval=0, c32k=0;
+   int err;
+
+   if (on) {
+   vval = SMPS_VOLT_2V1;
+   cval = SMPS_MODE_SLP_AUTO | SMPS_MODE_ACT_AUTO;
+   c32k = RSC_MODE_SLEEP | RSC_MODE

Re: [U-Boot] [PATCH v9 18/30] nand: mxc: Switch NAND SPL to generic SPL

2013-04-01 Thread Benoît Thébaudeau
Hi Albert,

On Monday, April 1, 2013 10:26:21 AM, Albert ARIBAUD wrote:
> Hi Benoît,
> 
> On Mon, 1 Apr 2013 02:30:00 +0200 (CEST), Benoît Thébaudeau
>  wrote:
> 
> > Hi Albert,
> > 
> > On Sunday, March 31, 2013 7:30:24 PM, Albert ARIBAUD wrote:
> > > Hi Benoît,
> > > 
> > > I have managed to rebase your patch series and have tested it over the
> > > ARM targets. This particular patch was the only one to cause an issue,
> > > and an amusing one at that:
> > > 
> > > On Wed,  6 Mar 2013 19:59:24 +0100, Benoît Thébaudeau
> > >  wrote:
> > > 
> > > > This also fixes support for mx31pdk and tx25, which had been broken by
> > > > commit
> > > > e05e5de7fae5bec79617e113916dac6631251156.
> > > 
> > > Both boards actually build fine with e05e5de7fae (and have built
> > > fine since, at least in all of the routine ARM-wide builds I do as the
> > > ARM custodian and where I accept zero build failures or warnings).
> > 
> > Yes, for me too. This was not a build issue, but a runtime one.
> > 
> > > And both boards actually do not build at all with this patch :) and die
> > > with the same error:
> > > 
> > > .../spl/u-boot-spl.lds:45: non constant or forward reference address
> > > expression for section .bss
> > > 
> > > In both case I have double-checked this using Ubuntu's gcc version
> > > 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1) or ELDK 5.3's gcc version 4.7.2
> > > (GCC).
> > 
> > OK. That worked fine for me and Fabio at the time I issued the v9, so it
> > can be
> > the rebase, or something that changed in mainline in the meantime, or the
> > toolchain. According to your tests, it's very unlikely that the toolchain
> > is
> > involved.
> > 
> > I've looked at the Git history, and the guilty commit is 3ebd1cb. But
> > thanks to
> > commit 65cdd64, this build issue should be easily solved by replacing:
> > +#define CONFIG_SPL_LDSCRIPT"arch/$(ARCH)/cpu/u-boot.lds"
> > with:
> > +#define CONFIG_SPL_LDSCRIPT"arch/$(ARCH)/cpu/u-boot-spl.lds"
> > in both mx31pdk.h and tx25.h.
> > 
> > Can you please retest with this change?
> 
> Patch 18/30 amended with this change and testing done; all ARM boards
> build fine now.

Thanks for testing that.

> > This line could even be dropped from tx25.h since there is no arm926ejs SPL
> > linker script obstructing the default assignment, contrary to arm1136 for
> > mx31pdk, but that would be risky if such a linker script is added later.
> > 
> > Is it still OK for the release if I send v10 on April 8 as I said (so just
> > with
> > the rebase including the change above if you confirm that everything is OK
> > like
> > that)?
> 
> You have Scott's acked-by for the NAND parts, and Tom's reviewed-by is
> proof enough for me that he is ok with the few non-ARM-only patches,
> so the patch series in itself is fine (assuming v10 is identical to
> v9 as I rebased it).
> 
> I would just like some reports that boards (mx31pdk and tx25 especially,
> but others too, including a few non-ARM to make sure) have no issue
> running v10.

OK, then it's probably better if I send v10 ASAP. I may not have access to my
repo before this date, and I have not kept my v9 bundle in my outbox, so can you
just send me back this bundle please? I will try to send a v10 during this week.

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


[U-Boot] Banner -> git co target?

2013-04-01 Thread Michael Cashwell
Greetings,

My u-boot work area got messed up recently when I pulled from master. I'm 
having trouble figuring out what's wrong.

I have this banner "U-Boot SPL 2013.04-rc1-00024-ga268170-dirty (Mar 15 2013 - 
10:24:41)" from a recently working state. A corresponding banner that's broken 
for me is "U-Boot SPL 2013.04-rc1-00292-g417c558-dirty (Apr 01 2013 - 08:10:25)"

I'd like to go through and methodically compare these two but I can't figure 
out what git command would rewind the work area back to a state that 
corresponds to a known u-boot banner.

I assume the key bits are "00024-ga268170" but I expect I need a commit ID or 
branch name and that doesn't seem to be either.

Any pointers?

Thanks,
-Mike Cashwell

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


Re: [U-Boot] [PATCH v4 0/3] i.MX6 SabreSD and SabreAUTO bmode support

2013-04-01 Thread Otavio Salvador
On Mon, Apr 1, 2013 at 9:42 AM, Fabio Estevam  wrote:
> On Wed, Mar 20, 2013 at 9:36 AM, Otavio Salvador
>  wrote:
>> On Fri, Mar 15, 2013 at 9:05 AM, Otavio Salvador
>>  wrote:
>>>
>>> This adds the bmode support for i.MX6 SabreSD and SabreAUTO
>>> boards. This allows user to choose the boot mode at runtime making it
>>> easy to boot from USB or other media.
>>
>> Fabio, can you give it a try?
>
> Tested on a mx6qsabreauto, though there is only one mmc port currently
> supported in this board.
>
> Tested-by: Fabio Estevam 

Stefano, could you please review these?

--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 0/3] i.MX6 SabreSD and SabreAUTO bmode support

2013-04-01 Thread Fabio Estevam
On Wed, Mar 20, 2013 at 9:36 AM, Otavio Salvador
 wrote:
> On Fri, Mar 15, 2013 at 9:05 AM, Otavio Salvador
>  wrote:
>>
>> This adds the bmode support for i.MX6 SabreSD and SabreAUTO
>> boards. This allows user to choose the boot mode at runtime making it
>> easy to boot from USB or other media.
>
> Fabio, can you give it a try?

Tested on a mx6qsabreauto, though there is only one mmc port currently
supported in this board.

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


Re: [U-Boot] [PATCH 1/3 V4] EXYNOS5: Add gpio pin numbering feature

2013-04-01 Thread Minkyu Kang
On 21/03/13 20:33, Rajeshwari Shinde wrote:
> This patch adds support for gpio pin numbering support on
> EXYNOS5250
> To have consistent 0..n-1 GPIO numbering the banks are divided
> into different parts where ever they have holes in them.
> 
> Signed-off-by: Leela Krishna Amudala 
> Signed-off-by: Rajeshwari Shinde 
> ---
> Changes in V2:
> - none.
> Changes in V3:
> - none.
> Changes in V4:
>   - To have consistent 0..n-1 GPIO numbering the banks are divided
>   into different parts where ever they have holes in them.
>   - Combined previous patch 1 and 2 into single patch.
>  arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +---
>  arch/arm/include/asm/arch-exynos/cpu.h  |   10 +-
>  arch/arm/include/asm/arch-exynos/gpio.h |  376 
> ++-
>  board/samsung/smdk5250/smdk5250.c   |   24 +--
>  drivers/gpio/s5p_gpio.c |   65 ++-
>  5 files changed, 508 insertions(+), 115 deletions(-)
> 
> diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
> index 656bf4a..1b882cb 100644
> --- a/drivers/gpio/s5p_gpio.c
> +++ b/drivers/gpio/s5p_gpio.c
> @@ -36,6 +36,27 @@
>  #define RATE_MASK(x) (0x1 << (x + 16))
>  #define RATE_SET(x)  (0x1 << (x + 16))
>  
> +
> +struct gpio_info {
> + unsigned int reg_addr;  /* Address of register for this part */
> + unsigned int max_gpio;  /* Maximum GPIO in this part */
> +};
> +
> +#ifdef CONFIG_EXYNOS5

I think, this ifdef is unnecessary.

> +static const struct gpio_info gpio_data[EXYNOS5_GPIO_NUM_PARTS] = {

maybe it should be exynos5_gpio_data?

> + { EXYNOS5_GPIO_PART1_BASE, EXYNOS5_GPIO_MAX_PORT_PART_1 },
> + { EXYNOS5_GPIO_PART2_BASE, EXYNOS5_GPIO_MAX_PORT_PART_2 },
> + { EXYNOS5_GPIO_PART3_BASE, EXYNOS5_GPIO_MAX_PORT_PART_3 },
> + { EXYNOS5_GPIO_PART4_BASE, EXYNOS5_GPIO_MAX_PORT_PART_4 },
> + { EXYNOS5_GPIO_PART5_BASE, EXYNOS5_GPIO_MAX_PORT_PART_5 },
> + { EXYNOS5_GPIO_PART6_BASE, EXYNOS5_GPIO_MAX_PORT_PART_6 },
> + { EXYNOS5_GPIO_PART7_BASE, EXYNOS5_GPIO_MAX_PORT_PART_7 },
> + { EXYNOS5_GPIO_PART8_BASE, EXYNOS5_GPIO_MAX_PORT },
> +};
> +
> +#define HAVE_GENERIC_GPIO
> +#endif
> +
>  void s5p_gpio_cfg_pin(struct s5p_gpio_bank *bank, int gpio, int cfg)
>  {
>   unsigned int value;
> @@ -141,7 +162,30 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int 
> gpio, int mode)
>  
>   writel(value, &bank->drv);
>  }
> -
> +#ifdef HAVE_GENERIC_GPIO
> +static struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned int gpio)

please consider exynos4 also.

> +{
> + const struct gpio_info *data;
> + unsigned int upto;
> + int i;
> +
> + for (i = upto = 0, data = gpio_data; i < EXYNOS5_GPIO_NUM_PARTS;
> + i++, upto = data->max_gpio, data++) {
> + debug("i=%d, upto=%d\n", i, upto);
> + if (gpio < data->max_gpio) {
> + struct s5p_gpio_bank *bank;
> + bank = (struct s5p_gpio_bank *)data->reg_addr;
> + bank += (gpio - upto) / GPIO_PER_BANK;
> + debug("   gpio=%d, bank=%p\n", gpio, bank);
> + return bank;
> + }
> + }
> +#ifndef CONFIG_SPL_BUILD
> + assert(gpio < EXYNOS5_GPIO_MAX_PORT);   /* ...which it will not be */
> +#endif
> + return NULL;
> +}
> +#else
>  struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio)
>  {
>   int bank;
> @@ -151,6 +195,7 @@ struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio)
>   bank *= sizeof(struct s5p_gpio_bank);
>   return (struct s5p_gpio_bank *) (s5p_gpio_base(gpio) + bank);
>  }
> +#endif
>  
>  int s5p_gpio_get_pin(unsigned gpio)
>  {
> @@ -196,3 +241,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);
> +}
> 

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


Re: [U-Boot] [PATCH V7 10/10] EXYNOS5: I2C: Added FDT and non-FDT support for I2C

2013-04-01 Thread Minkyu Kang
On 01/04/13 20:37, Amarendra Reddy wrote:
> Dear Minkyu,
> 
> While creating the separate file(exynos5-dt.c) to handle dts, I had to do the 
> changes for i2c also. And those changes became part of this patchset.
> 
> Ok, I will separate this from the dwmmc patchset.

OK. thanks.

btw, I've requested to you so many times..
"please don't top posting when replying".

> 
> Thanks & Regards
> Amarendra
> 
> 
> On 28 March 2013 13:59, Minkyu Kang  > wrote:
> 
> Dear Amar,
> 
> On 05/03/13 22:11, Amar wrote:
> > This patch adds FDT and non-FDT support for I2C, and initialise
> > the I2C channels.
> >
> > Signed-off-by: Amar  >
> > ---
> > Changes since V4:
> >   New patch.
> >
> > Changes since V5:
> >   1)Removed the function call i2c_init() present inside the
> >   function board_i2c_init().
> >
> > Changes since V6:
> >   No change.
> >
> >  drivers/i2c/s3c24x0_i2c.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> 
> I think, this patch should separate from this patchset.
> Why you this add this "i2c" patch to
> "EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot"?
> 
> Thanks,
> Minkyu Kang.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de 
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 


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


Re: [U-Boot] [PATCH V7 10/10] EXYNOS5: I2C: Added FDT and non-FDT support for I2C

2013-04-01 Thread Amarendra Reddy
Dear Minkyu,

While creating the separate file(exynos5-dt.c) to handle dts, I had to do
the changes for i2c also. And those changes became part of this patchset.

Ok, I will separate this from the dwmmc patchset.

Thanks & Regards
Amarendra


On 28 March 2013 13:59, Minkyu Kang  wrote:

> Dear Amar,
>
> On 05/03/13 22:11, Amar wrote:
> > This patch adds FDT and non-FDT support for I2C, and initialise
> > the I2C channels.
> >
> > Signed-off-by: Amar 
> > ---
> > Changes since V4:
> >   New patch.
> >
> > Changes since V5:
> >   1)Removed the function call i2c_init() present inside the
> >   function board_i2c_init().
> >
> > Changes since V6:
> >   No change.
> >
> >  drivers/i2c/s3c24x0_i2c.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
>
> I think, this patch should separate from this patchset.
> Why you this add this "i2c" patch to
> "EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot"?
>
> Thanks,
> Minkyu Kang.
> ___
> 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 V7 08/10] SMDK5250: Enable EMMC booting

2013-04-01 Thread Amarendra Reddy
Dear Minkyu,
Ok, I will keep these valuse locally.

Thanks & Regards
Amarendra Reddy


On 28 March 2013 13:53, Minkyu Kang  wrote:

> Dear Amar,
>
> On 05/03/13 22:11, Amar wrote:
> > This patch adds support for EMMC booting on SMDK5250.
> >
> > Signed-off-by: Amar 
> > Acked-by: Simon Glass 
> > ---
> > Changes since V1:
> >   1)Updated spl_boot.c file to maintain irom pointer table
> >   instead of using the #define values defined in header file.
> >
> > Changes since V2:
> >   1)Updation of commit message and resubmition of proper patch set.
> >
> > Changes since V3:
> >   No change.
> >
> > Changes since V4:
> >   1)The function get_irom_func(int index) has been added to avoid
> >   type casting at many places.
> >   2)The changes to file arch/arm/include/asm/arch-exynos/clk.h are
> >   included in this patch file.
> >
> > Changes since V5:
> >   No change.
> >
> > Changes since V6:
> >   No change.
> >
> >  arch/arm/include/asm/arch-exynos/clk.h |  3 ++
> >  board/samsung/smdk5250/clock_init.c| 15 ++
> >  board/samsung/smdk5250/clock_init.h|  5 
> >  board/samsung/smdk5250/spl_boot.c  | 52
> ++
> >  4 files changed, 69 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-exynos/clk.h
> b/arch/arm/include/asm/arch-exynos/clk.h
> > index 1935b0b..a4d5b4e 100644
> > --- a/arch/arm/include/asm/arch-exynos/clk.h
> > +++ b/arch/arm/include/asm/arch-exynos/clk.h
> > @@ -29,6 +29,9 @@
> >  #define VPLL 4
> >  #define BPLL 5
> >
> > +#define FSYS1_MMC0_DIV_MASK  0xff0f
> > +#define FSYS1_MMC0_DIV_VAL   0x0701
>
> I think, these values are not generic.
> please keep these values locally.
>
> > +
> >  unsigned long get_pll_clk(int pllreg);
> >  unsigned long get_arm_clk(void);
> >  unsigned long get_i2c_clk(void);
> > diff --git a/board/samsung/smdk5250/clock_init.c
> b/board/samsung/smdk5250/clock_init.c
> > index c009ae5..154993c 100644
> > --- a/board/samsung/smdk5250/clock_init.c
> > +++ b/board/samsung/smdk5250/clock_init.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "clock_init.h"
> >  #include "setup.h"
> > @@ -664,3 +665,17 @@ void clock_init_dp_clock(void)
> >   /* We run DP at 267 Mhz */
> >   setbits_le32(&clk->div_disp1_0, CLK_DIV_DISP1_0_FIMD1);
> >  }
> > +
> > +/*
> > + * Set clock divisor value for booting from EMMC.
> > + * Set DWMMC channel-0 clk div to operate mmc0 device at 50MHz.
> > + */
> > +void emmc_boot_clk_div_set(void)
> > +{
> > + struct exynos5_clock *clk = (struct exynos5_clock
> *)EXYNOS5_CLOCK_BASE;
> > + unsigned int div_mmc;
> > +
> > + div_mmc = readl((unsigned int) &clk->div_fsys1) &
> ~FSYS1_MMC0_DIV_MASK;
> > + div_mmc |= FSYS1_MMC0_DIV_VAL;
> > + writel(div_mmc, (unsigned int) &clk->div_fsys1);
> > +}
> > diff --git a/board/samsung/smdk5250/clock_init.h
> b/board/samsung/smdk5250/clock_init.h
> > index f751bcb..20a1d47 100644
> > --- a/board/samsung/smdk5250/clock_init.h
> > +++ b/board/samsung/smdk5250/clock_init.h
> > @@ -146,4 +146,9 @@ struct mem_timings *clock_get_mem_timings(void);
> >   * Initialize clock for the device
> >   */
> >  void system_clock_init(void);
> > +
> > +/*
> > + * Set clock divisor value for booting from EMMC.
> > + */
> > +void emmc_boot_clk_div_set(void);
> >  #endif
> > diff --git a/board/samsung/smdk5250/spl_boot.c
> b/board/samsung/smdk5250/spl_boot.c
> > index d8f3c1e..4ddbd4a 100644
> > --- a/board/samsung/smdk5250/spl_boot.c
> > +++ b/board/samsung/smdk5250/spl_boot.c
> > @@ -23,15 +23,42 @@
> >  #include
> >  #include
> >
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "clock_init.h"
> > +
> > +/* Index into irom ptr table */
> > +enum index {
> > + MMC_INDEX,
> > + EMMC44_INDEX,
> > + EMMC44_END_INDEX,
> > + SPI_INDEX,
> > +};
> > +
> > +/* IROM Function Pointers Table */
> > +u32 irom_ptr_table[] = {
> > + [MMC_INDEX] = 0x02020030,   /* iROM Function Pointer-SDMMC
> boot */
> > + [EMMC44_INDEX] = 0x02020044,/* iROM Function Pointer-EMMC4.4
> boot*/
> > + [EMMC44_END_INDEX] = 0x02020048,/* iROM Function Pointer
> > + -EMMC4.4 end boot
> operation */
> > + [SPI_INDEX] = 0x02020058,   /* iROM Function Pointer-SPI boot
> */
> > + };
> > +
> >  enum boot_mode {
> >   BOOT_MODE_MMC = 4,
> >   BOOT_MODE_SERIAL = 20,
> > + BOOT_MODE_EMMC = 8, /* EMMC4.4 */
> >   /* Boot based on Operating Mode pin settings */
> >   BOOT_MODE_OM = 32,
> >   BOOT_MODE_USB,  /* Boot using USB download */
> >  };
> >
> > - typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
> > +void *get_irom_func(int index)
> > +{
> > + return (void *) *(u32 *)irom_ptr_table[index];
> > +}
> >
> >  /*
> >  * Copy U-boot from mmc to RAM:
> > @@ -40,23 +67,36 @@ enum boot_mode {
> >  */
> >  void copy_uboot_to_ram(void)
> > 

Re: [U-Boot] [PATCH] Exynos5: i2c: Fix read NACK handling and remove some redundancy

2013-04-01 Thread Minkyu Kang
On 25/03/13 20:46, Akshay Saraswat wrote:
> From: Gabe Black 
> 
> The exynos s3c24x0 i2c driver wouldn't do the right thing when a NACK was
> received on a read because it didn't attempt a read before waiting for the
> read to finish. Putting a call to ReadWriteByte in the NACK path fixed a
> problem where getting a NACK reading from a device would jam up the bus and
> prevent future accesses like probing from working.
> 
> Because other than the ReadWriteByte call the NACK and normal paths were
> almost the same thing, and to avoid future instances of the NACK path not
> working because it's not exercised normally, this change also consolidates
> those two paths.
> 
> Signed-off-by: Gabe Black 
> Signed-off-by: Akshay Saraswat 
> ---
>  drivers/i2c/s3c24x0_i2c.c | 53 
> ---
>  1 file changed, 18 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
> index d2b4eb0..91298a7 100644
> --- a/drivers/i2c/s3c24x0_i2c.c
> +++ b/drivers/i2c/s3c24x0_i2c.c
> @@ -366,21 +366,25 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
>   break;
>  
>   case I2C_READ:
> - if (result == I2C_OK) {
> - writel(I2C_MODE_MR | I2C_TXRX_ENA, &i2c->iicstat);
> - writel(chip, &i2c->iicds);
> - /* send START */
> - writel(readl(&i2c->iicstat) | I2C_START_STOP,
> -&i2c->iicstat);
> - ReadWriteByte(i2c);
> - result = WaitForXfer(i2c);
> + {
> + int was_ok = (result == I2C_OK);

do you really need the was_ok?
If not, please remove it.

> +
> + writel(chip, &i2c->iicds);
> + /* resend START */
> + writel(I2C_MODE_MR | I2C_TXRX_ENA |
> + I2C_START_STOP, &i2c->iicstat);
> + ReadWriteByte(i2c);
> + result = WaitForXfer(i2c);
> +
> + if (was_ok || IsACK(i2c)) {
>   i = 0;
>   while ((i < data_len) && (result == I2C_OK)) {
>   /* disable ACK for final READ */
> - if (i == data_len - 1)
> - writel(readl(&i2c->iiccon)
> - & ~I2CCON_ACKGEN,
> - &i2c->iiccon);
> + if (i == data_len - 1) {
> + writel(readl(&i2c->iiccon) &
> +   ~I2CCON_ACKGEN,
> +   &i2c->iiccon);
> + }
>   ReadWriteByte(i2c);
>   result = WaitForXfer(i2c);
>   data[i] = readl(&i2c->iicds);
> @@ -388,35 +392,14 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
>   }
>  
>   } else {
> - writel(I2C_MODE_MR | I2C_TXRX_ENA, &i2c->iicstat);
> - writel(chip, &i2c->iicds);
> - /* send START */
> - writel(readl(&i2c->iicstat) | I2C_START_STOP,
> -&i2c->iicstat);
> - result = WaitForXfer(i2c);
> -
> - if (IsACK(i2c)) {
> - i = 0;
> - while ((i < data_len) && (result == I2C_OK)) {
> - /* disable ACK for final READ */
> - if (i == data_len - 1)
> - writel(readl(&i2c->iiccon) &
> - ~I2CCON_ACKGEN,
> - &i2c->iiccon);
> - ReadWriteByte(i2c);
> - result = WaitForXfer(i2c);
> - data[i] = readl(&i2c->iicds);
> - i++;
> - }
> - } else {
> - result = I2C_NACK;
> - }
> + result = I2C_NACK;
>   }
>  
>   /* send STOP */
>   writel(I2C_MODE_MR | I2C_TXRX_ENA, &i2c->iicstat);
>   ReadWriteByte(i2c);
>   break;
> + }
>  
>   default:
>   debug("i2c_transfer: bad call\n");
> 

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


Re: [U-Boot] [PATCH 00/11 v3] Fix and Re-organise PWM Timer

2013-04-01 Thread Minkyu Kang
On 01/04/13 13:42, Akshay Saraswat wrote:
> Hi Minkyu,
> 
>> Dear Akshay,
>>
>> On 28/03/13 23:32, Akshay Saraswat wrote:
>>> This patch set tries to fix few bugs in timer and re-organises PWM
>>> clock code.
>>>
>>> Changes since v2:
>>> - Patch-1: New patch.
>>> - Patch-2: None.
>>> - Patch-3: None.
>>> - Patch-4: None.
>>> - Patch-5: Fixed typo paremters in commit message.
>>> - Patch-6: None.
>>> - Patch-7: Added "Acked-by: Simon Glass".
>>> - Patch-8:
>>>  Fixed typo peripherial to peripheral.
>>> - Made exynos5_get_periph_rate static.
>>> - Added an empty line.
>>> - Replaced "enum periph_id" with "int" in function arguments.
>>> - Removed "#include " from clk.h.
>>> - Added "Acked-by: Simon Glass".
>>> - Patch-9: None.
>>> - Patch-10:
>>> - Replaced "exynos5_get_pwm_clk" with 
>>> "clock_get_periph_rate" in get_pwm_clk
>>>   instead of replacing everywhere.
>>> - Added "Acked-by: Simon Glass".
>>> - Patch-11: New patch.
>>>
>>> Changes since v1:
>>> - Patch-1: Added "Acked-by: Simon Glass".
>>> - Patch-2: Added "Acked-by: Simon Glass".
>>> - Patch-3: Added "Acked-by: Simon Glass".
>>> - Patch-4: Added "Acked-by: Simon Glass".
>>> - Patch-5: Added "Acked-by: Simon Glass".
>>> - Patch-6: None.
>>> - Patch-7: Fixed few nits.
>>> - Patch-8: Added "Acked-by: Simon Glass".
>>> - Patch-9: Restored get_pwm_clk call in case of non-exynos5 cpu.
>>>
>>> Akshay Saraswat (11):
>>>   Exynos5: config: enable time command
>>>   Exynos: Change get_timer() to work correctly
>>>   Exynos: Add timer_get_us function
>>>   Exynos: pwm: Fix two bugs in the exynos pwm  configuration code
>>>   Exynos: Avoid a divide by zero by specifying a non-zero  period
>>> for pwm 4
>>>   Exynos: Tidy up the pwm_config function in the exynos  pwm driver
>>>   Exynos: Add peripherial id for pwm
>>>   Exynos: clock: Add generic api to get the clk freq
>>>   Exynos: clock: Correct pwm source clk selection
>>>   Exynos: pwm: Use generic api to get pwm clk freq
>>>   Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk
>>>
>>>  arch/arm/cpu/armv7/exynos/clock.c | 167 
>>> ++
>>>  arch/arm/cpu/armv7/s5p-common/pwm.c   |  42 
>>>  arch/arm/cpu/armv7/s5p-common/timer.c | 117 ++---
>>>  arch/arm/include/asm/arch-exynos/clk.h|  15 +++
>>>  arch/arm/include/asm/arch-exynos/periph.h |   5 +
>>>  board/samsung/smdk5250/setup.h|   2 +-
>>>  include/configs/exynos5250-dt.h   |   3 +
>>>  7 files changed, 244 insertions(+), 107 deletions(-)
>>>
>>
>> The patch-7 seems to did not reached at mailing list.
>> If not, please let me know a link of patchwork.
>>
>> Thanks,
>> Minkyu Kang.
>>
> 
> I am sorry. I don't know how come this patch was left when the whole
> set was posted. I am posting patch-7 now. Please consider it.
> 
> Thanks & Regards,
> Akshay Saraswat
> 

applied to u-boot-samsung.

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


[U-Boot] [PATCH v1] bf609: add SPI register base address

2013-04-01 Thread Sonic Zhang
From: Scott Jiang 

- BF609 spi driver depend on this.

Signed-off-by: Scott Jiang 
Signed-off-by: Sonic Zhang 
---
 arch/blackfin/include/asm/mach-bf609/BF609_def.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/blackfin/include/asm/mach-bf609/BF609_def.h 
b/arch/blackfin/include/asm/mach-bf609/BF609_def.h
index 4d3b003..02b81d3 100644
--- a/arch/blackfin/include/asm/mach-bf609/BF609_def.h
+++ b/arch/blackfin/include/asm/mach-bf609/BF609_def.h
@@ -128,6 +128,9 @@
 #define EMAC0_MACCFG  0xFFC2 /* EMAC0 MAC Configuration Register */
 #define EMAC1_MACCFG  0xFFC22000 /* EMAC1 MAC Configuration Register */
 
+#define SPI0_REGBASE  0xFFC40400 /* SPI0 Base Address */
+#define SPI1_REGBASE  0xFFC40500 /* SPI1 Base Address */
+
 #define DMA10_DSCPTR_NXT  0xFFC05000 /* DMA10 Pointer to Next Initial Desc */
 #define DMA10_ADDRSTART   0xFFC05004 /* DMA10 Start Address of Current Buf */
 #define DMA10_CFG 0xFFC05008 /* DMA10 Configuration Register */
-- 
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 v9 18/30] nand: mxc: Switch NAND SPL to generic SPL

2013-04-01 Thread Albert ARIBAUD
Hi Benoît,

On Mon, 1 Apr 2013 02:30:00 +0200 (CEST), Benoît Thébaudeau
 wrote:

> Hi Albert,
> 
> On Sunday, March 31, 2013 7:30:24 PM, Albert ARIBAUD wrote:
> > Hi Benoît,
> > 
> > I have managed to rebase your patch series and have tested it over the
> > ARM targets. This particular patch was the only one to cause an issue,
> > and an amusing one at that:
> > 
> > On Wed,  6 Mar 2013 19:59:24 +0100, Benoît Thébaudeau
> >  wrote:
> > 
> > > This also fixes support for mx31pdk and tx25, which had been broken by
> > > commit
> > > e05e5de7fae5bec79617e113916dac6631251156.
> > 
> > Both boards actually build fine with e05e5de7fae (and have built
> > fine since, at least in all of the routine ARM-wide builds I do as the
> > ARM custodian and where I accept zero build failures or warnings).
> 
> Yes, for me too. This was not a build issue, but a runtime one.
> 
> > And both boards actually do not build at all with this patch :) and die
> > with the same error:
> > 
> > .../spl/u-boot-spl.lds:45: non constant or forward reference address
> > expression for section .bss
> > 
> > In both case I have double-checked this using Ubuntu's gcc version
> > 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1) or ELDK 5.3's gcc version 4.7.2
> > (GCC).
> 
> OK. That worked fine for me and Fabio at the time I issued the v9, so it can 
> be
> the rebase, or something that changed in mainline in the meantime, or the
> toolchain. According to your tests, it's very unlikely that the toolchain is
> involved.
> 
> I've looked at the Git history, and the guilty commit is 3ebd1cb. But thanks 
> to
> commit 65cdd64, this build issue should be easily solved by replacing:
> +#define CONFIG_SPL_LDSCRIPT"arch/$(ARCH)/cpu/u-boot.lds"
> with:
> +#define CONFIG_SPL_LDSCRIPT"arch/$(ARCH)/cpu/u-boot-spl.lds"
> in both mx31pdk.h and tx25.h.
> 
> Can you please retest with this change?

Patch 18/30 amended with this change and testing done; all ARM boards
build fine now.

> This line could even be dropped from tx25.h since there is no arm926ejs SPL
> linker script obstructing the default assignment, contrary to arm1136 for
> mx31pdk, but that would be risky if such a linker script is added later.
> 
> Is it still OK for the release if I send v10 on April 8 as I said (so just 
> with
> the rebase including the change above if you confirm that everything is OK 
> like
> that)?

You have Scott's acked-by for the NAND parts, and Tom's reviewed-by is
proof enough for me that he is ok with the few non-ARM-only patches,
so the patch series in itself is fine (assuming v10 is identical to
v9 as I rebased it).

I would just like some reports that boards (mx31pdk and tx25 especially,
but others too, including a few non-ARM to make sure) have no issue
running v10.

> Best regards,
> Benoît

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