Re: [U-Boot] [PATCH V3] usb:ci_udc: Remove ULPI setting for i.MX OTG controller

[Li Ye-B37916]

On 12/31/2015 5:07 PM, Marek Vasut wrote:
> On Thursday, December 31, 2015 at 08:24:45 AM, Peng Fan wrote:
>> From: "Ye.Li" 
>>
>> All the i.MX6, i.MX23 and i.MX28 OTG controllers only support UTMI
>> interface. Set to ULPI is not correct, even the controller will
>> reject this setting in PORTSC register.
>>
>> Signed-off-by: Ye.Li 
>> Signed-off-by: Peng Fan 
>> ---
>>
>> Hi Marek,
>>  In V2: https://patchwork.ozlabs.org/patch/541663/
>>  The reason still use DBG, but not change to debug, is that the driver
>>  use DBG for debugging and error handling usage.
>>  So In this patch, I still keep DBG. If you think, it better to switch
>>  to use function debug, I can write another patch to convert all the
>>  DBGs to debug for ci_udc driver.
>>
>> Regards,
>> Peng.
>>
>> Changes since v2:
>>  - Correct code indent.
>> Changes since v1:
>>  - Add error handling for udc probe
>>
>>  drivers/usb/gadget/ci_udc.c | 14 +++---
>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
>> index 1ba5054..d36bcf6 100644
>> --- a/drivers/usb/gadget/ci_udc.c
>> +++ b/drivers/usb/gadget/ci_udc.c
>> @@ -1018,18 +1018,10 @@ int usb_gadget_register_driver(struct
>> usb_gadget_driver *driver) return ret;
>>
>>  ret = ci_udc_probe();
>> -#if defined(CONFIG_USB_EHCI_MX6) || defined(CONFIG_USB_EHCI_MXS)
>> -/*
>> - * FIXME: usb_lowlevel_init()->ehci_hcd_init() should be doing all
>> - * HW-specific initialization, e.g. ULPI-vs-UTMI PHY selection
>> - */
>> -if (!ret) {
>> -struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
>> -
>> -/* select ULPI phy */
>> -writel(PTS(PTS_ENABLE) | PFSC, >portsc);
> So if ci_udc_probe() doesn't fail, this code will select PTS_ENABLE and PFSC
> in the portsc register, right ? If you remove this code, who will do this
> configuration ? I suspect this breaks all i.MXes, no ?

Selecting PTS_ENABLE and PFSC are NOT correct for i.MXes. This code wants to 
select ULPI PHY,  but only UTMI PHY is supported.  So we have to remove this 
code and leave the default UTMI setting.

Actually when setting to ULPI,  other platforms except the i.MX6UL refuse the 
settings and keep default value. So there is no problem for them.  But on 6UL 
TO1.0, there is a IC bug that the PTW bit of PORTSC1 register which is 
documented as RO can change. This cause the interface setting problem with USB 
PHY.  And finally we traced to this incorrect setting.

>> +if (ret) {
>> +DBG("udc probe failed, returned %d\n", ret);
>> +return ret;
>>  }
>> -#endif
>>
>>  ret = driver->bind();
>>  if (ret) {
> Best regards,
> Marek Vasut
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb:ci_udc: Remove ULPI setting for i.MX OTG controller

[Li Ye-B37916]

On 11/5/2015 1:10 PM, Marek Vasut wrote:
> On Thursday, November 05, 2015 at 04:17:38 AM, Ye.Li wrote:
>> All the i.MX6, i.MX23 and i.MX28 OTG controllers only support UTMI
>> interface. Set to ULPI is not correct, even the controller will reject
>> this
>> setting in PORTSC register.
>>
>> Signed-off-by: Ye.Li 
>> ---
>>  drivers/usb/gadget/ci_udc.c |   12 
>>  1 files changed, 0 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
>> index 1ba5054..cb35982 100644
>> --- a/drivers/usb/gadget/ci_udc.c
>> +++ b/drivers/usb/gadget/ci_udc.c
>> @@ -1018,18 +1018,6 @@ int usb_gadget_register_driver(struct
>> usb_gadget_driver *driver) return ret;
>>
>>  ret = ci_udc_probe();
> You're now dropping the error handling for this function, that's really not
> good, so I cannot accept the patch. But the current error handling looks
> totally broken. So the solution I would propose here is to fix the error
> handling for ci_udc_probe() here instead of outright removing the code. What
> do you think ?
I will add a error handling in v2 patch. Thanks.

>
>> -#if defined(CONFIG_USB_EHCI_MX6) || defined(CONFIG_USB_EHCI_MXS)
>> -/*
>> - * FIXME: usb_lowlevel_init()->ehci_hcd_init() should be doing all
>> - * HW-specific initialization, e.g. ULPI-vs-UTMI PHY selection
>> - */
>> -if (!ret) {
>> -struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
>> -
>> -/* select ULPI phy */
>> -writel(PTS(PTS_ENABLE) | PFSC, >portsc);
>> -}
>> -#endif
>>
>>  ret = driver->bind();
>>  if (ret) {
> Best regards,
> Marek Vasut

Best regards,
Ye Li

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

Re: [U-Boot] [PATCH 4/4] imx: mx6sxsabreauto: Add support for mx6sx SABREAUTO board

[Li Ye-B37916]

Hi,

On 2/10/2015 6:51 PM, Stefano Babic wrote:
 Hi,

 On 12/01/2015 09:46, Ye.Li wrote:
 Initial version for mx6sx SABREAUTO board support with features:
 PMIC, QSPI, NAND flash, SD/MMC, USB, Ethernet, I2C, IO Expander.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  arch/arm/Kconfig|5 +
  board/freescale/mx6sxsabreauto/Kconfig  |   15 +
  board/freescale/mx6sxsabreauto/MAINTAINERS  |6 +
  board/freescale/mx6sxsabreauto/Makefile |6 +
  board/freescale/mx6sxsabreauto/imximage.cfg |  136 ++
  board/freescale/mx6sxsabreauto/mx6sxsabreauto.c |  498 
 +++
  configs/mx6sxsabreauto_defconfig|3 +
  include/configs/mx6sxsabreauto.h|  275 +
  8 files changed, 944 insertions(+), 0 deletions(-)
  create mode 100644 board/freescale/mx6sxsabreauto/Kconfig
  create mode 100644 board/freescale/mx6sxsabreauto/MAINTAINERS
  create mode 100644 board/freescale/mx6sxsabreauto/Makefile
  create mode 100644 board/freescale/mx6sxsabreauto/imximage.cfg
  create mode 100644 board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
  create mode 100644 configs/mx6sxsabreauto_defconfig
  create mode 100644 include/configs/mx6sxsabreauto.h

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index 5eb1d03..9c54914 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -638,6 +638,10 @@ config TARGET_MX6SXSABRESD
  bool Support mx6sxsabresd
  select CPU_V7
  
 +config TARGET_MX6SXSABREAUTO
 +bool Support mx6sxsabreauto
 +select CPU_V7
 +
  config TARGET_GW_VENTANA
  bool Support gw_ventana
  select CPU_V7
 @@ -916,6 +920,7 @@ source board/freescale/mx6qsabreauto/Kconfig
  source board/freescale/mx6sabresd/Kconfig
  source board/freescale/mx6slevk/Kconfig
  source board/freescale/mx6sxsabresd/Kconfig
 +source board/freescale/mx6sxsabreauto/Kconfig
  source board/freescale/vf610twr/Kconfig
  source board/gateworks/gw_ventana/Kconfig
  source board/genesi/mx51_efikamx/Kconfig
 diff --git a/board/freescale/mx6sxsabreauto/Kconfig 
 b/board/freescale/mx6sxsabreauto/Kconfig
 new file mode 100644
 index 000..b0f5167
 --- /dev/null
 +++ b/board/freescale/mx6sxsabreauto/Kconfig
 @@ -0,0 +1,15 @@
 +if TARGET_MX6SXSABREAUTO
 +
 +config SYS_BOARD
 +default mx6sxsabreauto
 +
 +config SYS_VENDOR
 +default freescale
 +
 +config SYS_SOC
 +default mx6
 +
 +config SYS_CONFIG_NAME
 +default mx6sxsabreauto
 +
 +endif
 diff --git a/board/freescale/mx6sxsabreauto/MAINTAINERS 
 b/board/freescale/mx6sxsabreauto/MAINTAINERS
 new file mode 100644
 index 000..dd3ae41
 --- /dev/null
 +++ b/board/freescale/mx6sxsabreauto/MAINTAINERS
 @@ -0,0 +1,6 @@
 +MX6SXSABREAUTO BOARD
 +M:  Ye Li ye...@freescale.com
 +S:  Maintained
 +F:  board/freescale/mx6sxsabreauto/
 +F:  include/configs/mx6sxsabreauto.h
 +F:  configs/mx6sxsabreauto_defconfig
 diff --git a/board/freescale/mx6sxsabreauto/Makefile 
 b/board/freescale/mx6sxsabreauto/Makefile
 new file mode 100644
 index 000..f0cd1ce
 --- /dev/null
 +++ b/board/freescale/mx6sxsabreauto/Makefile
 @@ -0,0 +1,6 @@
 +# (C) Copyright 2014 Freescale Semiconductor, Inc.
 +#
 +# SPDX-License-Identifier:  GPL-2.0+
 +#
 +
 +obj-y  := mx6sxsabreauto.o
 diff --git a/board/freescale/mx6sxsabreauto/imximage.cfg 
 b/board/freescale/mx6sxsabreauto/imximage.cfg
 new file mode 100644
 index 000..529e555
 --- /dev/null
 +++ b/board/freescale/mx6sxsabreauto/imximage.cfg
 @@ -0,0 +1,136 @@
 +/*
 + * Copyright (C) 2014 Freescale Semiconductor, Inc.
 + *
 + * SPDX-License-Identifier: GPL-2.0+
 + */
 +
 +#define __ASSEMBLY__
 +#include config.h
 +
 +/* image version */
 +
 +IMAGE_VERSION 2
 +
 +/*
 + * Boot Device : one of
 + * spi/sd/nand/onenand, qspi/nor
 + */
 +
 +BOOT_FROM   sd
 +
 +/*
 + * Device Configuration Data (DCD)
 + *
 + * Each entry must have the format:
 + * Addr-type   AddressValue
 + *
 + * where:
 + *  Addr-type register length (1,2 or 4 bytes)
 + *  Address   absolute address of the register
 + *  value value to be stored in the register
 + */
 +
 +/* Enable all clocks */
 +DATA 4 0x020c4068 0x
 +DATA 4 0x020c406c 0x
 +DATA 4 0x020c4070 0x
 +DATA 4 0x020c4074 0x
 +DATA 4 0x020c4078 0x
 +DATA 4 0x020c407c 0x
 +DATA 4 0x020c4080 0x
 +DATA 4 0x020c4084 0x
 +
 I will not block the patch for this: you are the maintainer and you can
 test and check if this ok.

 I would only to point to the discussion with Peng regarding the same
 issue for the mx6sxsabresd. Peng confirmed that he would send a
 following patch for enabling only the clocks are needed. Mybe you can
 synchronize wit him.

Ungating all clocks won't have functional problem, but consume more power at 
booting.  For mx6 platforms,
we won't change it any more, but on following mx7, we will use a new function 
to initialize needed clocks.

 +/* IOMUX - DDR IO Type */
 +DATA 4 0x020e0618 0x000c
 +DATA 4 

Re: [U-Boot] [PATCH 2/4] mx6: soc: Add ENET2 support

[Li Ye-B37916]

Hi Stefano,

On 2/10/2015 6:22 PM, Stefano Babic wrote:
 Hi,

 On 12/01/2015 09:46, Ye.Li wrote:
 The mx6sx has two ENET controllers, some board like mx6sxsabreauto
 uses the ENET2 for ethernet. So add ENET2 support to soc level,
 including: ENET2 clock enable and MAC address fuse for ENET2.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  arch/arm/cpu/armv7/mx6/clock.c   |9 -
  arch/arm/cpu/armv7/mx6/soc.c |   25 -
  arch/arm/include/asm/arch-mx6/crm_regs.h |7 +++
  3 files changed, 39 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
 index 055f44e..fd57f22 100644
 --- a/arch/arm/cpu/armv7/mx6/clock.c
 +++ b/arch/arm/cpu/armv7/mx6/clock.c
 @@ -498,7 +498,11 @@ int enable_fec_anatop_clock(enum enet_freq freq)
  
  reg = readl(anatop-pll_enet);
  reg = ~BM_ANADIG_PLL_ENET_DIV_SELECT;
 -reg |= freq;
 +reg |= BF_ANADIG_PLL_ENET_DIV_SELECT(freq);
 +#ifdef CONFIG_MX6SX
 +reg = ~BM_ANADIG_PLL_ENET2_DIV_SELECT;
 +reg |= BF_ANADIG_PLL_ENET2_DIV_SELECT(freq);
 +#endif
  
  if ((reg  BM_ANADIG_PLL_ENET_POWERDOWN) ||
  (!(reg  BM_ANADIG_PLL_ENET_LOCK))) {
 @@ -514,6 +518,9 @@ int enable_fec_anatop_clock(enum enet_freq freq)
  
  /* Enable FEC clock */
  reg |= BM_ANADIG_PLL_ENET_ENABLE;
 +#ifdef CONFIG_MX6SX
 +reg |= BM_ANADIG_PLL_ENET2_ENABLE;
 +#endif
  reg = ~BM_ANADIG_PLL_ENET_BYPASS;
  writel(reg, anatop-pll_enet);
  
 diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
 index 5f5f497..4994eab 100644
 --- a/arch/arm/cpu/armv7/mx6/soc.c
 +++ b/arch/arm/cpu/armv7/mx6/soc.c
 @@ -337,6 +337,29 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char 
 *mac)
  struct fuse_bank4_regs *fuse =
  (struct fuse_bank4_regs *)bank-fuse_regs;
  
 +#ifdef CONFIG_MX6SX
 +if (0 == dev_id) {
 +u32 value = readl(fuse-mac_addr_high);
 +mac[0] = (value  8);
 +mac[1] = value ;
 +
 +value = readl(fuse-mac_addr_low);
 +mac[2] = value  24 ;
 ^---

 Checkpatch complains about extra spaces.
I will fix this problem.
 +mac[3] = value  16 ;
 +mac[4] = value  8 ;
 +mac[5] = value ;
 +} else {
 +u32 value = readl(fuse-mac_addr2);
 +mac[0] = value  24 ;
 +mac[1] = value  16 ;
 +mac[2] = value  8 ;
 +mac[3] = value ;
 +
 +value = readl(fuse-mac_addr_high);
 +mac[4] = value  24 ;
 +mac[5] = value  16 ;
 Is it desired that the layout is different between the two mac addresses
 ? As far as I know, MAC_ADDR in fuses is reserved to customers, and it
 makes sense they have the same layout.
 Is there some reason (that I do not know, obviously) to have them
 different ?

I think the reason is to save one fuse. If the enet2 has same mac fuse layout 
as enet1, obviously we have to use one more fuse than
current layout. Additional, the layout is determined by IC, software just 
follows it. 

 +}
 +#else
  u32 value = readl(fuse-mac_addr_high);
  mac[0] = (value  8);
  mac[1] = value ;
 @@ -346,7 +369,7 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char 
 *mac)
  mac[3] = value  16 ;
  mac[4] = value  8 ;
  mac[5] = value ;
 -
 +#endif
  }
  #endif
  
 diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
 b/arch/arm/include/asm/arch-mx6/crm_regs.h
 index 39f3c07..eec03cf 100644
 --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
 +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
 @@ -1012,6 +1012,13 @@ struct mxc_ccm_reg {
  #define BM_ANADIG_PLL_ENET_DIV_SELECT 0x0003
  #define BF_ANADIG_PLL_ENET_DIV_SELECT(v)  \
  (((v)  0)  BM_ANADIG_PLL_ENET_DIV_SELECT)
 +#ifdef CONFIG_MX6SX
 +#define BM_ANADIG_PLL_ENET2_ENABLE 0x0010
 +
 +#define BM_ANADIG_PLL_ENET2_DIV_SELECT 0x000C
 +#define BF_ANADIG_PLL_ENET2_DIV_SELECT(v)  \
 +(((v)  2)  BM_ANADIG_PLL_ENET2_DIV_SELECT)
 +#endif
  
  #define BM_ANADIG_PFD_480_PFD3_CLKGATE 0x8000
  #define BM_ANADIG_PFD_480_PFD3_STABLE 0x4000

 Best regards,
 Stefano Babic


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

Re: [U-Boot] [PATCH 3/4] mx6: clock: Modify GPMI clock to support mx6sx

[Li Ye-B37916]

Hi Stefano,

On 2/10/2015 6:26 PM, Stefano Babic wrote:
 Hi Ye,

 On 12/01/2015 09:46, Ye.Li wrote:
 On mx6sx, the CCM register bits for GPMI are different as other
 mx6 platforms. Modify the GPMI clock function to support mx6sx.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  arch/arm/cpu/armv7/mx6/clock.c |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
 index fd57f22..ce7f0f7 100644
 --- a/arch/arm/cpu/armv7/mx6/clock.c
 +++ b/arch/arm/cpu/armv7/mx6/clock.c
 @@ -47,6 +47,17 @@ void setup_gpmi_io_clk(u32 cfg)
   MXC_CCM_CCGR4_RAWNAND_U_GPMI_INPUT_APB_MASK |
   MXC_CCM_CCGR4_PL301_MX6QPER1_BCH_MASK);
  
 +#if defined(CONFIG_MX6SX)
 +clrbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_QSPI2_ENFC_MASK);
 +
 +clrsetbits_le32(imx_ccm-cs2cdr,
 +MXC_CCM_CS2CDR_QSPI2_CLK_PODF_MASK |
 +MXC_CCM_CS2CDR_QSPI2_CLK_PRED_MASK |
 +MXC_CCM_CS2CDR_QSPI2_CLK_SEL_MASK,
 +cfg);
 +
 +setbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_QSPI2_ENFC_MASK);
 +#els
 If I have well understood, this code is protected by CONFIG_NAND_MXS,
 and that conflicts with what you are willing to do (setting clocks for
 QSPI). I suggest to split setup_gpmi_io_clk() function, that at the
 moment is ony for NAND, having something like:

 void setup_gpmi_io_clk()
 {
 #ifdef CONFIG_NAND_MXS

   ...setup nand
 #endif

   ...setup qspi

 }

 Best regards,
 Stefano Babic

I feel you misunderstand the patch. On i.MX6sx, the QSPI2 and GPMI shares the 
same clock root of QSPI2. So you can see the register bits are
named with MXC_CCM_CS2CDR_QSPI2_xxx. Actually, not only the name, there is a 
little different in the CS2CDR register bits layout.  The patch is used to fix 
the gap. 

Also the the GPMI pins are multiplexed with QSPI2 pins, so either NAND or QSPI2 
can work,  there is no conflict.

Best regards,
Ye Li

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

Re: [U-Boot] [PATCH 1/4] mx6sx: pins: Enable SION for I2C3 iomux setting

[Li Ye-B37916]

Hi Stefano, Nikolay,

On 1/30/2015 1:54 AM, Stefano Babic wrote:
 Hi,

 On 12/01/2015 11:37, Nikolay Dimitrov wrote:
 Hi Ye.Li,

 On 01/12/2015 10:46 AM, Ye.Li wrote:
 The I2C SDA and SCL require the IOMUX SION bit set to get input signal.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
   arch/arm/include/asm/arch-mx6/mx6sx_pins.h |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
 b/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
 index 7c6c1e8..da8c698 100644
 --- a/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
 +++ b/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
 @@ -420,7 +420,7 @@ enum {

MX6_PAD_KEY_COL4__KPP_COL_4=
 IOMUX_PAD(0x03FC, 0x00B4, 0, 0x, 0, 0),
MX6_PAD_KEY_COL4__ENET2_MDC=
 IOMUX_PAD(0x03FC, 0x00B4, 1, 0x, 0, 0),
 - MX6_PAD_KEY_COL4__I2C3_SCL =
 IOMUX_PAD(0x03FC, 0x00B4, 2, 0x07B8, 2, 0),
 + MX6_PAD_KEY_COL4__I2C3_SCL =
 IOMUX_PAD(0x03FC, 0x00B4, IOMUX_CONFIG_SION | 2, 0x07B8, 2, 0),
MX6_PAD_KEY_COL4__USDHC2_LCTL  =
 IOMUX_PAD(0x03FC, 0x00B4, 3, 0x, 0, 0),
MX6_PAD_KEY_COL4__AUDMUX_AUD5_RXC  =
 IOMUX_PAD(0x03FC, 0x00B4, 4, 0x0664, 0, 0),
MX6_PAD_KEY_COL4__GPIO2_IO_14  =
 IOMUX_PAD(0x03FC, 0x00B4, 5, 0x, 0, 0),
 @@ -467,7 +467,7 @@ enum {

MX6_PAD_KEY_ROW4__KPP_ROW_4=
 IOMUX_PAD(0x0410, 0x00C8, 0, 0x, 0, 0),
MX6_PAD_KEY_ROW4__ENET2_MDIO   =
 IOMUX_PAD(0x0410, 0x00C8, 1, 0x0770, 3, 0),
 - MX6_PAD_KEY_ROW4__I2C3_SDA =
 IOMUX_PAD(0x0410, 0x00C8, 2, 0x07BC, 2, 0),
 + MX6_PAD_KEY_ROW4__I2C3_SDA =
 IOMUX_PAD(0x0410, 0x00C8, IOMUX_CONFIG_SION | 2, 0x07BC, 2, 0),
MX6_PAD_KEY_ROW4__USDHC1_LCTL  =
 IOMUX_PAD(0x0410, 0x00C8, 3, 0x, 0, 0),
MX6_PAD_KEY_ROW4__AUDMUX_AUD5_RXFS =
 IOMUX_PAD(0x0410, 0x00C8, 4, 0x0668, 0, 0),
MX6_PAD_KEY_ROW4__GPIO2_IO_19  =
 IOMUX_PAD(0x0410, 0x00C8, 5, 0x, 0, 0),

 Usually the SCL is output-only, driven by the I2C master. Why do you
 need to enable SION bit on SCL, if the pin will be used as output-only?

 Right - I do not see why SION should be set.

 Regards,
 Stefano Babic


Setting SION to both SDA and SCL is required by i.MX6 reference manual.  You 
can find the information below from i2c chapter.

34.2 External Signals
This section discusses I2C signals that connect off-chip.
For I2C compliance, all devices connected to the I2Cn_SCL and I2Cn_SDA signals 
must
have open-drain or open-collector outputs. The logic AND function is 
implemented on
both lines with external pull-up resistors.
Inputs of I2Cn_SCL and I2Cn_SDA also need to be manually enabled by setting the
SION bit in the IOMUX after the corresponding PADs are selected as I2C function.

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

Re: [U-Boot] [PATCH 1/4] imx: mx6: Add support for MX6 plugin images

[Li Ye-B37916]

Hi Fabio,

On 11/4/2014 11:46 PM, Fabio Estevam wrote:
 Hi Ye Li,

 On Tue, Nov 4, 2014 at 6:27 AM, Ye.Li b37...@freescale.com wrote:
 Plugin image is a firmware which can be executed by boot ROM to do
 device initialization, custom settings, delay assertion, etc.
 Could you please elaborate a bit mode about the usage of the 'plugin image'?

 When does it become useful? When should we make use of it instead of
 the current DCD table?

 Thanks,

 Fabio Estevam
I will improve the patch message in v2.

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

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Li Ye-B37916]

Hi Przemyslaw,

On 11/4/2014 10:09 PM, Przemyslaw Marczak wrote:
 Hello Ye Li,

 On 11/04/2014 10:37 AM, Li Ye-B37916 wrote:

 Hi Przemyslaw,

 On 11/4/2014 5:24 PM, Li Ye-B37916 wrote:
 Hi Przemyslaw,


 On 10/30/2014 6:36 PM, Stefano Babic wrote:
 Hi Ye,

 On 10/09/2014 11:08, Ye.Li wrote:
 Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
 has Pfuze100 or Pfuze200, print the chip type by parsing the ID.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Slowly (sorry for that..) I am checking again all PMIC related patches
 you sent last month. However, these patches do not fit very well in the
 current development.

 In the last U-Boot mini summit we get the decision to post new PMIC
 drivers according to the Device Model rules. Przemyslaw is the new
 custodian for PMICs, and he will take care of all related issues
 regarding power management.
 Can you share me more information about the new PMIC drivers development 
 that Stefano mentioned above.
 1. Have you completed the APIs define for new PMIC drivers?  If yes, where 
 I can get them.
 2. When will the new PMIC drivers deliver?
 3. Will the PMIC devices already supported in current release stay 
 supported by new PMIC drivers?


 The work on new PMIC framework was temporary on hold.
 Now I'm working on it, but the basic functionality is actually done.
 The first version you can check here:
 https://github.com/bobenstein/u-boot.git
 I need to make some rework, since the i2c is going to support the driver 
 model.

 I can now focus on this work. And this will be merged through u-boot-dm - 
 since i2c support is added.

 The plan is simple:
 1) Add new drivers to the present PMIC framework - before merge the new one.
 2) Add new PMIC framework as a separated piece of code.
 3) Migrate old drivers and boards to the new framework.
 4) Remove the old framework without any conflicts.

 So it's not a problem if you want add this driver, we add this to the current 
 framework - the migration should be simple and will not cause conflicts.

 If you are interested in the new PMIC framework design, please read the doc 
 file added by the patches from the link above.

 You can implement just one class(UCLASS_PMIC), and if you need user friendly 
 interface it is welcome to implement also UCLASS_PMIC_REGULATOR.

 Please follow the list, maybe I will send the patches at the end of this week.

 ... [ snip ] ...


 Best regards,

My patches don't add any new PMIC driver. The PFUZE100 driver already exists in 
present u-boot.  We just call the driver to apply new settings for PFUZE100.
According to your plan, can you help to figure out which phase the PMIC 
development is at now?   I feel my patches won't conflict with your job before 
phase 3. 
If there is no conflict, I will continue the upstream.

Best regards,
Ye Li

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

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Li Ye-B37916]

Hi Przemyslaw,

On 11/4/2014 11:56 PM, Przemyslaw Marczak wrote:
 Hello Ye Li,

 On 09/10/2014 11:08 AM, Ye.Li wrote:
 Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
 has Pfuze100 or Pfuze200, print the chip type by parsing the ID.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
   board/freescale/mx6slevk/mx6slevk.c |   57 
 +++
   include/configs/mx6slevk.h  |7 
   2 files changed, 64 insertions(+), 0 deletions(-)

 diff --git a/board/freescale/mx6slevk/mx6slevk.c 
 b/board/freescale/mx6slevk/mx6slevk.c
 index fedd5c3..8b6a79c 100644
 --- a/board/freescale/mx6slevk/mx6slevk.c
 +++ b/board/freescale/mx6slevk/mx6slevk.c
 @@ -21,6 +21,8 @@
   #include mmc.h
   #include netdev.h
   #include i2c.h
 +#include power/pmic.h
 +#include power/pfuze100_pmic.h

   DECLARE_GLOBAL_DATA_PTR;

 @@ -48,6 +50,8 @@ DECLARE_GLOBAL_DATA_PTR;

   #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)

 +#define I2C_PMIC0
 +
   /* I2C1 for PMIC */
   struct i2c_pads_info i2c_pad_info0 = {
   .sda = {
 @@ -191,6 +195,59 @@ int board_init(void)
   return 0;
   }

 +static int pfuze_init(void)
 +{
 +struct pmic *p;
 +int ret;
 +unsigned int reg;
 +
 +ret = power_pfuze100_init(I2C_PMIC);
 +if (ret)
 +return ret;
 +
 +p = pmic_get(PFUZE100);
 +ret = pmic_probe(p);
 +if (ret)
 +return ret;
 +
 +pmic_reg_read(p, PFUZE100_DEVICEID, reg);
 +printf(PMIC:  PFUZE%s ID=0x%02x\n,
 +((reg  0xf) == 0) ? 100 : 200, reg);
 +
 +/* Set SW1AB stanby volage to 0.975V */
 +pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
 +reg = ~0x3f;
 +reg |= 0x1b;
 +pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
 +
 +/* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
 +pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
 +reg = ~0xc0;
 +reg |= 0x40;
 +pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
 +
 +/* Set SW1C standby voltage to 0.975V */
 +pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
 +reg = ~0x3f;
 +reg |= 0x1b;
 +pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
 +
 +/* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
 +pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
 +reg = ~0xc0;
 +reg |= 0x40;
 +pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
 +
 +return 0;
 +}
 +
 +int board_late_init(void)
 +{
 +pfuze_init();
 +
 +return 0;
 +}

 Why not use power_init_board()?
 It's dedicated and called at common/board_r.c.

Good suggestion, will change to use the power_init_board in v2.

 +
   u32 get_board_rev(void)
   {
   return get_cpu_rev();
 diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
 index bf5066f..09d0896 100644
 --- a/include/configs/mx6slevk.h
 +++ b/include/configs/mx6slevk.h
 @@ -30,6 +30,7 @@
   #define CONFIG_SYS_MALLOC_LEN(3 * SZ_1M)

   #define CONFIG_BOARD_EARLY_INIT_F
 +#define CONFIG_BOARD_LATE_INIT
   #define CONFIG_MXC_GPIO

   #define CONFIG_MXC_UART
 @@ -66,6 +67,12 @@
   #define CONFIG_SYS_I2C_MXC
   #define CONFIG_SYS_I2C_SPEED  10

 +/* PMIC */
 +#define CONFIG_POWER
 +#define CONFIG_POWER_I2C
 +#define CONFIG_POWER_PFUZE100
 +#define CONFIG_POWER_PFUZE100_I2C_ADDR0x08

 I assume that the I2C addr is const, if yes then it should be moved to the 
 PFUZE100 header.

It is not const. The default I2C address is 0x08.  But it can be programmed 
from 0x08 to 0x0F by setting
OTP_I2C_ADDR register.

 +
   /* allow to overwrite serial and ethaddr */
   #define CONFIG_ENV_OVERWRITE
   #define CONFIG_CONS_INDEX1


 Thank you,

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

Re: [U-Boot] [PATCH 4/4] imx: mx6: Set Pfuze mode to decrease power number for DSM

[Li Ye-B37916]

Hi Przemyslaw,

On 11/4/2014 11:57 PM, Przemyslaw Marczak wrote:
 Hello Ye Li,

 On 09/10/2014 11:08 AM, Ye.Li wrote:
 Set all switches APS mode in normal and PFM mode in standby. So when
 mx6 entering DSM mode, the power number can be decreased. There is
 no impact for mx6 in run mode.

 Changes for boards:
 -mx6 sabreauto
 -mx6 sabresd
 -mx6slevk
 -mx6sxsabresd

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
   board/freescale/mx6qsabreauto/mx6qsabreauto.c |   36 
 +
   board/freescale/mx6sabresd/mx6sabresd.c   |   36 
 +
   board/freescale/mx6slevk/mx6slevk.c   |   36 
 +
   board/freescale/mx6sxsabresd/mx6sxsabresd.c   |   36 
 +
   4 files changed, 144 insertions(+), 0 deletions(-)

 diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
 b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 index 76b024b..9e79915 100644
 --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 @@ -263,6 +263,37 @@ int board_init(void)
   return 0;
   }

 +/* set all switches APS in normal and PFM mode in standby */

 I think that the chip is quite misleading.
 Just use chipid and check the real value instead of using it as bool.
 And the PF100 DEVICEID should be defined in pf100 header.

Accept. Will change it in next version.

 +static int pfuze_setup_mode(struct pmic *p, int chip)
 +{
 +unsigned char offset, i, switch_num, value;
 +
 +if (!chip) {
 +/* pfuze100 */
 +switch_num = 6;
 +offset = 0x31;
 +} else {
 +/* pfuze200 */
 +switch_num = 4;
 +offset = 0x38;
 +}
 +
 +value = 0xc;

 If you change magic values (e.g. 0xc) with proper defines in pmic header, 
 then it could be reused in the future and the code will be more readable.

Ok.

 +if (pmic_reg_write(p, 0x23, value)) {
 +printf(Set SW1AB mode error!\n);
 +return -1;
 +}
 +
 +for (i = 0; i  switch_num - 1; i++) {
 +if (pmic_reg_write(p, offset + i * 7, value)) {
 +printf(Set switch%x mode error!\n, offset);
 +return -1;
 +}
 +}
 +
 +return 0;
 +}

 The function above is duplicated few times in each board code.
 Why not make it common and just one?


I already have made it as a common function in v4. The patch you reviewed seems 
not the latest one.  I will address your other comments and send out v5.

 +
   static int pfuze_init(void)
   {
   struct pmic *p;
 @@ -281,6 +312,11 @@ static int pfuze_init(void)
   pmic_reg_read(p, PFUZE100_DEVICEID, reg);
   printf(PMIC:  PFUZE100 ID=0x%02x\n, reg);

 +if (pfuze_setup_mode(p, (reg  0xf))) {
 +printf(setup pfuze mode error!\n);
 +return -1;
 +}
 +
   /* Set SW1AB stanby volage to 0.975V */
   pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
   reg = ~0x3f;
 diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
 b/board/freescale/mx6sabresd/mx6sabresd.c
 index 72d6562..810fe13 100644
 --- a/board/freescale/mx6sabresd/mx6sabresd.c
 +++ b/board/freescale/mx6sabresd/mx6sabresd.c
 @@ -456,6 +456,37 @@ int board_init(void)
   return 0;
   }

 +/* set all switches APS in normal and PFM mode in standby */
 +static int pfuze_setup_mode(struct pmic *p, int chip)
 +{
 +unsigned char offset, i, switch_num, value;
 +
 +if (!chip) {
 +/* pfuze100 */
 +switch_num = 6;
 +offset = 0x31;
 +} else {
 +/* pfuze200 */
 +switch_num = 4;
 +offset = 0x38;
 +}
 +
 +value = 0xc;
 +if (pmic_reg_write(p, 0x23, value)) {
 +printf(Set SW1AB mode error!\n);
 +return -1;
 +}
 +
 +for (i = 0; i  switch_num - 1; i++) {
 +if (pmic_reg_write(p, offset + i * 7, value)) {
 +printf(Set switch%x mode error!\n, offset);
 +return -1;
 +}
 +}
 +
 +return 0;
 +}
 +
   static int pfuze_init(void)
   {
   struct pmic *p;
 @@ -475,6 +506,11 @@ static int pfuze_init(void)
   printf(PMIC:  PFUZE%s ID=0x%02x\n,
   ((reg  0xf) == 0) ? 100 : 200, reg);

 +if (pfuze_setup_mode(p, (reg  0xf))) {
 +printf(setup pfuze mode error!\n);
 +return -1;
 +}
 +
   /* Increase VGEN3 from 2.5 to 2.8V */
   pmic_reg_read(p, PFUZE100_VGEN3VOL, reg);
   reg = ~0xf;
 diff --git a/board/freescale/mx6slevk/mx6slevk.c 
 b/board/freescale/mx6slevk/mx6slevk.c
 index 8b6a79c..fe5e37d 100644
 --- a/board/freescale/mx6slevk/mx6slevk.c
 +++ b/board/freescale/mx6slevk/mx6slevk.c
 @@ -195,6 +195,37 @@ int board_init(void)
   return 0;
   }

 +/* set all switches APS in normal and PFM mode in standby */
 +static int pfuze_setup_mode(struct pmic *p, int chip)
 +{
 +unsigned char offset, i, switch_num, value;
 +
 +if (!chip) {
 +/* pfuze100 */
 +switch_num = 6;
 +offset = 0x31;
 +} else {
 +/* pfuze200 */
 +

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Li Ye-B37916]

Hi Przemyslaw,


On 10/30/2014 6:36 PM, Stefano Babic wrote:
 Hi Ye,

 On 10/09/2014 11:08, Ye.Li wrote:
 Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
 has Pfuze100 or Pfuze200, print the chip type by parsing the ID.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Slowly (sorry for that..) I am checking again all PMIC related patches
 you sent last month. However, these patches do not fit very well in the
 current development.

 In the last U-Boot mini summit we get the decision to post new PMIC
 drivers according to the Device Model rules. Przemyslaw is the new
 custodian for PMICs, and he will take care of all related issues
 regarding power management.

Can you share me more information about the new PMIC drivers development that 
Stefano mentioned above.
1. Have you completed the APIs define for new PMIC drivers?  If yes, where I 
can get them.
2. When will the new PMIC drivers deliver?
3. Will the PMIC devices already supported in current release stay supported by 
new PMIC drivers?

Best regards,
Ye Li
 Please rethink your patches and post them again, not forgetting to add
 Przemyslaw in CC.

 Best regards,
 Stefano Babic

  board/freescale/mx6slevk/mx6slevk.c |   57 
 +++
  include/configs/mx6slevk.h  |7 
  2 files changed, 64 insertions(+), 0 deletions(-)

 diff --git a/board/freescale/mx6slevk/mx6slevk.c 
 b/board/freescale/mx6slevk/mx6slevk.c
 index fedd5c3..8b6a79c 100644
 --- a/board/freescale/mx6slevk/mx6slevk.c
 +++ b/board/freescale/mx6slevk/mx6slevk.c
 @@ -21,6 +21,8 @@
  #include mmc.h
  #include netdev.h
  #include i2c.h
 +#include power/pmic.h
 +#include power/pfuze100_pmic.h
  
  DECLARE_GLOBAL_DATA_PTR;
  
 @@ -48,6 +50,8 @@ DECLARE_GLOBAL_DATA_PTR;
  
  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
  
 +#define I2C_PMIC0
 +
  /* I2C1 for PMIC */
  struct i2c_pads_info i2c_pad_info0 = {
  .sda = {
 @@ -191,6 +195,59 @@ int board_init(void)
  return 0;
  }
  
 +static int pfuze_init(void)
 +{
 +struct pmic *p;
 +int ret;
 +unsigned int reg;
 +
 +ret = power_pfuze100_init(I2C_PMIC);
 +if (ret)
 +return ret;
 +
 +p = pmic_get(PFUZE100);
 +ret = pmic_probe(p);
 +if (ret)
 +return ret;
 +
 +pmic_reg_read(p, PFUZE100_DEVICEID, reg);
 +printf(PMIC:  PFUZE%s ID=0x%02x\n,
 +((reg  0xf) == 0) ? 100 : 200, reg);
 +
 +/* Set SW1AB stanby volage to 0.975V */
 +pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
 +reg = ~0x3f;
 +reg |= 0x1b;
 +pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
 +
 +/* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
 +pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
 +reg = ~0xc0;
 +reg |= 0x40;
 +pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
 +
 +/* Set SW1C standby voltage to 0.975V */
 +pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
 +reg = ~0x3f;
 +reg |= 0x1b;
 +pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
 +
 +/* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
 +pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
 +reg = ~0xc0;
 +reg |= 0x40;
 +pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
 +
 +return 0;
 +}
 +
 +int board_late_init(void)
 +{
 +pfuze_init();
 +
 +return 0;
 +}
 +
  u32 get_board_rev(void)
  {
  return get_cpu_rev();
 diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
 index bf5066f..09d0896 100644
 --- a/include/configs/mx6slevk.h
 +++ b/include/configs/mx6slevk.h
 @@ -30,6 +30,7 @@
  #define CONFIG_SYS_MALLOC_LEN   (3 * SZ_1M)
  
  #define CONFIG_BOARD_EARLY_INIT_F
 +#define CONFIG_BOARD_LATE_INIT
  #define CONFIG_MXC_GPIO
  
  #define CONFIG_MXC_UART
 @@ -66,6 +67,12 @@
  #define CONFIG_SYS_I2C_MXC
  #define CONFIG_SYS_I2C_SPEED  10
  
 +/* PMIC */
 +#define CONFIG_POWER
 +#define CONFIG_POWER_I2C
 +#define CONFIG_POWER_PFUZE100
 +#define CONFIG_POWER_PFUZE100_I2C_ADDR  0x08
 +
  /* allow to overwrite serial and ethaddr */
  #define CONFIG_ENV_OVERWRITE
  #define CONFIG_CONS_INDEX   1



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

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Li Ye-B37916]

Hi Przemyslaw,

On 11/4/2014 5:24 PM, Li Ye-B37916 wrote:
 Hi Przemyslaw,


 On 10/30/2014 6:36 PM, Stefano Babic wrote:
 Hi Ye,

 On 10/09/2014 11:08, Ye.Li wrote:
 Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
 has Pfuze100 or Pfuze200, print the chip type by parsing the ID.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Slowly (sorry for that..) I am checking again all PMIC related patches
 you sent last month. However, these patches do not fit very well in the
 current development.

 In the last U-Boot mini summit we get the decision to post new PMIC
 drivers according to the Device Model rules. Przemyslaw is the new
 custodian for PMICs, and he will take care of all related issues
 regarding power management.
 Can you share me more information about the new PMIC drivers development that 
 Stefano mentioned above.
 1. Have you completed the APIs define for new PMIC drivers?  If yes, where I 
 can get them.
 2. When will the new PMIC drivers deliver?
 3. Will the PMIC devices already supported in current release stay supported 
 by new PMIC drivers?

 Best regards,
 Ye Li
 Please rethink your patches and post them again, not forgetting to add
 Przemyslaw in CC.

 Best regards,
 Stefano Babic

  board/freescale/mx6slevk/mx6slevk.c |   57 
 +++
  include/configs/mx6slevk.h  |7 
  2 files changed, 64 insertions(+), 0 deletions(-)

 diff --git a/board/freescale/mx6slevk/mx6slevk.c 
 b/board/freescale/mx6slevk/mx6slevk.c
 index fedd5c3..8b6a79c 100644
 --- a/board/freescale/mx6slevk/mx6slevk.c
 +++ b/board/freescale/mx6slevk/mx6slevk.c
 @@ -21,6 +21,8 @@
  #include mmc.h
  #include netdev.h
  #include i2c.h
 +#include power/pmic.h
 +#include power/pfuze100_pmic.h
  
  DECLARE_GLOBAL_DATA_PTR;
  
 @@ -48,6 +50,8 @@ DECLARE_GLOBAL_DATA_PTR;
  
  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
  
 +#define I2C_PMIC   0
 +
  /* I2C1 for PMIC */
  struct i2c_pads_info i2c_pad_info0 = {
 .sda = {
 @@ -191,6 +195,59 @@ int board_init(void)
 return 0;
  }
  
 +static int pfuze_init(void)
 +{
 +   struct pmic *p;
 +   int ret;
 +   unsigned int reg;
 +
 +   ret = power_pfuze100_init(I2C_PMIC);
 +   if (ret)
 +   return ret;
 +
 +   p = pmic_get(PFUZE100);
 +   ret = pmic_probe(p);
 +   if (ret)
 +   return ret;
 +
 +   pmic_reg_read(p, PFUZE100_DEVICEID, reg);
 +   printf(PMIC:  PFUZE%s ID=0x%02x\n,
 +   ((reg  0xf) == 0) ? 100 : 200, reg);
 +
 +   /* Set SW1AB stanby volage to 0.975V */
 +   pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
 +   reg = ~0x3f;
 +   reg |= 0x1b;
 +   pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
 +
 +   /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
 +   pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
 +   reg = ~0xc0;
 +   reg |= 0x40;
 +   pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
 +
 +   /* Set SW1C standby voltage to 0.975V */
 +   pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
 +   reg = ~0x3f;
 +   reg |= 0x1b;
 +   pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
 +
 +   /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
 +   pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
 +   reg = ~0xc0;
 +   reg |= 0x40;
 +   pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
 +
 +   return 0;
 +}
 +
 +int board_late_init(void)
 +{
 +   pfuze_init();
 +
 +   return 0;
 +}
 +
  u32 get_board_rev(void)
  {
 return get_cpu_rev();
 diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
 index bf5066f..09d0896 100644
 --- a/include/configs/mx6slevk.h
 +++ b/include/configs/mx6slevk.h
 @@ -30,6 +30,7 @@
  #define CONFIG_SYS_MALLOC_LEN  (3 * SZ_1M)
  
  #define CONFIG_BOARD_EARLY_INIT_F
 +#define CONFIG_BOARD_LATE_INIT
  #define CONFIG_MXC_GPIO
  
  #define CONFIG_MXC_UART
 @@ -66,6 +67,12 @@
  #define CONFIG_SYS_I2C_MXC
  #define CONFIG_SYS_I2C_SPEED 10
  
 +/* PMIC */
 +#define CONFIG_POWER
 +#define CONFIG_POWER_I2C
 +#define CONFIG_POWER_PFUZE100
 +#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
 +
  /* allow to overwrite serial and ethaddr */
  #define CONFIG_ENV_OVERWRITE
  #define CONFIG_CONS_INDEX  1


Please help to answer my questions in the emails thread.  A incorrect email 
address was given, so I resend the email now.

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

Re: [U-Boot] [PATCH v2 1/4] imx: mx6sabresd/sabreauto: Move MX6Q/DL DDR and FDT configs to defconfig

[Li Ye-B37916]

Hi Stefano,

On 9/9/2014 2:50 PM, Ye.Li wrote:
 To support more iMX6 variants,
 1. Make the DDR size configurable based on the defconfig file
 2. Make the FDT file configurable based on the defconfig file

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Changes since v1:
 - Rework the short log subject

  board/freescale/mx6qsabreauto/mx6qsabreauto.c |2 +-
  board/freescale/mx6sabresd/mx6sabresd.c   |2 +-
  configs/mx6dlsabreauto_defconfig  |2 +-
  configs/mx6dlsabresd_defconfig|2 +-
  configs/mx6qsabreauto_defconfig   |2 +-
  configs/mx6qsabresd_defconfig |2 +-
  include/configs/mx6qsabreauto.h   |9 ++---
  include/configs/mx6sabresd.h  |8 +---
  8 files changed, 9 insertions(+), 20 deletions(-)

 diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
 b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 index 928dadf..bfb9b6a 100644
 --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 @@ -45,7 +45,7 @@ DECLARE_GLOBAL_DATA_PTR;
  
  int dram_init(void)
  {
 - gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
 + gd-ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
  
   return 0;
  }
 diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
 b/board/freescale/mx6sabresd/mx6sabresd.c
 index 80c8ebd..5f65f1b 100644
 --- a/board/freescale/mx6sabresd/mx6sabresd.c
 +++ b/board/freescale/mx6sabresd/mx6sabresd.c
 @@ -53,7 +53,7 @@ DECLARE_GLOBAL_DATA_PTR;
  
  int dram_init(void)
  {
 - gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
 + gd-ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
  
   return 0;
  }
 diff --git a/configs/mx6dlsabreauto_defconfig 
 b/configs/mx6dlsabreauto_defconfig
 index b649935..ce755d1 100644
 --- a/configs/mx6dlsabreauto_defconfig
 +++ b/configs/mx6dlsabreauto_defconfig
 @@ -1,3 +1,3 @@
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6qsabreauto/mx6dl.cfg,MX6DL
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6qsabreauto/mx6dl.cfg,MX6DL,DEFAULT_FDT_FILE=\imx6dl-sabreauto.dtb\,DDR_MB=2048
  CONFIG_ARM=y
  CONFIG_TARGET_MX6QSABREAUTO=y
 diff --git a/configs/mx6dlsabresd_defconfig b/configs/mx6dlsabresd_defconfig
 index 9ce960e..b8e6d29 100644
 --- a/configs/mx6dlsabresd_defconfig
 +++ b/configs/mx6dlsabresd_defconfig
 @@ -1,3 +1,3 @@
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DEFAULT_FDT_FILE=\imx6dl-sabresd.dtb\,DDR_MB=1024
  CONFIG_ARM=y
  CONFIG_TARGET_MX6SABRESD=y
 diff --git a/configs/mx6qsabreauto_defconfig b/configs/mx6qsabreauto_defconfig
 index 7d86700..25085a9 100644
 --- a/configs/mx6qsabreauto_defconfig
 +++ b/configs/mx6qsabreauto_defconfig
 @@ -1,3 +1,3 @@
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q,DEFAULT_FDT_FILE=\imx6q-sabreauto.dtb\,DDR_MB=2048
  CONFIG_ARM=y
  CONFIG_TARGET_MX6QSABREAUTO=y
 diff --git a/configs/mx6qsabresd_defconfig b/configs/mx6qsabresd_defconfig
 index dc8e254..edfb988 100644
 --- a/configs/mx6qsabresd_defconfig
 +++ b/configs/mx6qsabresd_defconfig
 @@ -1,3 +1,3 @@
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q,DEFAULT_FDT_FILE=\imx6q-sabresd.dtb\,DDR_MB=1024
  CONFIG_ARM=y
  CONFIG_TARGET_MX6SABRESD=y
 diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
 index d1639c4..e8580e6 100644
 --- a/include/configs/mx6qsabreauto.h
 +++ b/include/configs/mx6qsabreauto.h
 @@ -1,5 +1,5 @@
  /*
 - * Copyright (C) 2012 Freescale Semiconductor, Inc.
 + * Copyright (C) 2014 Freescale Semiconductor, Inc.
   *
   * Configuration settings for the Freescale i.MX6Q SabreAuto board.
   *
 @@ -12,13 +12,8 @@
  #define CONFIG_MACH_TYPE 3529
  #define CONFIG_MXC_UART_BASE UART4_BASE
  #define CONFIG_CONSOLE_DEV   ttymxc3
 -#if defined CONFIG_MX6Q
 -#define CONFIG_DEFAULT_FDT_FILE  imx6q-sabreauto.dtb
 -#elif defined CONFIG_MX6DL
 -#define CONFIG_DEFAULT_FDT_FILE  imx6dl-sabreauto.dtb
 -#endif
 +
  #define CONFIG_MMCROOT   /dev/mmcblk0p2
 -#define PHYS_SDRAM_SIZE  (2u * 1024 * 1024 * 1024)
  
  /* USB Configs */
  #define CONFIG_CMD_USB
 diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
 index e666ebb..c8ac5aa 100644
 --- a/include/configs/mx6sabresd.h
 +++ b/include/configs/mx6sabresd.h
 @@ -1,5 +1,5 @@
  /*
 - * Copyright (C) 2012 Freescale Semiconductor, Inc.
 + * Copyright (C) 2014 Freescale Semiconductor, Inc.
   *
   * Configuration settings for the Freescale i.MX6Q SabreSD board.
   *
 @@ -16,12 +16,6 @@
  #define 

Re: [U-Boot] [PATCH 3/5] arm:imx-common introduce a new function to set gpr

[Li Ye-B37916]

Hi Peng,

 

On 11/1/2014 10:19 AM, Peng Fan wrote:
 Add a new function mxc_iomux_set_gpr_register to
 set the iomux gpr register.

 32-bit general purpose registers according to SoC
 requirements for any usage.

 Signed-off-by: Peng Fan peng@freescale.com
 Signed-off-by: Ye.Li b37...@freescale.com
 Signed-off-by: Nitin Garg nitin.g...@freescale.com
 ---
  arch/arm/imx-common/iomux-v3.c | 25 +
  1 file changed, 25 insertions(+)

 diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
 index 22cd11a..b27aab8 100644
 --- a/arch/arm/imx-common/iomux-v3.c
 +++ b/arch/arm/imx-common/iomux-v3.c
 @@ -77,3 +77,28 @@ void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const 
 *pad_list,
   p += stride;
   }
  }
 +
 +/*
 + * Configure the IOMUX General Purpose Registers.
 + *
 + * @group, which gpr register to configure.
 + * @start_bit, the first bit to set
 + * @num_bits, how many bits to set
 + * @value, the value will be set to [start_bits...start_bits+num_bits-1]
 + */
 +void mxc_iomux_set_gpr_register(int group, int start_bit, int num_bits,
 + int value)
 +{
 + int i = 0;
 + u32 reg;
 +
 + reg = readl(base + group * 4);
 + while (num_bits) {
 + reg = ~(1  (start_bit + i));
 + i++;
 + num_bits--;
 + }
 +
 + reg |= (value  start_bit);
 + writel(reg, base + group * 4);
 +}
This function is already in my previous patch 
(http://patchwork.ozlabs.org/patch/405013/). The function name is changed to 
imx_iomux_set_gpr_register. 

 

Best regards,

Ye Li

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

Re: [U-Boot] [PATCH 1/5] imx:mx6sxsabresd add usb support

[Li Ye-B37916]

Hi Peng,

On 11/1/2014 10:19 AM, Peng Fan wrote:
 Add usb support for mx6sxsabresd board.

 Signed-off-by: Peng Fan peng@freescale.com
 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  board/freescale/mx6sxsabresd/mx6sxsabresd.c | 29 
 +
  include/configs/mx6sxsabresd.h  | 14 ++
  2 files changed, 43 insertions(+)

 diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
 b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
 index 256ea29..016b8e8 100644
 --- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
 +++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
 @@ -296,3 +296,32 @@ int checkboard(void)
  
   return 0;
  }
 +
 +#ifdef CONFIG_USB_EHCI_MX6
 +iomux_v3_cfg_t const usb_otg1_pads[] = {
 + MX6_PAD_GPIO1_IO09__USB_OTG1_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
 + MX6_PAD_GPIO1_IO10__ANATOP_OTG1_ID | MUX_PAD_CTRL(NO_PAD_CTRL)
 +};
 +
 +iomux_v3_cfg_t const usb_otg2_pads[] = {
 + MX6_PAD_GPIO1_IO12__USB_OTG2_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
 +};
 +
 +int board_ehci_hcd_init(int port)
 +{
 + switch (port) {
 + case 0:
 + imx_iomux_v3_setup_multiple_pads(usb_otg1_pads,
 +  ARRAY_SIZE(usb_otg1_pads));
 + break;
 + case 1:
 + imx_iomux_v3_setup_multiple_pads(usb_otg2_pads,
 +  ARRAY_SIZE(usb_otg2_pads));
 + break;
 + default:
 + printf(MXC USB port %d not yet supported\n, port);
 + return 1;
 + }
 + return 0;
 +}
 +#endif
 diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
 index e02ea18..8edf187 100644
 --- a/include/configs/mx6sxsabresd.h
 +++ b/include/configs/mx6sxsabresd.h
 @@ -198,6 +198,20 @@
  #define CONFIG_PHYLIB
  #define CONFIG_PHY_ATHEROS
  
 +
 +#define CONFIG_CMD_USB
 +#ifdef CONFIG_CMD_USB
 +#define CONFIG_USB_EHCI
 +#define CONFIG_USB_EHCI_MX6
 +#define CONFIG_USB_STORAGE
 +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 +#define CONFIG_USB_HOST_ETHER
 +#define CONFIG_USB_ETHER_ASIX
 +#define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
 +#define CONFIG_MXC_USB_FLAGS   0
 +#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
 +#endif
 +
  #define CONFIG_CMD_PCI
  #ifdef CONFIG_CMD_PCI
  #define CONFIG_PCI
The OTG power polarity setting in ehci-imx6 driver is opposed with the board 
design. So without changing the polarity setting, we have to use GPIO to 
control the power switch.

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

Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT

[Li Ye-B37916]

Hi Stefano,

On 10/27/2014 7:18 PM, Stefano Babic wrote:
 Hi Ye,

 On 27/10/2014 05:10, Li Ye-B37916 wrote:
 The patch is used to add a choice for GPT clock source to provide high 
 frequency clock.  The configuration CONFIG_MXC_GPT_HCLK is not dependent 
 on the chip version. Even it is i.MX28, it is ok to set the configuration.
 Ok, thanks for clarification.

 The implementation has handled the differences between the chips.
 Most of i.MX6 series supports to use 24Mhz OSC as its high clock source 
 (except MX6Q/D Rev 1.0 and MX6SL).  So for i.MX6, the implementation uses 
 the 24Mhz OSC.
 For others (the time.c only compiles for i.MX5 and i.MX6, so the other is 
 i.MX5),  they don't have 24Mhz OSC source for GPT. When the configuration is 
 set, we use perclk instead.
 It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and
 raise an error at compile time. This configuration is wrong and the
 error should be reported and not hidden at runtime.

No, this configuration is not wrong for MX5. When it is set on MX5, the 
implementation uses preclk as the clock source to generate a high frequency 
GPT.  

 I feel the patch subject need to modify, like add HCLK clock source for 
 GPT, then people may not confuse.
 Agree, do it.

 MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
 so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
 perclk in CCM, so eventually the clock comes from OSC 24Mhz.

 I am trying to understand. The explanation here does not reflect in the
 implementation.  From the implementation, it is possible to set it even
 with wrong revision.
 As explained above, the implementation has handled the differences. Users 
 does not need to care the revision. For example, when the image runs on a  
 MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.

 Anyway, I do not think it is correct to put it as a configuration
 option. This makes that we need different binaries for different
 revisions of the SOC. It should be checked at runtime if the revision is
 correct to set this clock as source. gpt_has_clk_source_osc has a check,
 but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
 Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK 
 can be set in any case.
 Well, but if does not make sense for i.MX5, why do we have to accept it ?

The MX5 can also have a high frequency GPT. The difference is it uses another 
clock source preclk than the 24Mhz OSC used for iMX6.


 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Is this a second version of the patchset ? What are the changes ? Please
 add version number to your patchset and write a history about changes. I
 can suggest to use Simon's patman to post your patches.
 I met a email problem last Friday. I can't get any email from 
 u-boot@lists.denx.de for a long time. So I mistakenly thought
 the first patches are failed and send out second.
 Never mind ;-)

  arch/arm/imx-common/timer.c |   76 
 +--
  1 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
 index c63f78f..f7e49bd 100644
 --- a/arch/arm/imx-common/timer.c
 +++ b/arch/arm/imx-common/timer.c
 @@ -2,7 +2,7 @@
   * (C) Copyright 2007
   * Sascha Hauer, Pengutronix
   *
 - * (C) Copyright 2009 Freescale Semiconductor, Inc.
 + * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
 I have already complain about this. There are a lot of commits after the
 file was merged into u-boot, and a lot of them not directly by
 Freescale. I do not think it is legally correct to change the Copyright.
 Will fix this.
 Thanks

   *
   * SPDX-License-Identifier:   GPL-2.0+
   */
 @@ -12,6 +12,7 @@
  #include div64.h
  #include asm/arch/imx-regs.h
  #include asm/arch/clock.h
 +#include asm/arch/sys_proto.h
  
  /* General purpose timers registers */
  struct mxc_gpt {
 @@ -26,23 +27,60 @@ static struct mxc_gpt *cur_gpt = (struct mxc_gpt 
 *)GPT1_BASE_ADDR;
  
  /* General purpose timers bitfields */
  #define GPTCR_SWR (1  15)   /* Software reset */
 +#define GPTCR_24MEN   (1  10)   /* Enable 24MHz clock input 
 from crystal */
  #define GPTCR_FRR (1  9)/* Freerun / restart */
 -#define GPTCR_CLKSOURCE_32(4  6)/* Clock source */
 +#define GPTCR_CLKSOURCE_32(4  6)/* Clock source 32khz */
 +#define GPTCR_CLKSOURCE_OSC   (5  6)/* Clock source OSC */
 +#define GPTCR_CLKSOURCE_PRE   (1  6)/* Clock source PRECLK 
 */
 +#define GPTCR_CLKSOURCE_MASK (0x7  6)
  #define GPTCR_TEN 1   /* Timer enable */
  
 +#define GPTPR_PRESCALER24M_SHIFT 12
 +#define GPTPR_PRESCALER24M_MASK (0xF  GPTPR_PRESCALER24M_SHIFT)
 +
  DECLARE_GLOBAL_DATA_PTR;
  
 +static inline int gpt_has_clk_source_osc(void)
 +{
 +#if defined(CONFIG_MX6)
 +  if (((is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D

Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT

[Li Ye-B37916]

Hi Stefano,

On 10/24/2014 9:18 PM, Stefano Babic wrote:
 Hi Ye,

 On 24/10/2014 14:32, Ye.Li wrote:
 Introduce a new configuration CONFIG_MXC_GPT_HCLK. When it is set,
 the GPT will use 24Mhz OSC as clock source. Otherwise, the GPT will
 use 32Khz OSC as clock source.

 Since only the GPT on iMX6 series provide the clock source option for
 24Mhz OSC. For other series(MX5), if the configuration is set, the
 perclk will be selected as clock source.
 But if the source option is possible only for i.MX6, why should be
 possible to set it for MX5 ? It should be hidden in the SOC
 configuration and not in board configuration.

The patch is used to add a choice for GPT clock source to provide high 
frequency clock.  The configuration CONFIG_MXC_GPT_HCLK is not dependent on 
the chip version. Even it is i.MX28, it is ok to set the configuration.

The implementation has handled the differences between the chips.
Most of i.MX6 series supports to use 24Mhz OSC as its high clock source (except 
MX6Q/D Rev 1.0 and MX6SL).  So for i.MX6, the implementation uses the 24Mhz OSC.
For others (the time.c only compiles for i.MX5 and i.MX6, so the other is 
i.MX5),  they don't have 24Mhz OSC source for GPT. When the configuration is 
set, we use perclk instead.

I feel the patch subject need to modify, like add HCLK clock source for GPT, 
then people may not confuse.

 MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
 so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
 perclk in CCM, so eventually the clock comes from OSC 24Mhz.

 I am trying to understand. The explanation here does not reflect in the
 implementation.  From the implementation, it is possible to set it even
 with wrong revision.

As explained above, the implementation has handled the differences. Users does 
not need to care the revision. For example, when the image runs on a  MX6Q/D 
Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.

 Anyway, I do not think it is correct to put it as a configuration
 option. This makes that we need different binaries for different
 revisions of the SOC. It should be checked at runtime if the revision is
 correct to set this clock as source. gpt_has_clk_source_osc has a check,
 but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK can 
be set in any case.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Is this a second version of the patchset ? What are the changes ? Please
 add version number to your patchset and write a history about changes. I
 can suggest to use Simon's patman to post your patches.

I met a email problem last Friday. I can't get any email from 
u-boot@lists.denx.de for a long time. So I mistakenly thought
the first patches are failed and send out second.

  arch/arm/imx-common/timer.c |   76 
 +--
  1 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
 index c63f78f..f7e49bd 100644
 --- a/arch/arm/imx-common/timer.c
 +++ b/arch/arm/imx-common/timer.c
 @@ -2,7 +2,7 @@
   * (C) Copyright 2007
   * Sascha Hauer, Pengutronix
   *
 - * (C) Copyright 2009 Freescale Semiconductor, Inc.
 + * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
 I have already complain about this. There are a lot of commits after the
 file was merged into u-boot, and a lot of them not directly by
 Freescale. I do not think it is legally correct to change the Copyright.

Will fix this.

   *
   * SPDX-License-Identifier: GPL-2.0+
   */
 @@ -12,6 +12,7 @@
  #include div64.h
  #include asm/arch/imx-regs.h
  #include asm/arch/clock.h
 +#include asm/arch/sys_proto.h
  
  /* General purpose timers registers */
  struct mxc_gpt {
 @@ -26,23 +27,60 @@ static struct mxc_gpt *cur_gpt = (struct mxc_gpt 
 *)GPT1_BASE_ADDR;
  
  /* General purpose timers bitfields */
  #define GPTCR_SWR   (1  15)   /* Software reset */
 +#define GPTCR_24MEN (1  10)   /* Enable 24MHz clock input from 
 crystal */
  #define GPTCR_FRR   (1  9)/* Freerun / restart */
 -#define GPTCR_CLKSOURCE_32  (4  6)/* Clock source */
 +#define GPTCR_CLKSOURCE_32  (4  6)/* Clock source 32khz */
 +#define GPTCR_CLKSOURCE_OSC (5  6)/* Clock source OSC */
 +#define GPTCR_CLKSOURCE_PRE (1  6)/* Clock source PRECLK */
 +#define GPTCR_CLKSOURCE_MASK (0x7  6)
  #define GPTCR_TEN   1   /* Timer enable */
  
 +#define GPTPR_PRESCALER24M_SHIFT 12
 +#define GPTPR_PRESCALER24M_MASK (0xF  GPTPR_PRESCALER24M_SHIFT)
 +
  DECLARE_GLOBAL_DATA_PTR;
  
 +static inline int gpt_has_clk_source_osc(void)
 +{
 +#if defined(CONFIG_MX6)
 +if (((is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
 + (is_soc_rev(CHIP_REV_1_0)  0))
 +|| is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO)
 +|| is_cpu_type(MXC_CPU_MX6SX))
 

Re: [U-Boot] [PATCH] imximage: Fix the bootdata.size calculation

[Li Ye-B37916]

Hi Stefano,

On 10/22/2014 3:22 PM, Stefano Babic wrote:
 Hi Ye,

 On 22/10/2014 08:39, Ye.Li wrote:
 The bootdata.size should contain the IVT offset part, but the calculation
 in imximage tool does not have. This will cause some data at
 the end of image not be loaded into memory.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  tools/imximage.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/tools/imximage.c b/tools/imximage.c
 index faba238..526b7d4 100644
 --- a/tools/imximage.c
 +++ b/tools/imximage.c
 @@ -587,7 +587,7 @@ static void imximage_set_header(void *ptr, struct stat 
 *sbuf, int ifd,
   *
   * The remaining fraction of a block bytes would not be loaded!
   */
 -*header_size_ptr = ROUND(sbuf-st_size, 4096);
 +*header_size_ptr = ROUND((sbuf-st_size + imximage_ivt_offset), 4096);
  
 Can you help me pointing which part of the manual(s) is describing this
 ? Checking into i.MX6Q, length is defined as size of the program image,
 that means without IVT. I have not yet checked into MX53.

 Which is the use case you find the error ? Do you had a size of exactly
 a multiple of 4K and have you discover that the whole image was not loaded ?

 Best regards,
 Stefano Babic


You can look into the Figure 8-21. Image Vector Table in the system boot 
chapter of i.MX6Q manual. The bootdata.start points
to the beginning of the destination memory, which means the bootdata.size 
should have IVT offset included.  We also have checked
the boot rom codes for this.

We found this issue when booting from QSPI NOR on i.MX6SX. The u-boot runs into 
abnormal (crash or stop) after booting.  We checked the
destination memory where the image is loaded to, and found hundreds of bytes at 
the image end are not loaded into memory. Since there
is a 4096 bytes round in the calculation, so the image size decides if the 
issue can be reproduced. It is not easy to see the issue by SD boot.

Best regards,
Ye Li

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

Re: [U-Boot] [PATCH] imximage: Fix the bootdata.size calculation

[Li Ye-B37916]

Hi Stefano,

On 10/22/2014 4:14 PM, Stefano Babic wrote:
 Hi Ye,

 On 22/10/2014 09:38, Li Ye-B37916 wrote:

 You can look into the Figure 8-21. Image Vector Table in the system boot 
 chapter of i.MX6Q manual. The bootdata.start points
 to the beginning of the destination memory, which means the bootdata.size 
 should have IVT offset included.
 Well, ok, this is an interpretation

  We also have checked
 the boot rom codes for this.
 ok - this is the most important thing. Is it the same for all MX6 and
 MX53 ?

Yes. This is same for all MX6 and MX53.


 We found this issue when booting from QSPI NOR on i.MX6SX. The u-boot runs 
 into abnormal (crash or stop) after booting.  We checked the
 destination memory where the image is loaded to, and found hundreds of bytes 
 at the image end are not loaded into memory. Since there
 is a 4096 bytes round in the calculation, so the image size decides if the 
 issue can be reproduced. It is not easy to see the issue by SD boot.
 ok - the only thing that it looks weird is that the issue happens now
 and not with a MX6Q(D) booting from SPI-NOR. There are several boards
 booting from SPI, but I have not heard about such as problems.

 Best regards,
 Stefano Babic


There are some reasons:
1. The SPI-NOR IVT offset is 0x400, but QSPI-NOR IVT offset is 0x1000.  Because 
of the 0x1000 round, the possibility of showing the issue on SPI-NOR is less 
than QSPI-NOR.  Even for QSPI-NOR, we only
reproduce it on some image with particular size .

2. The IVT_offset was once included in the calculation before this patch 
2013-08-31 Stefano Babictools: imx_header should not include 
flash_offset.

3. At the end of the image, most of data are zero.

Best regards,
Ye Li

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

Re: [U-Boot] [PATCH] imx: mx6 sabreauto: Add board support for USB EHCI

[Li Ye-B37916]

On 10/10/2014 7:46 PM, Fabio Estevam wrote:
 On Fri, Oct 10, 2014 at 6:01 AM, Ye.Li b37...@freescale.com wrote:
 On mx6 sabreauto board, there are two USB ports:
 0: OTG
 1: HOST
 The EHCI driver is enabled for this board, but the IOMUX and VBUS power
 control is not implemented, which cause both USB port failed to work.
 This patch fix the problem by adding the BSP support.
 BSP is a broad term here.

 Since the power control uses the GPIO pin from port expander MAX7310,
 the PCA953X driver is enabled for accessing the MAX7310.

 The ID pin of OTG Port needs to configure the GPR1 bit 13 for selecting
 its daisy chain. Add a new function imx_iomux_set_gpr_register to
 handle GPR register setting.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  arch/arm/imx-common/iomux-v3.c|   17 +-
  arch/arm/include/asm/imx-common/iomux-v3.h|7 ++-
  board/freescale/mx6qsabreauto/mx6qsabreauto.c |   89 
 -
  include/configs/mx6qsabreauto.h   |5 +-
  4 files changed, 114 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
 index 22cd11a..2d96655 100644
 --- a/arch/arm/imx-common/iomux-v3.c
 +++ b/arch/arm/imx-common/iomux-v3.c
 @@ -4,7 +4,7 @@
   * Copyright (C) 2009 by Jan Weitzel Phytec Messtechnik GmbH,
   *   armli...@phytec.de
   *
 - * Copyright (C) 2004-2011 Freescale Semiconductor, Inc.
 + * Copyright (C) 2004-2014 Freescale Semiconductor, Inc.
 I don't see the need for changing the copyright everytime you touch a
 file. Same apply to other files in this patch.

 +static int port_exp_direction_output(unsigned gpio, int value)
 +{
 +   int ret;
 +
 +   i2c_set_bus_num(2);
 +   if (i2c_probe(PORTEXP_IO_TO_CHIP(gpio)))
 +   return -ENXIO;
 Would be better like this:

 ret = i2c_probe(PORTEXP_IO_TO_CHIP(gpio))
 if (ret)
 return ret;

 +
 +   ret = pca953x_set_dir(PORTEXP_IO_TO_CHIP(gpio),
 +   (1  PORTEXP_IO_TO_PIN(gpio)),
 +   (PCA953X_DIR_OUT  PORTEXP_IO_TO_PIN(gpio)));
 Here you can do:

 if (ret)
   return ret;

 +
 +   if (!ret)
 Then you don't need to check for !ret here

 +   ret = pca953x_set_val(PORTEXP_IO_TO_CHIP(gpio),
 +   (1  PORTEXP_IO_TO_PIN(gpio)),
 +   (value  PORTEXP_IO_TO_PIN(gpio)));
 +
 +   if (ret)
 +   ret = -EIO;
 +
 +   return ret;
 +}
 if (ret)
return ret;

 return 0;

 +int board_ehci_hcd_init(int port)
 +{
 +   switch (port) {
 +   case 0:
 +   imx_iomux_v3_setup_multiple_pads(usb_otg_pads,
 +   ARRAY_SIZE(usb_otg_pads));
 +
 +   /*set daisy chain for otg_pin_id on 6q. for 6dl, this bit is 
 reserved*/
 +   imx_iomux_set_gpr_register(1, 13, 1, 0);
 +   break;
 +   case 1:
 +   break;
 +   default:
 +   printf(MXC USB port %d not yet supported\n, port);
 +   return 1;
 return -EINVAL;

 +int board_ehci_power(int port, int on)
 +{
 +   switch (port) {
 +   case 0:
 +   if (on)
 +   port_exp_direction_output(USB_OTG_PWR, 1);
 +   else
 +   port_exp_direction_output(USB_OTG_PWR, 0);
 +   break;
 +   case 1:
 +   if (on)
 +   port_exp_direction_output(USB_HOST1_PWR, 1);
 +   else
 +   port_exp_direction_output(USB_HOST1_PWR, 0);
 +   break;
 +   default:
 +   printf(MXC USB port %d not yet supported\n, port);
 +   return 1;
 return -EINVAL;

I will update per your comments.

For the copyright, in FSL we are asked to update it when applying any change to 
the file. what's the rule used in community?

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

Re: [U-Boot] [PATCH] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support

[Li Ye-B37916]

On 9/12/2014 4:17 PM, Stefano Babic wrote:
 Hi Ye,

 On 10/09/2014 07:52, Ye.Li wrote:
 Initialize the Pfuze100 at board late init.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  board/freescale/mx6qsabreauto/mx6qsabreauto.c |   52 
 -
  include/configs/mx6qsabreauto.h   |6 +++
  2 files changed, 57 insertions(+), 1 deletions(-)

 diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
 b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 index bfb9b6a..76b024b 100644
 --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
 @@ -1,5 +1,5 @@
  /*
 - * Copyright (C) 2012 Freescale Semiconductor, Inc.
 + * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
   *
   * Author: Fabio Estevam fabio.este...@freescale.com
   *
 @@ -23,6 +23,8 @@
  #include netdev.h
  #include asm/arch/sys_proto.h
  #include i2c.h
 +#include power/pmic.h
 +#include power/pfuze100_pmic.h
  
  DECLARE_GLOBAL_DATA_PTR;
  
 @@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
  
  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
  
 +#define I2C_PMIC1
 +
  int dram_init(void)
  {
  gd-ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
 @@ -259,6 +263,51 @@ int board_init(void)
  return 0;
  }
  
 +static int pfuze_init(void)
 +{
 +struct pmic *p;
 +int ret;
 +unsigned int reg;
 +
 +ret = power_pfuze100_init(I2C_PMIC);
 +if (ret)
 +return ret;
 +
 +p = pmic_get(PFUZE100);
 +ret = pmic_probe(p);
 +if (ret)
 +return ret;
 +
 +pmic_reg_read(p, PFUZE100_DEVICEID, reg);
 +printf(PMIC:  PFUZE100 ID=0x%02x\n, reg);
 +
 +/* Set SW1AB stanby volage to 0.975V */
 +pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
 +reg = ~0x3f;
 +reg |= 0x1b;
 +pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
 +
 +/* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
 +pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
 +reg = ~0xc0;
 +reg |= 0x40;
 +pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
 +
 +/* Set SW1C standby voltage to 0.975V */
 +pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
 +reg = ~0x3f;
 +reg |= 0x1b;
 +pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
 +
 +/* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
 +pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
 +reg = ~0xc0;
 +reg |= 0x40;
 +pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
 +
 +return 0;
 +}
 The initialization, with the exception of VGEN3/VGEN5, is identical to
 the sabresd. Any possibility to improve code and factorize the function
 for sabre* boards ?

 Best regards,
 Stefano Babic

Yes. The pfuze codes are similar on these boards. I will try to factorize the 
function. How about moving the common codes to board/freescale/imx ?

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

Re: [U-Boot] [PATCH v3 1/4] imx: mx6slevk: Add I2C1 support

[Li Ye-B37916]

Hi Stefano,

On 9/12/2014 6:08 PM, Stefano Babic wrote:
 Hi Ye,


 On 11/09/2014 05:13, Ye.Li wrote:
 Add I2C1 pin and pad settings, and enable the MXC I2C driver.

 I see two different topics in this patch:

 1. Add I2C1 pins to mx6sl pins. This is general, and not related to a
 specific board.

 2. Add I2C1 support to 6slevk board, as in subject.

 Please spliut this patch to address ewach related issue.

 Thanks,
 Stefano Babic

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Changes since v1:
 - None

 Changes since v2:
 - None

  arch/arm/include/asm/arch-mx6/mx6sl_pins.h |5 +
  board/freescale/mx6slevk/mx6slevk.c|   26 ++
  include/configs/mx6slevk.h |6 ++
  3 files changed, 37 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h 
 b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
 index 045ccc4..ac84270 100644
 --- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
 +++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
 @@ -34,5 +34,10 @@ enum {
  MX6_PAD_FEC_REF_CLK__FEC_REF_OUT= 
 IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
  MX6_PAD_FEC_RX_ER__GPIO_4_19= 
 IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
  MX6_PAD_FEC_TX_CLK__GPIO_4_21   = 
 IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
 +
 +MX6_PAD_I2C1_SDA__I2C1_SDA  = 
 IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
 +MX6_PAD_I2C1_SDA__GPIO_3_13 = 
 IOMUX_PAD(0x0450, 0x0160, 5, 0x, 0, 0),
 +MX6_PAD_I2C1_SCL__I2C1_SCL  = 
 IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
 +MX6_PAD_I2C1_SCL__GPIO_3_12 = 
 IOMUX_PAD(0x044C, 0x015C, 5, 0x, 0, 0),
  };
  #endif  /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
 diff --git a/board/freescale/mx6slevk/mx6slevk.c 
 b/board/freescale/mx6slevk/mx6slevk.c
 index a990b4c..fedd5c3 100644
 --- a/board/freescale/mx6slevk/mx6slevk.c
 +++ b/board/freescale/mx6slevk/mx6slevk.c
 @@ -13,12 +13,14 @@
  #include asm/arch/sys_proto.h
  #include asm/gpio.h
  #include asm/imx-common/iomux-v3.h
 +#include asm/imx-common/mxc_i2c.h
  #include asm/io.h
  #include linux/sizes.h
  #include common.h
  #include fsl_esdhc.h
  #include mmc.h
  #include netdev.h
 +#include i2c.h
  
  DECLARE_GLOBAL_DATA_PTR;
  
 @@ -37,8 +39,29 @@ DECLARE_GLOBAL_DATA_PTR;
  #define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
  
 +#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
 +PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
 +PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
 +PAD_CTL_ODE | PAD_CTL_SRE_FAST)
 +
  #define ETH_PHY_RESET   IMX_GPIO_NR(4, 21)
  
 +#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
 +
 +/* I2C1 for PMIC */
 +struct i2c_pads_info i2c_pad_info0 = {
 +.sda = {
 +.i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
 +.gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
 +.gp = IMX_GPIO_NR(3, 13),
 +},
 +.scl = {
 +.i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
 +.gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
 +.gp = IMX_GPIO_NR(3, 12),
 +},
 +};
 +
  int dram_init(void)
  {
  gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
 @@ -162,6 +185,9 @@ int board_init(void)
  #ifdef  CONFIG_FEC_MXC
  setup_fec();
  #endif
 +
 +setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info0);
 +
  return 0;
  }
  
 diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
 index 3d05a64..bf5066f 100644
 --- a/include/configs/mx6slevk.h
 +++ b/include/configs/mx6slevk.h
 @@ -60,6 +60,12 @@
  #define CONFIG_PHYLIB
  #define CONFIG_PHY_SMSC
  
 +/* I2C Configs */
 +#define CONFIG_CMD_I2C
 +#define CONFIG_SYS_I2C
 +#define CONFIG_SYS_I2C_MXC
 +#define CONFIG_SYS_I2C_SPEED  10
 +
  /* allow to overwrite serial and ethaddr */
  #define CONFIG_ENV_OVERWRITE
  #define CONFIG_CONS_INDEX   1


I will split this patch to two in v4.

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

Re: [U-Boot] [PATCH v3 3/4] imx: mx6sabresd: Add clear print for pfuze200

[Li Ye-B37916]

Hi Stefano,

On 9/12/2014 6:13 PM, Stefano Babic wrote:
 Hi Ye,

 On 11/09/2014 05:13, Ye.Li wrote:
 Add clear print log to show pfuze200 or pfuze100 found on mx6sabresd.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Changes since v1:
 - None

 Changes since v2:
 - None

  board/freescale/mx6sabresd/mx6sabresd.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
 b/board/freescale/mx6sabresd/mx6sabresd.c
 index 5f65f1b..72d6562 100644
 --- a/board/freescale/mx6sabresd/mx6sabresd.c
 +++ b/board/freescale/mx6sabresd/mx6sabresd.c
 @@ -472,7 +472,8 @@ static int pfuze_init(void)
  return ret;
  
  pmic_reg_read(p, PFUZE100_DEVICEID, reg);
 -printf(PMIC:  PFUZE100 ID=0x%02x\n, reg);
 +printf(PMIC:  PFUZE%s ID=0x%02x\n,
 +((reg  0xf) == 0) ? 100 : 200, reg);
  
  /* Increase VGEN3 from 2.5 to 2.8V */
  pmic_reg_read(p, PFUZE100_VGEN3VOL, reg);

 This is completely unrelated to the series - it can be applied
 independently from the other patches. You do not need to resend this one
 but please send in future patches belonging to the same series if they
 are related to the same issue or to the same set of issues. This
 simplifies review and merging - thanks !

 Acked-by: Stefano Babic sba...@denx.de

 Best regards,
 Stefano Babic


Thanks for your comments. I feel this patch has somewhat relation with others, 
that in 4/4 the pfuze mode setup needs to consider the pfuze chip type. Of 
course, this patch can be applied independently.  I will be more careful about 
the patch set in future.

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

Re: [U-Boot] [PATCH v2 4/4] imx: mx6: Set Pfuze mode to decrease power number for DSM

[Li Ye-B37916]

On 9/11/2014 10:28 AM, Fabio Estevam wrote:
 On Wed, Sep 10, 2014 at 11:25 PM, Ye.Li b37...@freescale.com wrote:
 Set all switches APS mode in normal and PFM mode in standby. So when
 mx6 entering DSM mode, the power number can be decreased. There is
 no impact for mx6 in run mode.

 Changes for boards:
 -mx6 sabreauto
 -mx6 sabresd
 -mx6slevk
 -mx6sxsabresd

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Changes since v1:
 - Correct the return code per Fabio's comments.
 Are you sure about that?

 I still see a lot of return -1 in this patch ;-)
Sorry, my fault. Send out v3 soon.

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

Re: [U-Boot] [PATCH 4/5] iMX6Solo:SABRESD: Add the i.MX6Solo SABRESD board support

[Li Ye-B37916]

On 9/9/2014 7:41 AM, Otavio Salvador wrote:
 On Wed, Sep 3, 2014 at 4:23 AM, Li Ye-B37916 b37...@freescale.com wrote:
 On 9/2/2014 10:06 PM, Fabio Estevam wrote:
 On Tue, Sep 2, 2014 at 3:11 AM, Ye.Li b37...@freescale.com wrote:

  #ifdef CONFIG_SUPPORT_EMMC_BOOT
  #define EMMC_ENV \
 emmcdev=2\0 \
 @@ -146,7 +155,8 @@
 fi;   \
 fi\0 \
 EMMC_ENV  \
 -   mmcargs=setenv bootargs console=${console},${baudrate}  \
 +   smp= CONFIG_SYS_NOSMP \0\
 Why do we need this 'smp' string?
 This nosmp is intended for imx6solo on a SMP kernel, which asks SMP kernel 
 to act as UP kernel.  If kernel supports to detect the uni-processor or 
 multi-processor with cores number from SCU, this parameter is not necessary 
 . But it is nice to have.  How do you think?
 is this a real mx6solo processor on this board, or is it a dual-lite
 that you only wants to use a single core to 'simulate' a solo?


This is a real mx6solo processor on this board. 
Your question reminders me this bootarg is indeed for simulation. In fsl 
release, we provide a feature to simulate the mx6dl for mx6solo. But on a real 
mx6solo board, this bootarg is unnecessary. 

Best regards,
Ye Li

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

Re: [U-Boot] [PATCH 4/5] iMX6Solo:SABRESD: Add the i.MX6Solo SABRESD board support

[Li Ye-B37916]

Hi Fabio,

On 9/9/2014 11:56 AM, Fabio Estevam wrote:
 Hi Ye,

 On Tue, Sep 9, 2014 at 12:35 AM, Li Ye-B37916 b37...@freescale.com wrote:
 This is a real mx6solo processor on this board.
 Your question reminders me this bootarg is indeed for simulation. In fsl 
 release, we provide a feature to simulate the mx6dl for mx6solo. But on a 
 real mx6solo board, this bootarg is unnecessary.
 In this case, let's skip the 'smp' then.

 Thanks
Agree.  Have removed the smp string in v2 patch.

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

Re: [U-Boot] [PATCH v2 3/5] iMX6DL:arm2: Add support for i.MX6DL arm2 DDR3 board

[Li Ye-B37916]

On 9/5/2014 2:43 AM, Otavio Salvador wrote:
 Hello Ye,

 On Thu, Sep 4, 2014 at 11:17 AM, Ye.Li b37...@freescale.com wrote:
 This patch adds the i.MX6DL arm2 board support. The i.MX6DL ARM2
 shared the same board with i.MX6Q ARM2 board since the i.MX6DL is
 pin-pin compatible with i.MX6Q.

 The patch also support the DDR 32-BIT mode option. Please define
 CONFIG_DDR_32BIT in the board configure file to enable DDR 32-BIT
 mode.But due to the board design, it's 64bit DDR buswidth physically,
 so, if you CONFIG_DDR_32BIT, the DDR memory size will be half of it.

 Signed-off-by: Ye.Li b37...@freescale.com
 Your patch short log could be improved for:

 imx: mx6dlarm2: Add support for i.MX6DL arm2 DDR3 board

 This could be reworked on the other patches as well.

 My 2c.

Thanks for your comments. I will rework the short logs in v3.

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

Re: [U-Boot] [PATCH 4/5] iMX6Solo:SABRESD: Add the i.MX6Solo SABRESD board support

[Li Ye-B37916]

On 9/2/2014 10:06 PM, Fabio Estevam wrote:
 On Tue, Sep 2, 2014 at 3:11 AM, Ye.Li b37...@freescale.com wrote:

  #ifdef CONFIG_SUPPORT_EMMC_BOOT
  #define EMMC_ENV \
 emmcdev=2\0 \
 @@ -146,7 +155,8 @@
 fi;   \
 fi\0 \
 EMMC_ENV  \
 -   mmcargs=setenv bootargs console=${console},${baudrate}  \
 +   smp= CONFIG_SYS_NOSMP \0\
 Why do we need this 'smp' string?
This nosmp is intended for imx6solo on a SMP kernel, which asks SMP kernel to 
act as UP kernel.  If kernel supports to detect the uni-processor or 
multi-processor with cores number from SCU, this parameter is not necessary . 
But it is nice to have.  How do you think?

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

Re: [U-Boot] [PATCH 3/5] iMX6DL:SABRESD: Add new DDR script

[Li Ye-B37916]

On 9/2/2014 8:13 PM, Fabio Estevam wrote:
 Hi Ye Li,

 On Tue, Sep 2, 2014 at 3:11 AM, Ye.Li b37...@freescale.com wrote:
 Add specified mx6dl_4x_mt41j128.cfg DDR script for iMX6DLSABRESD board. Not
 share from nitrogen6x. The default boot device also changes to SD card.

 Signed-off-by: Ye.Li b37...@freescale.com
 Thanks for the patch, but I have already sent this one:
 https://patchwork.ozlabs.org/patch/381961/

 Regards,

 Fabio Estevam
I did not notice your patch. Thanks for submit it. I will rework mine.

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

Re: [U-Boot] [PATCH 2/5] iMX6Q:SABREAUTO: Rename the imximage.cfg to mx6q.cfg

[Li Ye-B37916]

On 9/2/2014 10:08 PM, Fabio Estevam wrote:
 On Tue, Sep 2, 2014 at 3:11 AM, Ye.Li b37...@freescale.com wrote:
 Rename the imximage.cfg to mx6q.cfg.
 No function change at all

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  board/freescale/mx6qsabreauto/imximage.cfg |  129 
 
  board/freescale/mx6qsabreauto/mx6q.cfg |  129 
 
 It would be better to use git format -M so that git can detect the file 
 rename.
Ok. Will change to use it in V2 patch.

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

Re: [U-Boot] [PATCH] imximage: Fix imximage IVT bug for EIM-NOR boot

[Li Ye-B37916]

Hi Stefano Babic,

On 8/20/2014 5:44 PM, Stefano Babic wrote:
 Hi Ye,

 On 20/08/2014 10:55, Ye.Li wrote:
 From: Ye.Li ye...@freescale.com

 The load region size of EIM-NOR are defined to 0. For this case,
 the parameter imximage_init_loadsize must be calculated.
 The imximage tool implements the calculation in the imximage_generate
 function, but the following function imximage_set_header resets the value
 and not calculate. This bug cause some fields of IVT head are not
 correct, for example the boot_data and DCD overlay the application area.

 Signed-off-by: Ye.Li b37...@freescale.com
 ---
  tools/imximage.c |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/tools/imximage.c b/tools/imximage.c
 index 18dc051..faba238 100644
 --- a/tools/imximage.c
 +++ b/tools/imximage.c
 @@ -568,6 +568,13 @@ static void imximage_set_header(void *ptr, struct stat 
 *sbuf, int ifd,
  /* Parse dcd configuration file */
  dcd_len = parse_cfg_file(imxhdr, params-imagename);
  
 +if (imximage_version == IMXIMAGE_V2) {
 +if (imximage_init_loadsize  imximage_ivt_offset +
 +sizeof(imx_header_v2_t))
 +imximage_init_loadsize = imximage_ivt_offset +
 +sizeof(imx_header_v2_t);
 +}
 +
 Agree that this must be fixed for NOR flash. I am checking where the fix
 should be done.

 As far as I see, there are multiple entry involved in the computation:

 387   if (imximage_init_loadsize  imximage_ivt_offset)
 388  imximage_init_loadsize = imximage_ivt_offset;

 It seems more logical that the check should be here.

 The other point is:

 #define FLASH_LOADSIZE_NOR  0x0 /* entire image */

 Well, if the comment is correct (with NOR the SOC can load the entire
 image and there is no limit as with other storage), setting it to 0
 has nothing to do with it.
 Then it seems to me clearer something at line 372:

 if (!imximage_init_loadsize  imximage_version == IMXIMAGE_V2)
   imximage_init_loadsize = imximage_ivt_offset +
   sizeof(imx_header_v2_t);

 What do you think ?

 Best regards,
 Stefano Babic




There are two minor impacts if putting the check in the function 
parse_cfg_cmd:

1. The imximage_version must be got before parsing a CMD_BOOT_FROM command. 
This compels the CMD_IMAGE_VERSION preceding the CMD_BOOT_FROM in script.  
imximage_init_loadsize is only needed by V2 version.

2. Since the imximage_generate function already implements post fixing for 
imximage_init_loadsize, this post fixing needs be removed.

Actually, putting the check in the parsing or post the parsing are ok for me. 
Both can resolve the issue.
The comment for FLASH_LOADSIZE_NOR sources from iMX reference manual, it is 
correct.

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

Re: [U-Boot] [PATCH v2 2/2] net: fec_mxc: Do not error out when FEC_TBD_READY

[Li Ye-B37916]

On 8/21/2014 3:57 PM, Stefano Babic wrote:
 Hi,

 On 21/08/2014 07:02, Marek Vasut wrote:
 On Thursday, August 21, 2014 at 06:11:16 AM, Ye Li wrote:
 The TDAR bit is set when the descriptors are all out from TX ring, but the
 descriptor properly is in transmitting not READY.
 I don't quite understand this, can you please rephrase ?
When transmitting data,  FEC internal DMA reads the TX descriptor and move the 
data from the buffer pointed by TX descriptor to FEC internal FIFO. All TX 
descriptors are managed in a ring. 
We found the TDAR is cleared at DMA starting last descriptor of the ring, not 
at DMA having last descriptor finished. So this bit clears earlier than the 
READY bit of last descriptor. The delay is the time for the data sending of 
last descriptor.
 These are two signals,
 and in Ic simulation, we found the TDAR always clear prior than the READY
 bit of last BD. In mx6solox, we use a latest version of FEC IP. It looks
 the intrinsic behave of TDAR bit is changed in this FEC version, not any
 bug in mx6sx.
 OK, so this behavior is isolated to MX6SX and newer. Then any adjustment 
 should 
 focus solely on MX6SX and newer.
 Not really. It looks like that the implementation is suitable for
 current FEC IP, but this does not mean that is correct at all. A
 solution working for all FEC IP versions is surely preferable.
Agree that the solution should cover all FEC IP versions. Thus, to wait all BD 
sent by FEC, we must check not only the TDAR but also the READY bit in last BD.
 There are some solutions for this problem. Which would be acceptable?
 1. Change the TDAR polling to checking the READY bit in BD.
 This would return the cache-grinding, so this is not nice.

 Agree.

 2. Add polling the READY bit of BD after the TDAR polling.
 If this would be isolated to MX6SX only, then that is doable.

 Why not ? On current FEC IP (not MX6SX), this costs only one read of the
 BD register. Only by MX6SX is polled again. This looks to me the best
 solution.

 3. Add a delay after the TDAR polling.
 This is just work.
 Of course, but it is a trick and we have to add some magical number of
 uSec, explaining that with so it works. My preference goes to 2.
The delay time is relevant with the data length and transmit frequency,  this 
is the difficulty.  A long delay decreases the performance.

 Best regards,
 Stefano Babic

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

Re: [U-Boot] [PATCH v4] net: fec_mxc: Poll FEC_TBD_READY after polling TDAR

[Li Ye-B37916]

Hi Marek,

On 8/22/2014 1:18 AM, Marek Vasut wrote:
 On Thursday, August 21, 2014 at 07:10:32 PM, Fabio Estevam wrote:
 When testing the FEC driver on a mx6solox we noticed that the TDAR bit gets
 always cleared prior then the READY bit is set in the last BD, which causes
 FEC transmission to fail.

 As explained by Ye Li:

 The TDAR bit is set when the descriptors are all out from TX ring, but the
 descriptor properly is in transmitting not READY.
 Again, I do not understand this sentence :-(

When transmitting data, FEC internal DMA reads the TX descriptor and move the 
data from the buffer pointed by TX descriptor to FEC internal FIFO. All TX 
descriptors are managed in a ring. 
We found the TDAR is cleared at DMA starting last descriptor of the ring, not 
at DMA having last descriptor finished. So this bit clears earlier than the 
READY bit of last descriptor. The delay is the time for the data sending of 
last descriptor.


 These are two signals,
 and in Ic simulation, we found the TDAR always clear prior than the READY
 bit of last BD.
 And this is the behavior of which version of the FEC IP, the old one or the 
 one present in MX6slx ?


This is the behavior of current FEC IP on mx6sx. For old ones, we did not do 
simulation for them, but it seems the TDAR clear at the last TX descriptor 
finished.


 In mx6solox, we use a latest version of FEC IP. It looks
 the intrinsic behave of TDAR bit is changed in this FEC version, not any
 bug in mx6sx.

 Fix this by polling the READY bit of BD after the TDAR polling, which
 covers the mx6solox case and does not harm for the other SoCs.

 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 [...]

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

Re: [U-Boot] [PATCH v2 1/2] net: fec_mxc: Adjust RX DMA alignment for mx6solox

[Li Ye-B37916]

Hi Fabio,

I feel the name ARCH_DMA_MINALIGN_MX6SX is not good here. Because the 64 
bytes alignment is only required by the DMA engine in FEC controller, not a 
ARCH DMA value.

Best regards,
Ye Li

On 8/21/2014 5:24 AM, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com

 mx6solox has a requirement for 64 bytes alignment for RX DMA transfer.

 Adjust it accordingly.

 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
 Changes since v1:
 - Avoid too many ifdef's by providing a dma_rx_align() funtion as suggested
 by Otavio

  drivers/net/fec_mxc.c | 17 ++---
  1 file changed, 14 insertions(+), 3 deletions(-)

 diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
 index 4cefda4..1a5105e 100644
 --- a/drivers/net/fec_mxc.c
 +++ b/drivers/net/fec_mxc.c
 @@ -28,6 +28,8 @@ DECLARE_GLOBAL_DATA_PTR;
   */
  #define FEC_XFER_TIMEOUT 5000
  
 +#define ARCH_DMA_MINALIGN_MX6SX  64
 +
  #ifndef CONFIG_MII
  #error CONFIG_MII has to be defined!
  #endif
 @@ -267,6 +269,15 @@ static int fec_tx_task_disable(struct fec_priv *fec)
   return 0;
  }
  
 +static int dma_rx_align(void)
 +{
 +#ifdef CONFIG_MX6SX
 + return  ARCH_DMA_MINALIGN_MX6SX;
 +#else
 + return ARCH_DMA_MINALIGN;
 +#endif
 +}
 +
  /**
   * Initialize receive task's buffer descriptors
   * @param[in] fec all we know about the device yet
 @@ -286,7 +297,7 @@ static void fec_rbd_init(struct fec_priv *fec, int count, 
 int dsize)
* Reload the RX descriptors with default values and wipe
* the RX buffers.
*/
 - size = roundup(dsize, ARCH_DMA_MINALIGN);
 + size = roundup(dsize, dma_rx_align());
   for (i = 0; i  count; i++) {
   data = (uint8_t *)fec-rbd_base[i].data_pointer;
   memset(data, 0, dsize);
 @@ -881,9 +892,9 @@ static int fec_alloc_descs(struct fec_priv *fec)
   /* Allocate RX buffers. */
  
   /* Maximum RX buffer size. */
 - size = roundup(FEC_MAX_PKT_SIZE, ARCH_DMA_MINALIGN);
 + size = roundup(FEC_MAX_PKT_SIZE, dma_rx_align());
   for (i = 0; i  FEC_RBD_NUM; i++) {
 - data = memalign(ARCH_DMA_MINALIGN, size);
 + data = memalign(dma_rx_align(), size);
   if (!data) {
   printf(%s: error allocating rxbuf %d\n, __func__, i);
   goto err_ring;

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