[U-Boot] [PATCH] pci: layerscape: enable PCIe config ready

[Zhiqiang Hou]

From: Hou Zhiqiang 

In EP mode, to enable accesses from the Root Complex, the
CONFIG_READY bit must be set, otherwise any config attempts
from the Root Complex will be returned with config retry
status (CRS).

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Minghuan Lian 
---
 drivers/pci/pcie_layerscape.c | 7 +++
 drivers/pci/pcie_layerscape.h | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 90b9fe2..e597a75 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -409,6 +409,11 @@ static void ls_pcie_ep_setup_bars(void *bar_base)
ls_pcie_ep_setup_bar(bar_base, 4, PCIE_BAR4_SIZE);
 }
 
+static void ls_pcie_ep_enable_cfg(struct ls_pcie *pcie)
+{
+   ctrl_writel(pcie, PCIE_CONFIG_READY, PCIE_PF_CONFIG);
+}
+
 static void ls_pcie_setup_ep(struct ls_pcie *pcie)
 {
u32 sriov;
@@ -432,6 +437,8 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie)
ls_pcie_ep_setup_bars(pcie->dbi + PCIE_NO_SRIOV_BAR_BASE);
ls_pcie_ep_setup_atu(pcie);
}
+
+   ls_pcie_ep_enable_cfg(pcie);
 }
 
 static int ls_pcie_probe(struct udevice *dev)
diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
index 1e635ef..0f9d2fe6 100644
--- a/drivers/pci/pcie_layerscape.h
+++ b/drivers/pci/pcie_layerscape.h
@@ -94,8 +94,10 @@
 #define PCIE_LUT_ENTRY_COUNT   32
 
 /* PF Controll registers */
+#define PCIE_PF_CONFIG 0x14
 #define PCIE_PF_VF_CTRL0x7F8
 #define PCIE_PF_DBG0x7FC
+#define PCIE_CONFIG_READY  (1 << 0)
 
 #define PCIE_SRDS_PRTCL(idx)   (PCIE1 + (idx))
 #define PCIE_SYS_BASE_ADDR 0x340
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH] fsl_i2c.c: Fix warning on gcc-6.x

[Heiko Schocher]

Hello Tom,

Am 09.02.2017 um 21:40 schrieb Tom Rini:

With gcc-6.x we see:
drivers/i2c/fsl_i2c.c:86:3: warning: ‘fsl_i2c_speed_map’ defined but not
used [-Wunused-const-variable=]

The easy way to fix this is that since we only use fsl_i2c_speed_map at
all on __M68K__ move the existing guards around slightly.

Reported-by: Thomas Schaefer 
Signed-off-by: Tom Rini 
---
  drivers/i2c/fsl_i2c.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Thanks!

Acked-by: Heiko Schocher 

Do you want to pick up this patch directly, or should I send an i2c pull
request?

bye,
Heiko


diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index e9fbf828f34b..a1406baa87b2 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -53,6 +53,7 @@ static const struct fsl_i2c_base *i2c_base[4] = {

  /* I2C speed map for a DFSR value of 1 */

+#ifdef __M68K__
  /*
   * Map I2C frequency dividers to FDR and DFSR values
   *
@@ -84,7 +85,6 @@ static const struct {
unsigned short divider;
u8 fdr;
  } fsl_i2c_speed_map[] = {
-#ifdef __M68K__
{20, 32}, {22, 33}, {24, 34}, {26, 35},
{28, 0}, {28, 36}, {30, 1}, {32, 37},
{34, 2}, {36, 38}, {40, 3}, {40, 39},
@@ -102,8 +102,8 @@ static const struct {
{1536, 61}, {1792, 62}, {1920, 27}, {2048, 63},
{2304, 28}, {2560, 29}, {3072, 30}, {3840, 31},
{-1, 31}
-#endif
  };
+#endif

  /**
   * Set the I2C bus speed for a given I2C device



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] spi: ich: Configure SPI BIOS parameters

[Bin Meng]

Hi Stefan,

On Thu, Feb 9, 2017 at 5:26 PM, Stefan Roese  wrote:
> Without configuring these registers in the SPI controller, the Linux
> MTD device driver is not able to correctly read/write to the SPI
> NOR chip at all. In fact, the chip is not detected at all.
>
> Signed-off-by: Stefan Roese 
> Cc: Bin Meng 
> Cc: Simon Glass 
> Cc: Jagan Teki 
> ---
> v3:
> - Moved defines from C-file into header file
> - Changed some enum's into macros in ich.h for consistency
> - Used these newly introduced defines
>
> v2:
> - Moved code into the ICH SPI driver as suggested by Simon and Bin
>
>  drivers/spi/ich.c | 18 ++
>  drivers/spi/ich.h | 45 ++---
>  2 files changed, 56 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
> index caf0103dc3..0418455a79 100644
> --- a/drivers/spi/ich.c
> +++ b/drivers/spi/ich.c
> @@ -111,6 +111,17 @@ static int ich9_can_do_33mhz(struct udevice *dev)
> return speed == 1;
>  }
>
> +/*
> + * Configure SPI controller so that the Linux MTD driver can fully
> + * access the SPI NOR chip
> + */
> +static void spi_controller_config(struct ich_spi_priv *ctlr)
> +{
> +   ich_writew(ctlr, SPI_OPTYPE, ctlr->optype);
> +   ich_writel(ctlr, SPI_OPMENU_LOWER, ctlr->opmenu);
> +   ich_writel(ctlr, SPI_OPMENU_UPPER, ctlr->opmenu + sizeof(u32));
> +}
> +
>  static int ich_init_controller(struct udevice *dev,
>struct ich_spi_platdata *plat,
>struct ich_spi_priv *ctlr)
> @@ -172,6 +183,13 @@ static int ich_init_controller(struct udevice *dev,
>
> ich_set_bbar(ctlr, 0);
>
> +   /*
> +* Configure the SPI-NOR controller in a way that the Linux
> +* MTD SPI-NOR device driver has full read-write access to
> +* the SPI-NOR chips
> +*/
> +   spi_controller_config(ctlr);
> +
> return 0;
>  }
>
> diff --git a/drivers/spi/ich.h b/drivers/spi/ich.h
> index bd0a820809..7282181247 100644
> --- a/drivers/spi/ich.h
> +++ b/drivers/spi/ich.h
> @@ -102,13 +102,6 @@ enum {
>  };
>
>  enum {
> -   SPI_OPCODE_TYPE_READ_NO_ADDRESS =   0,
> -   SPI_OPCODE_TYPE_WRITE_NO_ADDRESS =  1,
> -   SPI_OPCODE_TYPE_READ_WITH_ADDRESS = 2,
> -   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS =3
> -};
> -
> -enum {
> ICH_MAX_CMD_LEN = 5,
>  };
>
> @@ -127,6 +120,44 @@ struct spi_trans {
>  #define SPI_OPCODE_WREN0x06
>  #define SPI_OPCODE_FAST_READ   0x0b
>
> +#define SPI_OPCODE_TYPE_READ_NO_ADDRESS0
> +#define SPI_OPCODE_TYPE_WRITE_NO_ADDRESS   1
> +#define SPI_OPCODE_TYPE_READ_WITH_ADDRESS  2
> +#define SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS 3
> +

Thanks for changing this.

> +#define SPI_OPMENU_0   0x01 /* WRSR: Write Status Register */
> +#define SPI_OPTYPE_0   SPI_OPCODE_TYPE_WRITE_NO_ADDRESS
> +
> +#define SPI_OPMENU_1   0x02 /* BYPR: Byte Program */
> +#define SPI_OPTYPE_1   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS
> +
> +#define SPI_OPMENU_2   0x03 /* READ: Read Data */
> +#define SPI_OPTYPE_2   SPI_OPCODE_TYPE_READ_WITH_ADDRESS
> +
> +#define SPI_OPMENU_3   0x05 /* RDSR: Read Status Register */
> +#define SPI_OPTYPE_3   SPI_OPCODE_TYPE_READ_NO_ADDRESS
> +
> +#define SPI_OPMENU_4   0x20 /* SE20: Sector Erase 0x20 */
> +#define SPI_OPTYPE_4   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS
> +
> +#define SPI_OPMENU_5   0x9f /* RDID: Read ID */
> +#define SPI_OPTYPE_5   SPI_OPCODE_TYPE_READ_NO_ADDRESS
> +
> +#define SPI_OPMENU_6   0xd8 /* BED8: Block Erase 0xd8 */
> +#define SPI_OPTYPE_6   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS
> +
> +#define SPI_OPMENU_7   0x0b /* FAST: Fast Read */
> +#define SPI_OPTYPE_7   SPI_OPCODE_TYPE_READ_WITH_ADDRESS
> +

These are SPI flash commands. Should we name them similarly like
SPI_OPCODE_WREN and SPI_OPCODE_FAST_READ?

> +#define SPI_OPTYPE ((SPI_OPTYPE_7 << 14) | (SPI_OPTYPE_6 << 12) | \
> +   (SPI_OPTYPE_5 << 10) | (SPI_OPTYPE_4 <<  8) | \
> +   (SPI_OPTYPE_3 <<  6) | (SPI_OPTYPE_2 <<  4) | \
> +   (SPI_OPTYPE_1 <<  2) | (SPI_OPTYPE_0 <<  0))
> +#define SPI_OPMENU_UPPER ((SPI_OPMENU_7 << 24) | (SPI_OPMENU_6 << 16) | \
> + (SPI_OPMENU_5 <<  8) | (SPI_OPMENU_4 <<  0))
> +#define SPI_OPMENU_LOWER ((SPI_OPMENU_3 << 24) | (SPI_OPMENU_2 << 16) | \
> + (SPI_OPMENU_1 <<  8) | (SPI_OPMENU_0 <<  0))
> +

What if the board mounts a flash with a different SPI flash command
set? Will this work?

>  enum ich_version {
> ICHV_7,
> ICHV_9,
> --

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

Re: [U-Boot] [PATCH v2] Add single register pin controller driver

[Masahiro Yamada]

Hi Felix,

2017-02-09 18:47 GMT+09:00 Felix Brack :
>
>> device_probe()
>
> From 'pinctrl-uclass.c::device_probe()':
>
> ---
> /*
>  * Process pinctrl for everything except the root device, and
>  * continue regardless of the result of pinctrl. Don't process pinctrl
>  * settings for pinctrl devices since the device may not yet be
>  * probed.
>  */
> if (dev->parent && device_get_uclass_id(dev) != UCLASS_PINCTRL)
> pinctrl_select_state(dev, "default");
> ---
>
> The comment says it all. This is where 'periph' originates.


That's right.
Then, the "dev" in device_probe() represents
the peripheral, such as i2c.

Not a pin-config node, like i2c0_pins.


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

[U-Boot] Please pull u-boot-rockchip

[Simon Glass]

Hi Tom,

This includes a board rename and a few other minor changes.


The following changes since commit 21342d4aed6c77a4aa7a5b2579b3c23e21aea31a:

  Merge git://git.denx.de/u-boot-dm (2017-02-08 16:24:44 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git

for you to fetch changes up to 6f2797645562e85c407aab3e9a757bfd61a027fe:

  rockchip: rename miniarm to tinker board (2017-02-09 12:10:59 -0700)


Eddie Cai (1):
  rockchip: rename miniarm to tinker board

Jacob Chen (3):
  rockchip: dts: rk3288: correct sdram setting for miniarm
  rockchip: configs: move env offset to common header
  rockchip: firefly: configs: use spl back to brom

Romain Perier (1):
  rockchip: Enable ETH address randomization for the firefly-rk3288

Simon Glass (1):
  rockchip: Correct MAINTAINER entry for chromebook_minnie

 arch/arm/dts/Makefile  |  2 +-
 arch/arm/dts/rk3288-miniarm.dts| 58
--
 arch/arm/dts/rk3288-tinker.dts | 58
++
 .../{rk3288-miniarm.dtsi => rk3288-tinker.dtsi}|  0
 arch/arm/mach-rockchip/rk3288-board.c  |  2 +-
 arch/arm/mach-rockchip/rk3288/Kconfig  | 10 ++--
 board/google/veyron/MAINTAINERS|  4 +-
 board/rockchip/miniarm_rk3288/MAINTAINERS  |  6 ---
 .../{miniarm_rk3288 => tinker_rk3288}/Kconfig  |  6 +--
 board/rockchip/tinker_rk3288/MAINTAINERS   |  6 +++
 .../{miniarm_rk3288 => tinker_rk3288}/Makefile |  2 +-
 .../tinker-rk3288.c}   |  0
 configs/firefly-rk3288_defconfig   |  3 +-
 ...rm-rk3288_defconfig => tinker-rk3288_defconfig} |  4 +-
 doc/README.rockchip|  2 +-
 include/configs/evb_rk3288.h   | 14 --
 include/configs/fennec_rk3288.h| 14 --
 include/configs/firefly-rk3288.h   |  5 --
 include/configs/kylin_rk3036.h | 14 --
 include/configs/popmetal_rk3288.h  | 14 --
 include/configs/rock2.h| 14 --
 include/configs/rockchip-common.h  | 14 ++
 .../configs/{miniarm_rk3288.h => tinker_rk3288.h}  | 14 --
 23 files changed, 96 insertions(+), 170 deletions(-)
 delete mode 100644 arch/arm/dts/rk3288-miniarm.dts
 create mode 100644 arch/arm/dts/rk3288-tinker.dts
 rename arch/arm/dts/{rk3288-miniarm.dtsi => rk3288-tinker.dtsi} (100%)
 delete mode 100644 board/rockchip/miniarm_rk3288/MAINTAINERS
 rename board/rockchip/{miniarm_rk3288 => tinker_rk3288}/Kconfig (64%)
 create mode 100644 board/rockchip/tinker_rk3288/MAINTAINERS
 rename board/rockchip/{miniarm_rk3288 => tinker_rk3288}/Makefile (79%)
 rename board/rockchip/{miniarm_rk3288/miniarm-rk3288.c =>
tinker_rk3288/tinker-rk3288.c} (100%)
 rename configs/{miniarm-rk3288_defconfig => tinker-rk3288_defconfig} (95%)
 rename include/configs/{miniarm_rk3288.h => tinker_rk3288.h} (59%)


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

Re: [U-Boot] [PATCH] x86: Force 32-bit jumps in interrupt handlers

[Bin Meng]

On Fri, Feb 10, 2017 at 10:54 AM, J. Tang  wrote:
> Depending upon the compiler used, IRQ entries could vary in sizes. With
> GCC 5.x, the code generator will use short jumps for some IRQ entries
> but near jumps for others. For example, GCC 5.4.0 generates the
> following:
>
> $ objdump -d interrupt.o
> 
> 0207 :
> 207:   6a 12   push   $0x12
> 209:   eb 85   jmp190 
>
> 020b :
> 20b:   6a 13   push   $0x13
> 20d:   eb 81   jmp190 
>
> 020f :
> 20f:   6a 14   push   $0x14
> 211:   e9 7a ff ff ff  jmp190 
>
> 0216 :
> 216:   6a 15   push   $0x15
> 218:   e9 73 ff ff ff  jmp190 
>
> This causes a problem in cpu_init_interrupts(), because the IDT setup
> assumed same sizes for all IRQ entries. GCC 4.x always generated 32-bit
> jumps, so this previously was not a problem.
>
> The fix is to force 32-bit near jumps for all entries within the
> inline assembly. This works for GCC 5.x, and 4.x was already using
> that form of jumping.
>
> Signed-off-by: Jason Tang 
> ---
>  arch/x86/cpu/i386/interrupt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

Re: [U-Boot] [PATCH v2 5/5] configs: dra7xx_evm: Enable SPL_DM

[Tom Rini]

On Thu, Feb 09, 2017 at 09:30:12AM +0530, Lokesh Vutla wrote:

> Enable SPL_DM on all DRA7 based platforms.
> 
> Signed-off-by: Lokesh Vutla 
[snip]
> +++ b/include/configs/ti_omap5_common.h
> @@ -45,7 +45,7 @@
>   * Hardware drivers
>   */
>  #define CONFIG_SYS_NS16550_CLK   4800
> -#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_DM_SERIAL)
> +#if !defined(CONFIG_DM_SERIAL)
>  #define CONFIG_SYS_NS16550_SERIAL
>  #define CONFIG_SYS_NS16550_REG_SIZE  (-4)
>  #endif
> @@ -163,14 +163,8 @@
>  #define CONFIG_SPL_NAND_AM33XX_BCH   /* ELM support */
>  #endif
>  
> -/*
> - * Disable MMC DM for SPL build and can be re-enabled after adding
> - * DM support in SPL
> - */
>  #ifdef CONFIG_SPL_BUILD
> -#undef CONFIG_DM_MMC
>  #undef CONFIG_TIMER
> -#undef CONFIG_DM_ETH
>  #endif
>  
>  #endif /* __CONFIG_TI_OMAP5_COMMON_H */

Do you know why we need to disable timer?

-- 
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 v2 3/5] ARM: dts: OMAP5+: Add u-boot specific dtsi

[Tom Rini]

On Thu, Feb 09, 2017 at 09:30:10AM +0530, Lokesh Vutla wrote:

> Add u-boot specific dtsi so that this will be
> included automatically while building dts.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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 v2 4/5] configs: am57xx_evm: Enable SPL_DM

[Tom Rini]

On Thu, Feb 09, 2017 at 09:30:11AM +0530, Lokesh Vutla wrote:

> Enable SPL_DM on all AM57xx based platforms.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  configs/am57xx_evm_defconfig| 7 +--
>  configs/am57xx_hs_evm_defconfig | 5 -
>  include/configs/am57xx_evm.h| 5 -
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
> index e804b02c1e..50717ba65c 100644
> --- a/configs/am57xx_evm_defconfig
> +++ b/configs/am57xx_evm_defconfig
> @@ -6,7 +6,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI_SUPPORT=y
>  CONFIG_ARMV7_LPAE=y
>  CONFIG_SPL_STACK_R_ADDR=0x8200
> -CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
> +CONFIG_DEFAULT_DEVICE_TREE="am572x-idk"

Did you really want to change the default tree?

-- 
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] unused-const-variable warnings in FSL DDR driver

[york sun]

On 02/09/2017 09:17 AM, Thomas Schaefer wrote:
>
>> On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
>>> Hi York,
>>>
>>>
>>>
>>> When compiling latest u-boot with gcc 6.3 compiler, I get several
>>> 'unused-const-variable' warnings in options.c file of FSL DDR driver.
>>> Affected variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g.
>> dual_0S[4]) and warnings could be fixed with the patch applied.
>>>
>>>
>>>
>>> What do you think?
>>
>> Thomas,
>>
>> Thanks for bringing it to my attention. I understand GCC 6 may have more
>> warnings. The proposed patch is OK in logic but it increases the size of code
>> unnecessarily. Can you come up with a different fix?
>>
>> I can come back to check after I finish my work on hand.
>>
>> York
>
> Hi York,
>
> not sure if I understand this correctly, but why is code size increased when 
> these
> variables are not defined? I think code size is decreased instead as these 
> variables
> are no longer defined if not needed.
>
> I also don't see a way to achieve this in a different way as the variables 
> are defined
> differently for DDR2, DDR3 and DDR4.
>
>

Wait a minute, did you generate the patch backward? Your patch shows 
removing "#if CONFIG_DIMM_SLOTS_PER_CTLR==2" which doesn't exist in 
current code. If the logic is reversed, then yes, you are reducing the 
size. Can GCC 6 optimize out the unused data? If yes, maybe we can use 
__maybe_unused to get rid of the warning?

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

[U-Boot] [PATCH] x86: Force 32-bit jumps in interrupt handlers

[J. Tang]

Depending upon the compiler used, IRQ entries could vary in sizes. With
GCC 5.x, the code generator will use short jumps for some IRQ entries
but near jumps for others. For example, GCC 5.4.0 generates the
following:

$ objdump -d interrupt.o

0207 :
207:   6a 12   push   $0x12
209:   eb 85   jmp190 

020b :
20b:   6a 13   push   $0x13
20d:   eb 81   jmp190 

020f :
20f:   6a 14   push   $0x14
211:   e9 7a ff ff ff  jmp190 

0216 :
216:   6a 15   push   $0x15
218:   e9 73 ff ff ff  jmp190 

This causes a problem in cpu_init_interrupts(), because the IDT setup
assumed same sizes for all IRQ entries. GCC 4.x always generated 32-bit
jumps, so this previously was not a problem.

The fix is to force 32-bit near jumps for all entries within the
inline assembly. This works for GCC 5.x, and 4.x was already using
that form of jumping.

Signed-off-by: Jason Tang 
---
 arch/x86/cpu/i386/interrupt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
index a058303..ba576fe 100644
--- a/arch/x86/cpu/i386/interrupt.c
+++ b/arch/x86/cpu/i386/interrupt.c
@@ -28,7 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
".type irq_"#x", @function\n" \
"irq_"#x":\n" \
"pushl $"#x"\n" \
-   "jmp irq_common_entry\n"
+   "jmp.d32 irq_common_entry\n"
 
 static char *exceptions[] = {
"Divide Error",
-- 
2.1.4


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

Re: [U-Boot] [BUG] x86: invalid size calculations in interrupts.c with newer GCC

[Bin Meng]

On Tue, Feb 7, 2017 at 10:51 AM, J. Tang  wrote:
>
>> On 2017-02-06, at 01:35, Bin Meng  wrote:
>>
>> +Simon,
>>
>> I do not have a GCC5 toolchain to test this. I suspect this is only
>> exposed with GCC5, or GCC 5.4? Is there any parameter to control the
>> behavior?
>
> I observed a similar behavior with GCC 5.3.
>
> As an experiment, I disabled CONFIG_CC_OPTIMIZE_FOR_SIZE. This did not change 
> the sizes; the handler for IRQs 0 through 19 were still 4 bytes while the 
> rest were 7 bytes.
>
> Although I am not an expert x86 assembly writer, I was able to force the 
> assembler to generate 32-bit jumps with the following:
>
> diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
> index 5f6cdd3..9917d09 100644
> --- a/arch/x86/cpu/interrupts.c
> +++ b/arch/x86/cpu/interrupts.c
> @@ -32,7 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
> ".type irq_"#x", @function\n" \
> "irq_"#x":\n" \
> "pushl $"#x"\n" \
> -   "jmp irq_common_entry\n"
> +   "jmp.d32 irq_common_entry\n"
>
>  static char *exceptions[] = {
> "Divide Error",
>
> This worked for both GCC 5.4 and 4.9.
>

Looks good. Can you prepare a patch?

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

[U-Boot] [PATCH] ddr:fsl: Fix warnings on gcc-6.x

[Tom Rini]

With gcc-6.x we will see many warnings like:
warning: ‘dual_0S’ defined but not used [-Wunused-const-variable=]

Depending on exactly what DDR choices are or are not enabled when we use
this file.  So we use slightly more exact #ifdef tests in order to
silence the warnings.

Reported-by: Thomas Schaefer 
Cc: York Sun 
Signed-off-by: Tom Rini 
---
 drivers/ddr/fsl/options.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
index d6a8fcb216a4..7f7c16ced6f3 100644
--- a/drivers/ddr/fsl/options.c
+++ b/drivers/ddr/fsl/options.c
@@ -29,10 +29,12 @@ struct dynamic_odt {
unsigned int odt_rtt_wr;
 };
 
-#ifdef CONFIG_SYS_FSL_DDR4
+#if defined(CONFIG_SYS_FSL_DDR4) && defined(CONFIG_DIMM_SLOTS_PER_CTLR)
 /* Quad rank is not verified yet due availability.
  * Replacing 20 OHM with 34 OHM since DDR4 doesn't have 20 OHM option
  */
+#if (CONFIG_DIMM_SLOTS_PER_CTLR == 1) || ((CONFIG_DIMM_SLOTS_PER_CTLR == 2) && 
\
+   defined(CONFIG_FSL_DDR_FIRST_SLOT_QUAD_CAPABLE))
 static const struct dynamic_odt single_Q[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -59,7 +61,9 @@ static const struct dynamic_odt single_Q[4] = {
DDR4_RTT_120_OHM
}
 };
+#endif
 
+#if (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
 static const struct dynamic_odt single_D[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -89,6 +93,8 @@ static const struct dynamic_odt single_S[4] = {
{0, 0, 0, 0},
 };
 
+#elif (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
+
 static const struct dynamic_odt dual_DD[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -235,6 +241,7 @@ static const struct dynamic_odt dual_0S[4] = {
{0, 0, 0, 0}
 
 };
+#endif
 
 static const struct dynamic_odt odt_unknown[4] = {
{   /* cs0 */
@@ -262,7 +269,9 @@ static const struct dynamic_odt odt_unknown[4] = {
DDR4_RTT_OFF
}
 };
-#elif defined(CONFIG_SYS_FSL_DDR3)
+#elif defined(CONFIG_SYS_FSL_DDR3) && defined(CONFIG_DIMM_SLOTS_PER_CTLR)
+#if (CONFIG_DIMM_SLOTS_PER_CTLR == 1) || ((CONFIG_DIMM_SLOTS_PER_CTLR == 2) && 
\
+   defined(CONFIG_FSL_DDR_FIRST_SLOT_QUAD_CAPABLE))
 static const struct dynamic_odt single_Q[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -289,7 +298,9 @@ static const struct dynamic_odt single_Q[4] = {
DDR3_RTT_120_OHM
}
 };
+#endif
 
+#if (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
 static const struct dynamic_odt single_D[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -319,6 +330,8 @@ static const struct dynamic_odt single_S[4] = {
{0, 0, 0, 0},
 };
 
+#elif (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
+
 static const struct dynamic_odt dual_DD[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -465,6 +478,7 @@ static const struct dynamic_odt dual_0S[4] = {
{0, 0, 0, 0}
 
 };
+#endif
 
 static const struct dynamic_odt odt_unknown[4] = {
{   /* cs0 */
@@ -492,14 +506,18 @@ static const struct dynamic_odt odt_unknown[4] = {
DDR3_RTT_OFF
}
 };
-#else  /* CONFIG_SYS_FSL_DDR3 */
+#elif defined(CONFIG_SYS_FSL_DDR2) && defined(CONFIG_DIMM_SLOTS_PER_CTLR)
+#if (CONFIG_DIMM_SLOTS_PER_CTLR == 1) || ((CONFIG_DIMM_SLOTS_PER_CTLR == 2) && 
\
+   defined(CONFIG_FSL_DDR_FIRST_SLOT_QUAD_CAPABLE))
 static const struct dynamic_odt single_Q[4] = {
{0, 0, 0, 0},
{0, 0, 0, 0},
{0, 0, 0, 0},
{0, 0, 0, 0}
 };
+#endif
 
+#if (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
 static const struct dynamic_odt single_D[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -529,6 +547,8 @@ static const struct dynamic_odt single_S[4] = {
{0, 0, 0, 0},
 };
 
+#elif (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
+
 static const struct dynamic_odt dual_DD[4] = {
{   /* cs0 */
FSL_DDR_ODT_OTHER_DIMM,
@@ -676,6 +696,7 @@ static const struct dynamic_odt dual_0S[4] = {
{0, 0, 0, 0}
 
 };
+#endif
 
 static const struct dynamic_odt odt_unknown[4] = {
{   /* cs0 */
-- 
1.9.1

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

Re: [U-Boot] drivers: net: Provide Kconfig menu for PHYLIB

[Tom Rini]

On Thu, Feb 09, 2017 at 10:18:48AM -0800, Alexandru Gagniuc wrote:

> On 02/09/2017 08:28 AM, Joe Hershberger wrote:
> >Hi Alex,
> >Hi Joe
> >https://patchwork.ozlabs.org/patch/724968/ was applied to u-boot-net.git.
> 
> Thanks!
> 
> I see that the name in the committer field got truncated. do you
> know if this is misconfiguration on my side or a patchwork bug?

A little of both?  patchwork has your named saved as just 'Alex'.  We'll
take this off-list and sort it out.

-- 
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] drivers: net: Provide Kconfig menu for PHYLIB

[Joe Hershberger]

Hi Alex,

On Thu, Feb 9, 2017 at 12:18 PM, Alexandru Gagniuc  wrote:
> On 02/09/2017 08:28 AM, Joe Hershberger wrote:
>>
>> Hi Alex,
>> Hi Joe
>> https://patchwork.ozlabs.org/patch/724968/ was applied to u-boot-net.git.
>
>
> Thanks!
>
> I see that the name in the committer field got truncated. do you know if
> this is misconfiguration on my side or a patchwork bug?

I suspect it must be something about your name or email configuration
in git. Patchwork seems to not like something about it. I guess it
could be a patchwork bug, but not sure what it might be.

Cheers,
-Joe

> Alex
>
>
>
>> Thanks!
>> -Joe
>>
> ___
> 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] unused-const-variable warnings in FSL DDR driver

[Tom Rini]

On Thu, Feb 09, 2017 at 05:51:36PM +, york sun wrote:
> On 02/09/2017 09:46 AM, Thomas Schaefer wrote:
> >>>
>  On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
> > Hi York,
> >
> >
> >
> > When compiling latest u-boot with gcc 6.3 compiler, I get several
> > 'unused-const-variable' warnings in options.c file of FSL DDR driver.
> > Affected variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g.
> > dual_0S[4]) and warnings could be fixed with the patch applied.
> >
> >
> >
> > What do you think?
> 
>  Thomas,
> 
>  Thanks for bringing it to my attention. I understand GCC 6 may have
>  more warnings. The proposed patch is OK in logic but it increases the
>  size of code unnecessarily. Can you come up with a different fix?
> 
>  I can come back to check after I finish my work on hand.
> 
>  York
> >>>
> >>> Hi York,
> >>>
> >>> not sure if I understand this correctly, but why is code size
> >>> increased when these variables are not defined? I think code size is
> >>> decreased instead as these variables are no longer defined if not needed.
> >>>
> >>> I also don't see a way to achieve this in a different way as the
> >>> variables are defined differently for DDR2, DDR3 and DDR4.
> >>>
> >>>
> >
> >> Wait a minute, did you generate the patch backward? Your patch shows
> >> removing "#if CONFIG_DIMM_SLOTS_PER_CTLR==2" which doesn't exist in
> >> current code. If the logic is reversed, then yes, you are reducing the 
> >> size. Can
> >> GCC 6 optimize out the unused data? If yes, maybe we can use __maybe_unused
> >> to get rid of the warning?
> >>
> >> York
> >
> > Oops, you are right, sorry for the confusion. Here's the corrected version:
> >
> > diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
> > index d6a8fcb216..d90ed0b6cc 100644
> > --- a/drivers/ddr/fsl/options.c
> > +++ b/drivers/ddr/fsl/options.c
> > @@ -89,6 +89,7 @@ static const struct dynamic_odt single_S[4] = {
> > {0, 0, 0, 0},
> >  };
> >
> > +#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
> >  static const struct dynamic_odt dual_DD[4] = {
> > {   /* cs0 */
> > FSL_DDR_ODT_NEVER,
> > @@ -235,6 +236,7 @@ static const struct dynamic_odt dual_0S[4] = {
> > {0, 0, 0, 0}
> >
> >  };
> > +#endif
> >
> >  static const struct dynamic_odt odt_unknown[4] = {
> > {   /* cs0 */
> > @@ -319,6 +321,7 @@ static const struct dynamic_odt single_S[4] = {
> > {0, 0, 0, 0},
> >  };
> >
> > +#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
> >  static const struct dynamic_odt dual_DD[4] = {
> > {   /* cs0 */
> > FSL_DDR_ODT_NEVER,
> > @@ -465,6 +468,7 @@ static const struct dynamic_odt dual_0S[4] = {
> > {0, 0, 0, 0}
> >
> >  };
> > +#endif
> >
> >  static const struct dynamic_odt odt_unknown[4] = {
> > {   /* cs0 */
> > @@ -529,6 +533,7 @@ static const struct dynamic_odt single_S[4] = {
> > {0, 0, 0, 0},
> >  };
> >
> > +#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
> >  static const struct dynamic_odt dual_DD[4] = {
> > {   /* cs0 */
> > FSL_DDR_ODT_OTHER_DIMM,
> > @@ -676,6 +681,7 @@ static const struct dynamic_odt dual_0S[4] = {
> > {0, 0, 0, 0}
> >
> >  };
> > +#endif
> >
> >  static const struct dynamic_odt odt_unknown[4] = {
> > {   /* cs0 */
> >
> >
> 
> This looks better. Can you check the size before and after this change? 
> I wonder if GCC 6 can optimize out unused const. If it can, we may be 
> able to get away by using __maybe_used and save a lot of #if.
> 
> By the way, please put space around "==" if you want to go this way.

The above isn't quite enough for all cases.  I'm testing a different and
larger patch currently.

-- 
Tom


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

[U-Boot] [PATCH] fsl_i2c.c: Fix warning on gcc-6.x

[Tom Rini]

With gcc-6.x we see:
drivers/i2c/fsl_i2c.c:86:3: warning: ‘fsl_i2c_speed_map’ defined but not
used [-Wunused-const-variable=]

The easy way to fix this is that since we only use fsl_i2c_speed_map at
all on __M68K__ move the existing guards around slightly.

Reported-by: Thomas Schaefer 
Signed-off-by: Tom Rini 
---
 drivers/i2c/fsl_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index e9fbf828f34b..a1406baa87b2 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -53,6 +53,7 @@ static const struct fsl_i2c_base *i2c_base[4] = {
 
 /* I2C speed map for a DFSR value of 1 */
 
+#ifdef __M68K__
 /*
  * Map I2C frequency dividers to FDR and DFSR values
  *
@@ -84,7 +85,6 @@ static const struct {
unsigned short divider;
u8 fdr;
 } fsl_i2c_speed_map[] = {
-#ifdef __M68K__
{20, 32}, {22, 33}, {24, 34}, {26, 35},
{28, 0}, {28, 36}, {30, 1}, {32, 37},
{34, 2}, {36, 38}, {40, 3}, {40, 39},
@@ -102,8 +102,8 @@ static const struct {
{1536, 61}, {1792, 62}, {1920, 27}, {2048, 63},
{2304, 28}, {2560, 29}, {3072, 30}, {3840, 31},
{-1, 31}
-#endif
 };
+#endif
 
 /**
  * Set the I2C bus speed for a given I2C device
-- 
1.9.1

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

Re: [U-Boot] [PATCH v6 0/3] SPL: Add support to boot a partition type

[Marek Vasut]

On 02/09/2017 09:20 PM, Dalon Westergreen wrote:
> This adds support for the spl to seach for and boot from an arbitrary 
>   
> partition type rather then a specific partition number.  When 
>   
> USE_PARTITION_TYPE is enabled, spl will search for the partition type but 
>   
> fallback to the specified partition number.   
>   
>   
>   
> SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION is moved to a Kconfig and header and  
>   
> defconfigs for the affected boards are updated.   
>   
>   
>   
> Changes in V6:
>   
>  -> Fix unneeded backslash
>   
>  -> Move SPL socfpga Kconfig default to selec tin arch/arm/Kconfig
>   
>  -> Split out defconfig changes for affected boards into a separate patch 
> 
> Dalon Westergreen (3):
>   SPL: add support to boot from a partition type
>   SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig
>   SPL: Add board appropriate config for
> SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> 
>  arch/arm/Kconfig |  1 +
>  common/spl/Kconfig   | 32 
>  common/spl/spl_mmc.c | 27 ++-
>  configs/db-88f6820-gp_defconfig  |  1 +
>  configs/kc1_defconfig|  2 ++
>  configs/sniper_defconfig |  2 ++
>  disk/part_dos.c  |  1 +
>  include/configs/db-88f6820-gp.h  |  1 -
>  include/configs/kc1.h|  2 --
>  include/configs/sniper.h |  2 --
>  include/configs/socfpga_common.h |  2 --
>  include/part.h   |  3 +++
>  12 files changed, 60 insertions(+), 16 deletions(-)
> 

Series is

Reviewed-by: Marek Vasut 

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

Re: [U-Boot] unused-const-variable warnings in FSL I2C driver

[Tom Rini]

On Thu, Feb 09, 2017 at 10:42:52AM +, Thomas Schaefer wrote:

> Hi all,
> 
> 
> When compiling latest u-boot with gcc 6.3 for a T1024RDB system, I get a 
> 'unused-const-variable' warning in the FSL I2C driver. Affected variable is 
> fsl_i2c_speed_map.
> 
> I guess this warning can be fixed with the patch applied, but I'm not sure. 
> What do you think?

Close, we can just move the __M68K__ test to cover the entire definition
instead and that ends up being slightly cleaner looking.  Thanks for the
prod!

-- 
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 6/6] arm: am57xx: cl-som-am57x: enable USB commands

[Tom Rini]

On Thu, Feb 09, 2017 at 09:03:07AM +0200, Uri Mashiach wrote:

> Add CONFIG_CMD_USB to the defconfig file.
> 
> Signed-off-by: Uri Mashiach 

Reviewed-by: Tom Rini 

-- 
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 4/6] arm: am57xx: cl-som-am57x: fix USB scan

[Tom Rini]

On Thu, Feb 09, 2017 at 09:02:09AM +0200, Uri Mashiach wrote:

> USB bus scan attempt:

Reviewed-by: Tom Rini 

-- 
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 5/6] arm: am57xx: cl-som-am57x: enable USB storage

[Tom Rini]

On Thu, Feb 09, 2017 at 09:02:38AM +0200, Uri Mashiach wrote:

> Add CONFIG_USB_STORAGE to the defconfig file.
> 
> Signed-off-by: Uri Mashiach 

Reviewed-by: Tom Rini 

-- 
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 3/6] arm: am57xx: cl-som-am57x: invoke clock API to enable/disable clocks

[Tom Rini]

On Thu, Feb 09, 2017 at 09:01:36AM +0200, Uri Mashiach wrote:

> Invoke enable_usb_clocks during board_usb_init and disable_usb_clocks
> during board_usb_exit to enable and disable clocks respectively.
> 
> Modifications:
> * Enable USB clocks in the OMAP version of the function
>   board_usb_init.
> * Disable USB clocks in the OMAP version of the function
>   board_usb_cleanup.
> 
> Signed-off-by: Uri Mashiach 

Reviewed-by: Tom Rini 

-- 
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 1/6] arm: am57xx: cl-som-am57x: fix XHCI registers base address

[Tom Rini]

On Thu, Feb 09, 2017 at 09:00:26AM +0200, Uri Mashiach wrote:

> The following XHCI registers base address are set to OMAP5 values:
> OMAP_XHCI_BASE, OMAP_OCP1_SCP_BASE, OMAP_OTG_WRAPPER_BASE
> 
> Captured crash for "usb start" command:
> --cut--
> => usb start
> starting USB...
> USB0:   data abort
> pc : []  lr : []
> reloc pc : [<8081cd22>]lr : [<8081cb63>]
> sp : fdf42d08  ip : fff9e040 fp : fdf42d50
> r10: fff8a998  r9 : fdf42ef0 r8 : 
> r7 : fdf42d28  r6 : fdf42d2c r5 : fffa5c00  r4 : 
> r3 : 4a02  r2 :  r1 : fdf42e78  r0 : fffa5c00
> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> --cut--
> 
> Fix by adding the CL-SOM-AM57x target to the XHCI registers base address
> ifdef'ery.
> A better fix should be based on a SOC family defines (currently
> missing).

Can you please go add the Kconfig symbols that would be the better
solution please?  Thanks!

-- 
Tom


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

[U-Boot] [PATCH v6 3/3] SPL: Add board appropriate config for SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION

[Dalon Westergreen]

Due to SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION beingmoved to
Kconfig the board defconfigs for db-88f6820-gp_defconfig
kc1_defconfig and sniper_defconfig need to be updated.

Signed-off-by: Dalon Westergreen 
---
 configs/db-88f6820-gp_defconfig | 1 +
 configs/kc1_defconfig   | 2 ++
 configs/sniper_defconfig| 2 ++
 3 files changed, 5 insertions(+)

diff --git a/configs/db-88f6820-gp_defconfig b/configs/db-88f6820-gp_defconfig
index 1347550..fec5e56 100644
--- a/configs/db-88f6820-gp_defconfig
+++ b/configs/db-88f6820-gp_defconfig
@@ -51,3 +51,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
diff --git a/configs/kc1_defconfig b/configs/kc1_defconfig
index d9895d7..ffaaec3 100644
--- a/configs/kc1_defconfig
+++ b/configs/kc1_defconfig
@@ -36,3 +36,5 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_OF_LIBFDT=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=2
diff --git a/configs/sniper_defconfig b/configs/sniper_defconfig
index fbdbc0c..9dd737f 100644
--- a/configs/sniper_defconfig
+++ b/configs/sniper_defconfig
@@ -37,3 +37,5 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_OF_LIBFDT=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=2
-- 
2.7.4

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

[U-Boot] [PATCH v6 2/3] SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig

[Dalon Westergreen]

Added SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig.

Signed-off-by: Dalon Westergreen 

--
Changes in v3:
  -> Split off defconfig changes for db-88f6820-gp_defconfig
 kc1_defconfig and sniper_defconfig into a separate patch
Changes in v2:
  -> Remove SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION from socfpga_common.h
  -> wrong ifdef around mmc_load_image_raw_partition should be
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
---
 arch/arm/Kconfig |  1 +
 common/spl/Kconfig   | 17 -
 common/spl/spl_mmc.c | 12 +++-
 include/configs/db-88f6820-gp.h  |  1 -
 include/configs/kc1.h|  2 --
 include/configs/sniper.h |  2 --
 include/configs/socfpga_common.h |  2 --
 7 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0229800..e84b74e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -633,6 +633,7 @@ config ARCH_SOCFPGA
select ENABLE_ARM_SOC_BOOT0_HOOK
select ARCH_EARLY_INIT_R
select ARCH_MISC_INIT
+   select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 
 config TARGET_CM_T43
bool "Support cm_t43"
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 552b3b7..b45b841 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -96,9 +96,24 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
  Address on the MMC to load U-Boot from, when the MMC is being used
  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
 
+config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+   bool "MMC Raw mode: by partition"
+   depends on SPL
+   help
+ Use a partition for loading U-Boot when using MMC/SD in raw mode.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
+   hex "Partition to use to load U-Boot from"
+   depends on SPL && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+   default 1
+   help
+ Partition on the MMC to load U-Boot from when the MMC is being
+ used in raw mode
+
 config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
bool "MMC raw mode: by partition type"
-   depends on SPL && DOS_PARTITION
+   depends on SPL && DOS_PARTITION && \
+   SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
default y if ARCH_SOCFPGA
help
  Use partition type for specifying U-Boot partition on MMC/SD in
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index fb51fd5..18c1b59 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -150,7 +150,7 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 
boot_device)
return 0;
 }
 
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
struct mmc *mmc, int partition)
 {
@@ -187,13 +187,6 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
return mmc_load_image_raw_sector(spl_image, mmc, info.start);
 #endif
 }
-#else
-#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION -1
-static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
-   struct mmc *mmc, int partition)
-{
-   return -ENOSYS;
-}
 #endif
 
 #ifdef CONFIG_SPL_OS_BOOT
@@ -341,11 +334,12 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
if (!err)
return err;
}
-
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
err = mmc_load_image_raw_partition(spl_image, mmc,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION);
if (!err)
return err;
+#endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
err = mmc_load_image_raw_sector(spl_image, mmc,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
diff --git a/include/configs/db-88f6820-gp.h b/include/configs/db-88f6820-gp.h
index 1fdeedd..cc2bfbe 100644
--- a/include/configs/db-88f6820-gp.h
+++ b/include/configs/db-88f6820-gp.h
@@ -123,7 +123,6 @@
 
 #if CONFIG_SPL_BOOT_DEVICE == SPL_BOOT_SDIO_MMC_CARD
 /* SPL related MMC defines */
-#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 1
 #define CONFIG_SYS_MMC_U_BOOT_OFFS (160 << 10)
 #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_MMC_U_BOOT_OFFS
 #ifdef CONFIG_SPL_BUILD
diff --git a/include/configs/kc1.h b/include/configs/kc1.h
index 33b6a98..fed70f9 100644
--- a/include/configs/kc1.h
+++ b/include/configs/kc1.h
@@ -113,8 +113,6 @@
 #define CONFIG_SPL_LDSCRIPT"arch/arm/mach-omap2/u-boot-spl.lds"
 #define CONFIG_SPL_BOARD_INIT
 
-#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 2
-
 /*
  * Console
  */
diff --git a/include/configs/sniper.h b/include/configs/sniper.h
index 4f8a9f8..06519fb 100644
--- 

[U-Boot] [PATCH v6 1/3] SPL: add support to boot from a partition type

[Dalon Westergreen]

the socfpga bootrom supports mmc booting from either a raw image
starting at 0x0, or from a partition of type 0xa2.  This patch
adds support for locating the boot image in the first type 0xa2
partition found.

Assigned a partition number of -1 will cause a search for a
partition of type CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
and use it to find the u-boot image

Signed-off-by: Dalon Westergreen 

--
Changes in V6:
 - Remove unneeded backslash
Changes in V5:
 - fix styling in if (..) per Tom's request
Changes in V4:
 - Try search for partition type and failover to the defined
   partition number
Changes in V3:
 - Add depends on DOS_PARTITION
 - Ensure that PARTTION_TYPE defaults to non-zero
 - Add ifdef around sys_ind in disk_partition structure
Changes in V2:
 - Merge partition search into single partition function
---
 common/spl/Kconfig   | 17 +
 common/spl/spl_mmc.c | 15 +++
 disk/part_dos.c  |  1 +
 include/part.h   |  3 +++
 4 files changed, 36 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index cf714c2..552b3b7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -96,6 +96,23 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
  Address on the MMC to load U-Boot from, when the MMC is being used
  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
 
+config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
+   bool "MMC raw mode: by partition type"
+   depends on SPL && DOS_PARTITION
+   default y if ARCH_SOCFPGA
+   help
+ Use partition type for specifying U-Boot partition on MMC/SD in
+ raw mode. U-Boot will be loaded from the first partition of this
+ type to be found.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
+   hex "Partition Type on the MMC to load U-Boot from"
+   depends on SPL && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
+   default 0xa2
+   help
+ Partition Type on the MMC to load U-Boot from, when the MMC is being
+ used in raw mode.
+
 config TPL
bool
depends on SPL && SUPPORT_TPL
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 0cd355c..fb51fd5 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -157,6 +157,21 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
disk_partition_t info;
int err;
 
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
+   int type_part;
+   /* Only support MBR so DOS_ENTRY_NUMBERS */
+   for (type_part = 1; type_part <= DOS_ENTRY_NUMBERS; type_part++) {
+   err = part_get_info(mmc_get_blk_desc(mmc), type_part, );
+   if (err)
+   continue;
+   if (info.sys_ind == 
+   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE) {
+   partition = type_part;
+   break;
+   }
+   }
+#endif
+
err = part_get_info(mmc_get_blk_desc(mmc), partition, );
if (err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
diff --git a/disk/part_dos.c b/disk/part_dos.c
index c77d881..7ede15e 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -217,6 +217,7 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
 #if CONFIG_IS_ENABLED(PARTITION_UUIDS)
sprintf(info->uuid, "%08x-%02x", disksig, part_num);
 #endif
+   info->sys_ind = pt->sys_ind;
return 0;
}
 
diff --git a/include/part.h b/include/part.h
index 9d0e20d..b6d1b33 100644
--- a/include/part.h
+++ b/include/part.h
@@ -59,6 +59,9 @@ typedef struct disk_partition {
 #ifdef CONFIG_PARTITION_TYPE_GUID
chartype_guid[37];  /* type GUID as string, if exists   */
 #endif
+#ifdef CONFIG_DOS_PARTITION
+   uchar   sys_ind;/* partition type   */
+#endif
 } disk_partition_t;
 
 /* Misc _get_dev functions */
-- 
2.7.4

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

[U-Boot] [PATCH v6 0/3] SPL: Add support to boot a partition type

[Dalon Westergreen]

This adds support for the spl to seach for and boot from an arbitrary   
partition type rather then a specific partition number.  When   
USE_PARTITION_TYPE is enabled, spl will search for the partition type but   
fallback to the specified partition number. 

SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION is moved to a Kconfig and header and
defconfigs for the affected boards are updated. 

Changes in V6:  
 -> Fix unneeded backslash  
 -> Move SPL socfpga Kconfig default to selec tin arch/arm/Kconfig  
 -> Split out defconfig changes for affected boards into a separate patch 

Dalon Westergreen (3):
  SPL: add support to boot from a partition type
  SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig
  SPL: Add board appropriate config for
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION

 arch/arm/Kconfig |  1 +
 common/spl/Kconfig   | 32 
 common/spl/spl_mmc.c | 27 ++-
 configs/db-88f6820-gp_defconfig  |  1 +
 configs/kc1_defconfig|  2 ++
 configs/sniper_defconfig |  2 ++
 disk/part_dos.c  |  1 +
 include/configs/db-88f6820-gp.h  |  1 -
 include/configs/kc1.h|  2 --
 include/configs/sniper.h |  2 --
 include/configs/socfpga_common.h |  2 --
 include/part.h   |  3 +++
 12 files changed, 60 insertions(+), 16 deletions(-)

-- 
2.7.4

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

[U-Boot] [RFC PATCH] driver: pci: Fix regions for local memory

[York Sun]

When adding local memory to PCI region, gd->ram_size is correct only
if the memory is in one continuous block. In case memory is split
into several banks, each bank should be added separately.

Signed-off-by: York Sun 
CC: Simon Glass 
---
It was spotted when I was rewriting the code to reserve secure memory
and forgot to reduce gd->ram_size. PCIe resumes working after fixing
gd->ram_size. For my case, the memory is split into two banks. So
base + gd->ram_size is not in memory. I don't know how it worked before.
This change seems reasonable without digging into PCI code.

 drivers/pci/pci-uclass.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 3b00e6a..eb80198 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -814,7 +814,22 @@ static int decode_regions(struct pci_controller *hose, 
const void *blob,
pci_set_region(hose->regions + pos, pci_addr, addr, size, type);
}
 
-   /* Add a region for our local memory */
+   /* Add region(s) for our local memory */
+#ifdef CONFIG_NR_DRAM_BANKS
+   for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+   base = gd->bd->bi_dram[i].start;
+   size = gd->bd->bi_dram[i].size;
+   if (gd->pci_ram_top &&
+   gd->pci_ram_top >= base &&
+   gd->pci_ram_top < base + size)
+   size = gd->pci_ram_top - base;
+   if (size) {
+   pci_set_region(hose->regions + hose->region_count++,
+  base, base, size,
+  PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
+   }
+   }
+#else
size = gd->ram_size;
 #ifdef CONFIG_SYS_SDRAM_BASE
base = CONFIG_SYS_SDRAM_BASE;
@@ -823,6 +838,7 @@ static int decode_regions(struct pci_controller *hose, 
const void *blob,
size = gd->pci_ram_top - base;
pci_set_region(hose->regions + hose->region_count++, base, base,
   size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
+#endif
 
return 0;
 }
-- 
2.7.4

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

Re: [U-Boot] Please pull u-boot-video/master

[Tom Rini]

On Thu, Feb 09, 2017 at 08:16:56PM +0100, Anatolij Gustschin wrote:

> Hi Tom,
> 
> The following changes since commit 0ff27d4a94637d4b1937c625d33212375bd118d9:
> 
>   Merge git://git.denx.de/u-boot-mpc85xx (2017-02-01 16:34:36 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master
> 
> for you to fetch changes up to 9b23bafb4f628aca7a2852f097a7b7da66cac6d8:
> 
>   drivers/video/cfb_console.c: Correct "COFNIG_NDS32" typo. (2017-02-03 
> 13:27:23 +0100)
> 

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] omap_hsmmc.c: Fix build warning on non-omap3

[Tom Rini]

On Thu, Feb 09, 2017 at 01:45:12PM -0500, Tom Rini wrote:

> It was incorrect to always include "asm/arch-omap3/mux.h" constantly.
> This introduced warnings on non-omap3 where certain values will conflict
> between the various families.  Conditionally guard the inclusion in
> order to correct the problem.
> 
> Fixes: 6aca17c9b7e8 ("drivers: mmc: omap_hsmmc: Fix IO Buffer on OMAP36xx")
> Signed-off-by: Tom Rini 

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] qemu-x86_64_defconfig: Disable CONFIG_BOARD_EARLY_INIT_F

[Tom Rini]

On Thu, Feb 09, 2017 at 08:53:01AM -0500, Tom Rini wrote:

> The qemu-x86* targets do not want to enable this.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Thu, Feb 09, 2017 at 10:25:32AM -0600, Joe Hershberger wrote:

> Hi Tom,
> 
> The following changes since commit c83a824e62277162ad35f52879b2316902c0eff5:
> 
>   Merge git://git.denx.de/u-boot-fsl-qoriq (2017-02-03 20:33:42 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to a5fd13ad1913d9c66c47666dbedac7703a48e502:
> 
>   net: phy: MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541 (2017-02-08 
> 16:32:58 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [GIT PULL] Please pull u-boot-mmc master

[Tom Rini]

On Thu, Feb 09, 2017 at 08:50:16PM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Could you pull these patches on your master branch?
> These patch are related to pmic and mmc. (Tested buildman.)
> 
> If you are ok, i will send the split PR at next time.
> (One is u-boot-mmc master, other is u-boot-mmc pmic)
> What do you think about? Plz let me know.
> 
> The following changes since commit 21342d4aed6c77a4aa7a5b2579b3c23e21aea31a:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-02-08 16:24:44 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to a0269bb6e891c6c3b984a2f3d6a12c07e244484a:
> 
>   mmc: init mmc block devices on probe (2017-02-09 20:37:06 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Thu, Feb 09, 2017 at 12:38:30AM +0100, Marek Vasut wrote:

> Hi,
> 
> SoCFPGA PR for 2017.03 , I checked with Dinh and it should be OK.
> 
> The following changes since commit c83a824e62277162ad35f52879b2316902c0eff5:
> 
>   Merge git://git.denx.de/u-boot-fsl-qoriq (2017-02-03 20:33:42 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to a45526aaa0ae241f3e1df996fed988a014eeffe8:
> 
>   arm: socfpga: set the mpuclk divider in the Altera group register
> (2017-02-08 02:19:11 +0100)
> 

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] libfdt SWIG build error with Python 3.x

[Joakim Tjernlund]

On Thu, 2017-02-09 at 13:17 +, Ricardo Martins wrote:
> In some Linux distributions (e.g., Arch Linux) the Python binary points to
> Python 3.x instead of Python 2.x. This is an issue when building the libfdt
> SWIG extension, as the generated extension file will be called something
> like _libfdt.cpython-36m-x86_64-linux-gnu.so instead of just _libfdt.so. By
> simply changing python to python2 in tools/Makefile this issue goes away.
> Should I submit a patch to fix this ?

Yes

Please include tools/binman/binman.py too as it has the same problem.
I guess most python programs is python2 only so if you can find
more of them, fix these too.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-video/master

[Anatolij Gustschin]

Hi Tom,

The following changes since commit 0ff27d4a94637d4b1937c625d33212375bd118d9:

  Merge git://git.denx.de/u-boot-mpc85xx (2017-02-01 16:34:36 -0500)

are available in the git repository at:

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

for you to fetch changes up to 9b23bafb4f628aca7a2852f097a7b7da66cac6d8:

  drivers/video/cfb_console.c: Correct "COFNIG_NDS32" typo. (2017-02-03 
13:27:23 +0100)


Robert P. J. Day (1):
  drivers/video/cfb_console.c: Correct "COFNIG_NDS32" typo.

 drivers/video/cfb_console.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Please pull. Thanks!

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

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 08:06 PM, Konstantin Porotchkin wrote:
> 
> 
> On 02/09/2017 07:24 PM, Marek Vasut wrote:
>> On 02/09/2017 05:43 PM, Konstantin Porotchkin wrote:
>>>
>>> On 02/09/2017 06:15 PM, Marek Vasut wrote:
 On 02/09/2017 04:54 PM, Konstantin Porotchkin wrote:
>
> On 02/09/2017 05:36 PM, Marek Vasut wrote:
>> On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:
>>>
>>>
>>> On 02/09/2017 03:37 PM, Marek Vasut wrote:
 On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
> From: Konstantin Porotchkin 
>
> The USB device should linked to VBUS regulator through
 "vbus-supply"
> DTS property.
> This patch adds handling for "vbus-supply" property inside the USB
> device entry for turning on the VBUS regulator upon the host
 adapter
> probe.
>
> Signed-off-by: Konstantin Porotchkin 
> Cc: Stefan Roese 
> Cc: Marek Vasut 
> Cc: Nadav Haklai 
> Cc: Neta Zur Hershkovits 
> Cc: Igal Liberman 
> Cc: Haim Boot 
> ---
> Changes for v5:
> - Extended clocks description in documentation
> - Removed print for regulator not found case
>
>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
> +++
>  drivers/usb/host/Kconfig  |  1 +
>  drivers/usb/host/xhci-mvebu.c | 13 +-
>  3 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644
 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>
> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> new file mode 100644
> index 000..6cc370c
> --- /dev/null
> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> @@ -0,0 +1,29 @@
> +Marvell SOC USB controllers
> +
> +This controller is integrated in Armada 3700/8K.
> +It uses the same properties as a generic XHCI host controller
> +
> +Required properties :
> + - compatible: should be one or more of:
> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx
 SoCs
> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
> + - reg: should contain address and length of the standard XHCI
> +   register set for the device.
> + - interrupts: one XHCI interrupt should be described here.
> +
> +Optional properties:
> + - clocks: reference to a platform clocks that should be
> enabled/configured
> +   upon interface initialization. May not exist on all platforms.

 This is probably block clock then ?

 Otherwise,
 Acked-by: Marek Vasut 
>>> Otherwise the the internal SoC clock does not require
 gating/muxing or
>>> any other configuration for making this USB host adapter running.
>>> Not sure if I understood your question well.
>>
>> Well,  do these clock drive the USB block or do they drive the
 register
>> interface or what ?
> This entry is generic and applicable to all XHCI controllers, so it is
> hard to answer your question.  It supposes to be a clock that drives
 the
> data transfer. It can be directly connected to the internal clock
> generator and divider or pass though an additional gate/mux. In the
 last
> case it can be inhibited or redirected.

 So it's a PHY clock then ? Or XHCI block clock ?

 marvell.xhci-usb.txt probably doesn't contain generic stuff, but
 marvell
 XHCI implementation specific stuff, right ?
>>> No, in this particular case this entry is generic. That is why I
>>> proposed to remove it in the past.
>>> For the purpose of mvebu XHCI driver this entry is not required.
>>> In general and in Marvell case particularly, every unit is driven by
>>> some kind of internal clock.
>>
>> And those internal clock can never ever be gated ? That's some odd
>> design, I would not expect that on an advanced ARM chip ... I guess
>> marvell is not power conscious ? :) The example contradicts what you
>> just said though, it points into some clock module ...
> Yes, it can be gated. It is a gated clock coming from system controller.
> This XHCI driver supports two different SoC families, so the real clock
> names may vary.
> Please help me to understand what is missing in this description?
> Should I add "this clock is a gated unit clock driven by system
> controller" to th description?
> Should I drop this description file and submit it in a separate patch?

Something like "phandle to system controller clock for this block" 

Re: [U-Boot] drivers: net: Provide Kconfig menu for PHYLIB

[Alexandru Gagniuc]

On 02/09/2017 08:28 AM, Joe Hershberger wrote:

Hi Alex,
Hi Joe
https://patchwork.ozlabs.org/patch/724968/ was applied to u-boot-net.git.


Thanks!

I see that the name in the committer field got truncated. do you know if 
this is misconfiguration on my side or a patchwork bug?


Alex



Thanks!
-Joe


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

Re: [U-Boot] [PATCH] drivers: net: phy: atheros: apply the previous register setting for AR8031 to fix the voltage peak issue

[Yung-Ching LIN]

On Wed, Feb 8, 2017 at 10:47 AM, Joe Hershberger
 wrote:
> On Wed, Feb 8, 2017 at 12:26 AM, Sekhar Nori  wrote:
>> On Wednesday 08 February 2017 12:36 AM, Yung-Ching LIN wrote:
>>> On Tue, Feb 7, 2017 at 12:50 AM, Sekhar Nori  wrote:
 On Monday 06 February 2017 11:06 PM, Ken.Lin wrote:

>>> The register setting would turn out to be 0x3D47 on our project boards 
>>> and
>> our signal measurement results show the patch (v2 version,
>> https://patchwork.ozlabs.org/patch/723461/)) could fix the voltage peak 
>> issue.
>>> The proposed solution is to follow the implementation in previous 
>>> commits,
>> which include the reserved bits settings in SerDes Test and System Mode 
>> Control
>> register.

>> So what does the register setting turn out to be with my patch below ?
>>
>> What are the "previous commits" you refer to ?

 Thanks for the references to the commits. You left out answering my
 question about what register settings you see with my patch.

 I have included another patch now with some debug enabled. Can you
 apply this patch to latest u-boot master, run on your board and send me
 the log ? Here is what I see on AM335x EVM-SK:

 U-Boot 2017.03-rc1-00058-g1216f9a0851f (Feb 07 2017 - 13:55:38 +0530)

 CPU  : AM335X-GP rev 1.0
 Model: TI AM335x EVM-SK
 DRAM:  256 MiB
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 reading uboot.env
 ERROR: No USB device found

 at ../drivers/usb/gadget/ether.c:2709/usb_ether_init()
 Net:   ar8031_config: value read back 0x2c47, written: 0x2d47
 eth0: ethernet@4a10
 Hit any key to stop autoboot:  0

 Thanks,
 Sekhar

 ---8<---
 diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
 index b34cdd3d87dc..5c0a36676ce9 100644
 --- a/drivers/net/phy/atheros.c
 +++ b/drivers/net/phy/atheros.c
 @@ -28,12 +28,18 @@ static int ar8021_config(struct phy_device *phydev)

  static int ar8031_config(struct phy_device *phydev)
  {
 +   int regval;
 +
 if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
 phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
 phy_write(phydev, MDIO_DEVAD_NONE, 
 AR803x_PHY_DEBUG_ADDR_REG,
   AR803x_DEBUG_REG_5);
 +   regval = phy_read(phydev, MDIO_DEVAD_NONE,
 + AR803x_PHY_DEBUG_DATA_REG);
 +   printf("%s: value read back 0x%x, written: 0x%x\n",
 +   __func__, regval, regval | 
 AR803x_RGMII_TX_CLK_DLY);
 phy_write(phydev, MDIO_DEVAD_NONE, 
 AR803x_PHY_DEBUG_DATA_REG,
 - AR803x_RGMII_TX_CLK_DLY);
 + regval | AR803x_RGMII_TX_CLK_DLY);
 }

 if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||

>>>
>>>
>>>
>>> Hi ,
>>>
>>> Your patch doesn't work for the issue case on our project board.
>>> I added more debug messages for your reference.
>>>
>>
>> [...]
>>
>>>
>>> U-Boot 2017.03-rc1-00057-gc83a824e62-dirty (Feb 08 2017 - 02:54:43 +0800)
>>>
>>> CPU:   Freescale i.MX6D rev1.5 at 792 MHz
>>> Reset cause: POR
>>> BOARD: General Electric B850v3
>>> I2C:   ready
>>> DRAM:  2 GiB
>>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
>>> SF: Detected n25q32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   eth_init: fec_probe(bd, -1, 4) @ 02188000
>>> fec_mii_setspeed: mii_speed 001a
>>> fec_mdio_read: phy: 04 reg:02 val:0x4d
>>> fec_mdio_read: phy: 04 reg:03 val:0xd074
>>> fec_mii_setspeed: mii_speed 001a
>>> fec_mdio_write: phy: 04 reg:00 val:0x8000
>>> fec_mdio_read: phy: 04 reg:00 val:0x0
>>> fec_mdio_write: phy: 04 reg:0d val:0x7
>>> fec_mdio_write: phy: 04 reg:0e val:0x8016
>>> fec_mdio_write: phy: 04 reg:0d val:0x4007
>>> fec_mdio_write: phy: 04 reg:0e val:0x18
>>> fec_mdio_write: phy: 04 reg:1d val:0x5
>>> fec_mdio_write: phy: 04 reg:1e val:0x100
>>> fec_mdio_write: phy: 04 reg:1d val:0x5
>>> fec_mdio_read: phy: 04 reg:1e val:0x100
>>> ar8031_config check: value read back 0x100, written: 0x100
>>
>> Hmm, so in effect you are forced to use the magic value of 0x3c47 as the
>> reset default when actually it is 0x100 on your board. And there is no
>> backing public documentation on why the reset default should be 0x3c47.
>> And whether it will work for all boards that use this PHY.
>
> Well that's quite unfortunate.
>
>> Thats pretty unmaintainable in my opinion. If this value does not work
>> for the next person that comes along, we will be in trouble again.
>>
>> I guess the best thing that can be done at this point is to use this
>> 

[U-Boot] libfdt SWIG build error with Python 3.x

[Ricardo Martins]

In some Linux distributions (e.g., Arch Linux) the Python binary points to
Python 3.x instead of Python 2.x. This is an issue when building the libfdt
SWIG extension, as the generated extension file will be called something
like _libfdt.cpython-36m-x86_64-linux-gnu.so instead of just _libfdt.so. By
simply changing python to python2 in tools/Makefile this issue goes away.
Should I submit a patch to fix this ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] distro boot on ls2085ardb

[Peter Newton]

> From: york sun
> Sent: Wednesday, February 08, 2017 5:06 PM
> To: Stuart Yoder ; ag...@suse.de; Prabhakar Kushwaha 
> 
> Cc: Peter Newton ; u-boot@lists.denx.de
> Subject: Re: distro boot on ls2085ardb
> 
> On 02/08/2017 02:55 PM, Stuart Yoder wrote:
> > All,
> >
> > The patch Alex submitted to enable distro boot on ls2085ardb sets up a
> > default bootcmd that looks like this:
> >
> >   bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x58070 &&
> >   cp.b $kernel_start $kernel_load $kernel_size &&
> >   bootm $kernel_load || run distro_bootcmd
> >
> > Was there any particular reason to attempt the NOR flash boot first?
> > (Just backwards compatibility?)  That "cp.b" takes a full
> > 30 seconds and seems potentially unnecessary.  I thought the board was
> > hung.
> >
> > We want to support distro boot on all NXP LS* boards, and I'm
> > wondering if it's better to just make running distro_bootcmd the
> > default, and then fall back to NOR flash boot if distro boot fails.
> >
> >   bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x58070 &&
> >   run distro_bootcmd ||
> >   cp.b $kernel_start $kernel_load $kernel_size &&
> >   bootm $kernel_load
> >
> > Thoughts?
> 
> It was for backward compatibility. Even I have pointed out numerous times 
> (internally) that cp.b should not be used for this case, and
> even pointed out how to make a FIT image with load address, the board
> maintainer(s) didn't act. One change I can propose is to drop the "cp.b 
> $kernel_start $kernel_load $kernel_size" and run "bootm
> $kernel_start"
> directly. If it fails, then falls to distro_bootcmd.

I wondered why we needed the cp.b at all.  How do you add the load address to 
fit?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Konstantin Porotchkin]

On 02/09/2017 07:24 PM, Marek Vasut wrote:

On 02/09/2017 05:43 PM, Konstantin Porotchkin wrote:


On 02/09/2017 06:15 PM, Marek Vasut wrote:

On 02/09/2017 04:54 PM, Konstantin Porotchkin wrote:


On 02/09/2017 05:36 PM, Marek Vasut wrote:

On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:



On 02/09/2017 03:37 PM, Marek Vasut wrote:

On 02/09/2017 12:32 PM, kos...@marvell.com wrote:

From: Konstantin Porotchkin 

The USB device should linked to VBUS regulator through

"vbus-supply"

DTS property.
This patch adds handling for "vbus-supply" property inside the USB
device entry for turning on the VBUS regulator upon the host

adapter

probe.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Marek Vasut 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v5:
- Extended clocks description in documentation
- Removed print for regulator not found case

 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
+++
 drivers/usb/host/Kconfig  |  1 +
 drivers/usb/host/xhci-mvebu.c | 13 +-
 3 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644

doc/device-tree-bindings/usb/marvell.xhci-usb.txt


diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000..6cc370c
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,29 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx

SoCs

+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+   register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a platform clocks that should be
enabled/configured
+   upon interface initialization. May not exist on all platforms.


This is probably block clock then ?

Otherwise,
Acked-by: Marek Vasut 

Otherwise the the internal SoC clock does not require

gating/muxing or

any other configuration for making this USB host adapter running.
Not sure if I understood your question well.


Well,  do these clock drive the USB block or do they drive the

register

interface or what ?

This entry is generic and applicable to all XHCI controllers, so it is
hard to answer your question.  It supposes to be a clock that drives

the

data transfer. It can be directly connected to the internal clock
generator and divider or pass though an additional gate/mux. In the

last

case it can be inhibited or redirected.


So it's a PHY clock then ? Or XHCI block clock ?

marvell.xhci-usb.txt probably doesn't contain generic stuff, but marvell
XHCI implementation specific stuff, right ?

No, in this particular case this entry is generic. That is why I
proposed to remove it in the past.
For the purpose of mvebu XHCI driver this entry is not required.
In general and in Marvell case particularly, every unit is driven by
some kind of internal clock.


And those internal clock can never ever be gated ? That's some odd
design, I would not expect that on an advanced ARM chip ... I guess
marvell is not power conscious ? :) The example contradicts what you
just said though, it points into some clock module ...

Yes, it can be gated. It is a gated clock coming from system controller.
This XHCI driver supports two different SoC families, so the real clock 
names may vary.

Please help me to understand what is missing in this description?
Should I add "this clock is a gated unit clock driven by system 
controller" to th description?

Should I drop this description file and submit it in a separate patch?




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

[U-Boot] [PATCH] omap_hsmmc.c: Fix build warning on non-omap3

[Tom Rini]

It was incorrect to always include "asm/arch-omap3/mux.h" constantly.
This introduced warnings on non-omap3 where certain values will conflict
between the various families.  Conditionally guard the inclusion in
order to correct the problem.

Fixes: 6aca17c9b7e8 ("drivers: mmc: omap_hsmmc: Fix IO Buffer on OMAP36xx")
Signed-off-by: Tom Rini 
---
 drivers/mmc/omap_hsmmc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index b63ce565f2bf..7ed532843bca 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -37,8 +37,10 @@
 #include 
 #include 
 #endif
+#ifdef CONFIG_MMC_OMAP36XX_PINS
+#include 
+#endif
 #include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
1.9.1

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

Re: [U-Boot] net: cosmetic: Make the MAC address string less magical

[Joe Hershberger]

Hi oli...@schinagl.nl,

https://patchwork.ozlabs.org/patch/699273/ was applied to u-boot-net.git.

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

Re: [U-Boot] [PATCH v2 02/15] cmd: nand: abstract global variable usage for dm conversion

[Tom Rini]

On Thu, Feb 09, 2017 at 11:51:38AM -0600, Grygorii Strashko wrote:
> Hi Tom,
> 
> On 02/05/2017 07:57 PM, Tom Rini wrote:
> > On Tue, Jan 31, 2017 at 03:37:04PM -0600, Grygorii Strashko wrote:
> > 
> >> From: Mugunthan V N 
> >>
> >> nand_info is used all over the file so abstract it with
> >> get_nand_dev_by_index() which will help for DM conversion.
> >>
> >> Signed-off-by: Mugunthan V N 
> >> Signed-off-by: Grygorii Strashko 
> > 
> > Reviewed-by: Tom Rini 
> > 
> 
> Sry, I've not received your last comment:
> "So this is incomplete and breaks omap3_beagle booting for example, we
> hang during bootup."
> 
> I have one question - was boot tested only with this patch or with whole 
> series?

I tested with up until the TI driver was converted itself.  So... if
this series requires all drivers to have been converted in order to not
hang, then you need to convert all of the drivers to use the helper to
not break bisectability.

-- 
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] unused-const-variable warnings in FSL DDR driver

[york sun]

On 02/09/2017 09:46 AM, Thomas Schaefer wrote:
>>>
 On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
> Hi York,
>
>
>
> When compiling latest u-boot with gcc 6.3 compiler, I get several
> 'unused-const-variable' warnings in options.c file of FSL DDR driver.
> Affected variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g.
> dual_0S[4]) and warnings could be fixed with the patch applied.
>
>
>
> What do you think?

 Thomas,

 Thanks for bringing it to my attention. I understand GCC 6 may have
 more warnings. The proposed patch is OK in logic but it increases the
 size of code unnecessarily. Can you come up with a different fix?

 I can come back to check after I finish my work on hand.

 York
>>>
>>> Hi York,
>>>
>>> not sure if I understand this correctly, but why is code size
>>> increased when these variables are not defined? I think code size is
>>> decreased instead as these variables are no longer defined if not needed.
>>>
>>> I also don't see a way to achieve this in a different way as the
>>> variables are defined differently for DDR2, DDR3 and DDR4.
>>>
>>>
>
>> Wait a minute, did you generate the patch backward? Your patch shows
>> removing "#if CONFIG_DIMM_SLOTS_PER_CTLR==2" which doesn't exist in
>> current code. If the logic is reversed, then yes, you are reducing the size. 
>> Can
>> GCC 6 optimize out the unused data? If yes, maybe we can use __maybe_unused
>> to get rid of the warning?
>>
>> York
>
> Oops, you are right, sorry for the confusion. Here's the corrected version:
>
> diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
> index d6a8fcb216..d90ed0b6cc 100644
> --- a/drivers/ddr/fsl/options.c
> +++ b/drivers/ddr/fsl/options.c
> @@ -89,6 +89,7 @@ static const struct dynamic_odt single_S[4] = {
> {0, 0, 0, 0},
>  };
>
> +#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
>  static const struct dynamic_odt dual_DD[4] = {
> {   /* cs0 */
> FSL_DDR_ODT_NEVER,
> @@ -235,6 +236,7 @@ static const struct dynamic_odt dual_0S[4] = {
> {0, 0, 0, 0}
>
>  };
> +#endif
>
>  static const struct dynamic_odt odt_unknown[4] = {
> {   /* cs0 */
> @@ -319,6 +321,7 @@ static const struct dynamic_odt single_S[4] = {
> {0, 0, 0, 0},
>  };
>
> +#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
>  static const struct dynamic_odt dual_DD[4] = {
> {   /* cs0 */
> FSL_DDR_ODT_NEVER,
> @@ -465,6 +468,7 @@ static const struct dynamic_odt dual_0S[4] = {
> {0, 0, 0, 0}
>
>  };
> +#endif
>
>  static const struct dynamic_odt odt_unknown[4] = {
> {   /* cs0 */
> @@ -529,6 +533,7 @@ static const struct dynamic_odt single_S[4] = {
> {0, 0, 0, 0},
>  };
>
> +#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
>  static const struct dynamic_odt dual_DD[4] = {
> {   /* cs0 */
> FSL_DDR_ODT_OTHER_DIMM,
> @@ -676,6 +681,7 @@ static const struct dynamic_odt dual_0S[4] = {
> {0, 0, 0, 0}
>
>  };
> +#endif
>
>  static const struct dynamic_odt odt_unknown[4] = {
> {   /* cs0 */
>
>

This looks better. Can you check the size before and after this change? 
I wonder if GCC 6 can optimize out unused const. If it can, we may be 
able to get away by using __maybe_used and save a lot of #if.

By the way, please put space around "==" if you want to go this way.

York

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

Re: [U-Boot] net: cosmetic: Do not use magic values for ARP_HLEN

[Joe Hershberger]

Hi oli...@schinagl.nl,

https://patchwork.ozlabs.org/patch/699274/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: ti: Fix dp83867 RGMII_TXID interface path

[Joe Hershberger]

Hi Phil,

https://patchwork.ozlabs.org/patch/704405/ was applied to u-boot-net.git.

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

Re: [U-Boot] [PATCH v2 02/15] cmd: nand: abstract global variable usage for dm conversion

[Grygorii Strashko]

Hi Tom,

On 02/05/2017 07:57 PM, Tom Rini wrote:
> On Tue, Jan 31, 2017 at 03:37:04PM -0600, Grygorii Strashko wrote:
> 
>> From: Mugunthan V N 
>>
>> nand_info is used all over the file so abstract it with
>> get_nand_dev_by_index() which will help for DM conversion.
>>
>> Signed-off-by: Mugunthan V N 
>> Signed-off-by: Grygorii Strashko 
> 
> Reviewed-by: Tom Rini 
> 

Sry, I've not received your last comment:
"So this is incomplete and breaks omap3_beagle booting for example, we
hang during bootup."

I have one question - was boot tested only with this patch or with whole series?

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

Re: [U-Boot] net: designware: Fix for use with current Linux device tree for Meson GX

[Joe Hershberger]

Hi Heiner,

https://patchwork.ozlabs.org/patch/720901/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541

[Joe Hershberger]

Hi John,

https://patchwork.ozlabs.org/patch/704685/ was applied to u-boot-net.git.

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

Re: [U-Boot] unused-const-variable warnings in FSL DDR driver

[Thomas Schaefer]

>>
>>> On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
 Hi York,



 When compiling latest u-boot with gcc 6.3 compiler, I get several 
 'unused-const-variable' warnings in options.c file of FSL DDR driver.
 Affected variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g.
 dual_0S[4]) and warnings could be fixed with the patch applied.



 What do you think?
>>>
>>> Thomas,
>>>
>>> Thanks for bringing it to my attention. I understand GCC 6 may have 
>>> more warnings. The proposed patch is OK in logic but it increases the 
>>> size of code unnecessarily. Can you come up with a different fix?
>>>
>>> I can come back to check after I finish my work on hand.
>>>
>>> York
>>
>> Hi York,
>>
>> not sure if I understand this correctly, but why is code size 
>> increased when these variables are not defined? I think code size is 
>> decreased instead as these variables are no longer defined if not needed.
>>
>> I also don't see a way to achieve this in a different way as the 
>> variables are defined differently for DDR2, DDR3 and DDR4.
>>
>>

>Wait a minute, did you generate the patch backward? Your patch shows
>removing "#if CONFIG_DIMM_SLOTS_PER_CTLR==2" which doesn't exist in
>current code. If the logic is reversed, then yes, you are reducing the size. 
>Can 
>GCC 6 optimize out the unused data? If yes, maybe we can use __maybe_unused
>to get rid of the warning?
>
>York

Oops, you are right, sorry for the confusion. Here's the corrected version:

diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
index d6a8fcb216..d90ed0b6cc 100644
--- a/drivers/ddr/fsl/options.c
+++ b/drivers/ddr/fsl/options.c
@@ -89,6 +89,7 @@ static const struct dynamic_odt single_S[4] = {
{0, 0, 0, 0},
 };

+#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
 static const struct dynamic_odt dual_DD[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -235,6 +236,7 @@ static const struct dynamic_odt dual_0S[4] = {
{0, 0, 0, 0}

 };
+#endif

 static const struct dynamic_odt odt_unknown[4] = {
{   /* cs0 */
@@ -319,6 +321,7 @@ static const struct dynamic_odt single_S[4] = {
{0, 0, 0, 0},
 };

+#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
 static const struct dynamic_odt dual_DD[4] = {
{   /* cs0 */
FSL_DDR_ODT_NEVER,
@@ -465,6 +468,7 @@ static const struct dynamic_odt dual_0S[4] = {
{0, 0, 0, 0}

 };
+#endif

 static const struct dynamic_odt odt_unknown[4] = {
{   /* cs0 */
@@ -529,6 +533,7 @@ static const struct dynamic_odt single_S[4] = {
{0, 0, 0, 0},
 };

+#if (CONFIG_DIMM_SLOTS_PER_CTLR==2)
 static const struct dynamic_odt dual_DD[4] = {
{   /* cs0 */
FSL_DDR_ODT_OTHER_DIMM,
@@ -676,6 +681,7 @@ static const struct dynamic_odt dual_0S[4] = {
{0, 0, 0, 0}

 };
+#endif

 static const struct dynamic_odt odt_unknown[4] = {
{   /* cs0 */


Best regards,
Thomas


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

Re: [U-Boot] net: fec_mxc: Fix corruption of device tree blob

[Joe Hershberger]

Hi Daniel,

https://patchwork.ozlabs.org/patch/722979/ was applied to u-boot-net.git.

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

Re: [U-Boot] decode_regions() function

[Simon Glass]

Hi York,

On 8 February 2017 at 15:56, york sun  wrote:
> On 02/08/2017 02:12 PM, Simon Glass wrote:
>> Hi York,
>>
>> On 8 February 2017 at 14:58, york sun  wrote:
>>> Simon,
>>>
>>> I stumped on this issue when I was rewriting the code to reserve secure
>>> memory. I didn't realize gd->ram_size was used in the driver. I made the
>>> top of memory secure so EL2 code wouldn't be able to access. All of the
>>> sudden my PCI device failed. By reducing the gd->ram_size, PCI works again.
>>>
>>> Can you help me to understand a function in drivers/pci/pci-uclass.c?
>>> Around line 818 in function
>>>
>>> static int decode_regions(struct pci_controller *hose, const void *blob,
>>>int parent_node, int node)
>>>
>>>
>>>  /* Add a region for our local memory */
>>>  size = gd->ram_size;
>>> #ifdef CONFIG_SYS_SDRAM_BASE
>>>  base = CONFIG_SYS_SDRAM_BASE;
>>> #endif
>>>  if (gd->pci_ram_top && gd->pci_ram_top < base + size)
>>>  size = gd->pci_ram_top - base;
>>>  pci_set_region(hose->regions + hose->region_count++, base, base,
>>> size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
>>>
>>>
>>> What would happen if pci_ram_top is not set, and the memory is split
>>> into banks? gd->ram_size would have the total memory, but not in
>>> continuous space. Is adding a single region correct here?
>>
>> It is assuming a simple contiguous memory setup. If it is not
>> contiguous then it isn't right. It would need to add several regions,
>> I suppose.
>>
>
> Simon,
>
> Please see the proposed change below. I did a quick test on LS2080ARDB. PCIe 
> still works.
> For multi-bank case, I am not sure if we should add a single region up to 
> pci_ram_top, or
> continue to add all other banks.
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 3b00e6a..582c039 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -814,7 +814,19 @@ static int decode_regions(struct pci_controller *hose, 
> const void *blob,
> pci_set_region(hose->regions + pos, pci_addr, addr, size, 
> type);
> }
>
> -   /* Add a region for our local memory */
> +   /* Add region(s) for our local memory */
> +#ifdef CONFIG_NR_DRAM_BANKS
> +for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> +   base = gd->bd->bi_dram[i].start;
> +size = gd->bd->bi_dram[i].size;
> +   if (gd->pci_ram_top &&
> +   gd->pci_ram_top >= base &&
> +   gd->pci_ram_top < base + size)
> +   size = gd->pci_ram_top - base;

It seems reasonable to me, but do check that size is > 0.

> +   pci_set_region(hose->regions + hose->region_count++, base, 
> base,
> +  size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
> +   }
> +#else
> size = gd->ram_size;
>  #ifdef CONFIG_SYS_SDRAM_BASE
> base = CONFIG_SYS_SDRAM_BASE;
> @@ -823,6 +835,7 @@ static int decode_regions(struct pci_controller *hose, 
> const void *blob,
> size = gd->pci_ram_top - base;
> pci_set_region(hose->regions + hose->region_count++, base, base,
>size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
> +#endif
>
> return 0;
>  }
>
> York

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

Re: [U-Boot] net: macb: Remove redundant #ifdef CONFIG_DM_ETH

[Joe Hershberger]

Hi Wenyou,

https://patchwork.ozlabs.org/patch/690228/ was applied to u-boot-net.git.

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

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 05:43 PM, Konstantin Porotchkin wrote:
> 
> On 02/09/2017 06:15 PM, Marek Vasut wrote:
>> On 02/09/2017 04:54 PM, Konstantin Porotchkin wrote:
>> >
>> > On 02/09/2017 05:36 PM, Marek Vasut wrote:
>> >> On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:
>> >>>
>> >>>
>> >>> On 02/09/2017 03:37 PM, Marek Vasut wrote:
>>  On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
>> > From: Konstantin Porotchkin 
>> >
>> > The USB device should linked to VBUS regulator through
>> "vbus-supply"
>> > DTS property.
>> > This patch adds handling for "vbus-supply" property inside the USB
>> > device entry for turning on the VBUS regulator upon the host
>> adapter
>> > probe.
>> >
>> > Signed-off-by: Konstantin Porotchkin 
>> > Cc: Stefan Roese 
>> > Cc: Marek Vasut 
>> > Cc: Nadav Haklai 
>> > Cc: Neta Zur Hershkovits 
>> > Cc: Igal Liberman 
>> > Cc: Haim Boot 
>> > ---
>> > Changes for v5:
>> > - Extended clocks description in documentation
>> > - Removed print for regulator not found case
>> >
>> >  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
>> > +++
>> >  drivers/usb/host/Kconfig  |  1 +
>> >  drivers/usb/host/xhci-mvebu.c | 13 +-
>> >  3 files changed, 42 insertions(+), 1 deletion(-)
>> >  create mode 100644
>> doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> >
>> > diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> > b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> > new file mode 100644
>> > index 000..6cc370c
>> > --- /dev/null
>> > +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> > @@ -0,0 +1,29 @@
>> > +Marvell SOC USB controllers
>> > +
>> > +This controller is integrated in Armada 3700/8K.
>> > +It uses the same properties as a generic XHCI host controller
>> > +
>> > +Required properties :
>> > + - compatible: should be one or more of:
>> > +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx
>> SoCs
>> > +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
>> > + - reg: should contain address and length of the standard XHCI
>> > +   register set for the device.
>> > + - interrupts: one XHCI interrupt should be described here.
>> > +
>> > +Optional properties:
>> > + - clocks: reference to a platform clocks that should be
>> > enabled/configured
>> > +   upon interface initialization. May not exist on all platforms.
>> 
>>  This is probably block clock then ?
>> 
>>  Otherwise,
>>  Acked-by: Marek Vasut 
>> >>> Otherwise the the internal SoC clock does not require
>> gating/muxing or
>> >>> any other configuration for making this USB host adapter running.
>> >>> Not sure if I understood your question well.
>> >>
>> >> Well,  do these clock drive the USB block or do they drive the
>> register
>> >> interface or what ?
>> > This entry is generic and applicable to all XHCI controllers, so it is
>> > hard to answer your question.  It supposes to be a clock that drives
>> the
>> > data transfer. It can be directly connected to the internal clock
>> > generator and divider or pass though an additional gate/mux. In the
>> last
>> > case it can be inhibited or redirected.
>>
>> So it's a PHY clock then ? Or XHCI block clock ?
>>
>> marvell.xhci-usb.txt probably doesn't contain generic stuff, but marvell
>> XHCI implementation specific stuff, right ?
> No, in this particular case this entry is generic. That is why I
> proposed to remove it in the past.
> For the purpose of mvebu XHCI driver this entry is not required.
> In general and in Marvell case particularly, every unit is driven by
> some kind of internal clock.

And those internal clock can never ever be gated ? That's some odd
design, I would not expect that on an advanced ARM chip ... I guess
marvell is not power conscious ? :) The example contradicts what you
just said though, it points into some clock module ...


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

Re: [U-Boot] unused-const-variable warnings in FSL DDR driver

[york sun]

On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
> Hi York,
>
>
>
> When compiling latest u-boot with gcc 6.3 compiler, I get several
> ‘unused-const-variable’ warnings in options.c file of FSL DDR driver.
> Affected variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g.
> dual_0S[4]) and warnings could be fixed with the patch applied.
>
>
>
> What do you think?

Thomas,

Thanks for bringing it to my attention. I understand GCC 6 may have more 
warnings. The proposed patch is OK in logic but it increases the size of 
code unnecessarily. Can you come up with a different fix?

I can come back to check after I finish my work on hand.

York

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

Re: [U-Boot] net: phy: Marvell: Use phy_interface_is_rgmii helper function

[Joe Hershberger]

Hi Phil,

https://patchwork.ozlabs.org/patch/705033/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: cosmetic: Define ethernet name length

[Joe Hershberger]

Hi oli...@schinagl.nl,

https://patchwork.ozlabs.org/patch/699278/ was applied to u-boot-net.git.

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

Re: [U-Boot] tools: Allow crc8 to be used

[Joe Hershberger]

Hi oli...@schinagl.nl,

https://patchwork.ozlabs.org/patch/699401/ was applied to u-boot-net.git.

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

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

[Joe Hershberger]

Hi Tom,

The following changes since commit c83a824e62277162ad35f52879b2316902c0eff5:

  Merge git://git.denx.de/u-boot-fsl-qoriq (2017-02-03 20:33:42 -0500)

are available in the git repository at:


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

for you to fetch changes up to a5fd13ad1913d9c66c47666dbedac7703a48e502:

  net: phy: MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541 (2017-02-08 
16:32:58 -0600)


Alex (1):
  drivers: net: Provide Kconfig menu for PHYLIB

Daniel Strnad (1):
  net: fec_mxc: Fix corruption of device tree blob

Heiner Kallweit (1):
  net: designware: Fix for use with current Linux device tree for Meson GX

Joe Hershberger (1):
  net: phy: Improve the Marvell 151x constants

John Haechten (1):
  net: phy: MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541

Mugunthan V N (1):
  net: phy: dp83867: Add support for MAC impedance configuration

Phil Edworthy (5):
  net: phy: ti: Fix dp83867 RGMII_TXID interface path
  net: phy: Fix mask so that we can identify Marvell 88E1518
  net: phy: Add support for Marvell M88E1512
  net: phy: Marvell: Use phy_interface_is_rgmii helper function
  net: phy: vitesse: Fix cis8204 RGMII_ID code

Wenyou Yang (3):
  net: Kconfig: Add CONFIG_MACB option
  net: macb: Add the clock support
  net: macb: Remove redundant #ifdef CONFIG_DM_ETH

oli...@schinagl.nl (6):
  net: cosmetic: Do not use magic values for ARP_HLEN
  net: cosmetic: Make the MAC address string less magical
  net: cosmetic: Define ethernet name length
  net: core: cosmetic: A MAC address is not limited to SROM
  tools: Allow crc8 to be used
  tools: Add tool to add crc8 to a mac address

 arch/arm/dts/dra72-evm-revc.dts |   4 +-
 common/fdt_support.c|   2 +-
 configs/am335x_evm_defconfig|   1 +
 drivers/net/Kconfig |  38 +--
 drivers/net/designware.c|   1 +
 drivers/net/fec_mxc.c   |   1 -
 drivers/net/macb.c  |  44 +++-
 drivers/net/phy/Kconfig |  93 
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/marvell.c   |  63 +++--
 drivers/net/phy/mscc.c  | 508 
 drivers/net/phy/phy.c   |   3 +
 drivers/net/phy/ti.c|  34 ++-
 drivers/net/phy/vitesse.c   |   4 +-
 include/net.h   |  60 +++--
 include/phy.h   |   1 +
 include/u-boot/crc.h|   3 +
 net/eth-uclass.c|  12 +-
 net/eth_common.c|   2 +-
 net/eth_legacy.c|  10 +-
 tools/.gitignore|   1 +
 tools/Makefile  |   5 +
 tools/gen_ethaddr_crc.c |  75 ++
 23 files changed, 872 insertions(+), 94 deletions(-)
 create mode 100644 drivers/net/phy/Kconfig
 create mode 100644 drivers/net/phy/mscc.c
 create mode 100644 tools/gen_ethaddr_crc.c

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

Re: [U-Boot] distro boot on ls2085ardb

[york sun]

On 02/08/2017 06:43 PM, Prabhakar Kushwaha wrote:
>
>> -Original Message-
>> From: york sun
>> Sent: Thursday, February 09, 2017 4:43 AM
>> To: Peter Newton ; Stuart Yoder
>> ; ag...@suse.de; Prabhakar Kushwaha
>> 
>> Cc: u-boot@lists.denx.de
>> Subject: Re: distro boot on ls2085ardb
>>
>> On 02/08/2017 03:08 PM, Peter Newton wrote:
 From: york sun
>>
>> 
>>

 It was for backward compatibility. Even I have pointed out numerous times
>> (internally) that cp.b should not be used for this case, and
 even pointed out how to make a FIT image with load address, the board
 maintainer(s) didn't act. One change I can propose is to drop the "cp.b
>> $kernel_start $kernel_load $kernel_size" and run "bootm
 $kernel_start"
 directly. If it fails, then falls to distro_bootcmd.
>>>
>>> I wondered why we needed the cp.b at all.  How do you add the load address
>> to fit?
>>>
>>
>> FIT image header has load address and entry address. Our SDK didn't fill
>> in load address before (not sure now). If the load address exists, the
>> image(s) would be copied accordingly.
>>
>
> Our SDK provide load address for Kernel and device tree. But it don’t provide 
> load address for file system.
> This means, "its" file should be updated to provide load address of 
> filesystem also?
>

I think so. I have verified this before and sent email to internal team.

There was an issue before concerning loading to high region. It was 
fixed by commit c1913cb7897f77a26791765ef9c3c02b3588f3c1 in Feb 2016. We 
have been using low region for kernel and ramdisk, so this bug didn't 
block us.

Let's take this to internal team for further discussion.

York

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

Re: [U-Boot] unused-const-variable warnings in FSL DDR driver

[Thomas Schaefer]

> On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
>> Hi York,
>>
>>
>>
>> When compiling latest u-boot with gcc 6.3 compiler, I get several 
>> 'unused-const-variable' warnings in options.c file of FSL DDR driver.
>> Affected variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g.
> dual_0S[4]) and warnings could be fixed with the patch applied.
>>
>>
>>
>> What do you think?
>
> Thomas,
>
> Thanks for bringing it to my attention. I understand GCC 6 may have more 
> warnings. The proposed patch is OK in logic but it increases the size of code 
> unnecessarily. Can you come up with a different fix?
>
> I can come back to check after I finish my work on hand.
>
> York

Hi York,

not sure if I understand this correctly, but why is code size increased when 
these
variables are not defined? I think code size is decreased instead as these 
variables
are no longer defined if not needed.

I also don't see a way to achieve this in a different way as the variables are 
defined
differently for DDR2, DDR3 and DDR4.

Best regards,
Thomas

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

Re: [U-Boot] net: Kconfig: Add CONFIG_MACB option

[Joe Hershberger]

Hi Wenyou,

https://patchwork.ozlabs.org/patch/690226/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: Add support for Marvell M88E1512

[Joe Hershberger]

Hi Phil,

https://patchwork.ozlabs.org/patch/705032/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: core: cosmetic: A MAC address is not limited to SROM

[Joe Hershberger]

Hi oli...@schinagl.nl,

https://patchwork.ozlabs.org/patch/699283/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: vitesse: Fix cis8204 RGMII_ID code

[Joe Hershberger]

Hi Phil,

https://patchwork.ozlabs.org/patch/705058/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: Improve the Marvell 151x constants

[Joe Hershberger]

Hi Joe,

https://patchwork.ozlabs.org/patch/704632/ was applied to u-boot-net.git.

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

Re: [U-Boot] tools: Add tool to add crc8 to a mac address

[Joe Hershberger]

Hi oli...@schinagl.nl,

https://patchwork.ozlabs.org/patch/699397/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: Fix mask so that we can identify Marvell 88E1518

[Joe Hershberger]

Hi Phil,

https://patchwork.ozlabs.org/patch/705031/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: phy: dp83867: Add support for MAC impedance configuration

[Joe Hershberger]

Hi Grygorii,

https://patchwork.ozlabs.org/patch/719265/ was applied to u-boot-net.git.

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

Re: [U-Boot] drivers: net: Provide Kconfig menu for PHYLIB

[Joe Hershberger]

Hi Alex,

https://patchwork.ozlabs.org/patch/724968/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: macb: Add the clock support

[Joe Hershberger]

Hi Wenyou,

https://patchwork.ozlabs.org/patch/690227/ was applied to u-boot-net.git.

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

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Konstantin Porotchkin]

On 02/09/2017 06:15 PM, Marek Vasut wrote:

On 02/09/2017 04:54 PM, Konstantin Porotchkin wrote:
>
> On 02/09/2017 05:36 PM, Marek Vasut wrote:
>> On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:
>>>
>>>
>>> On 02/09/2017 03:37 PM, Marek Vasut wrote:
 On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
> From: Konstantin Porotchkin 
>
> The USB device should linked to VBUS regulator through "vbus-supply"
> DTS property.
> This patch adds handling for "vbus-supply" property inside the USB
> device entry for turning on the VBUS regulator upon the host adapter
> probe.
>
> Signed-off-by: Konstantin Porotchkin 
> Cc: Stefan Roese 
> Cc: Marek Vasut 
> Cc: Nadav Haklai 
> Cc: Neta Zur Hershkovits 
> Cc: Igal Liberman 
> Cc: Haim Boot 
> ---
> Changes for v5:
> - Extended clocks description in documentation
> - Removed print for regulator not found case
>
>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
> +++
>  drivers/usb/host/Kconfig  |  1 +
>  drivers/usb/host/xhci-mvebu.c | 13 +-
>  3 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>
> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> new file mode 100644
> index 000..6cc370c
> --- /dev/null
> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> @@ -0,0 +1,29 @@
> +Marvell SOC USB controllers
> +
> +This controller is integrated in Armada 3700/8K.
> +It uses the same properties as a generic XHCI host controller
> +
> +Required properties :
> + - compatible: should be one or more of:
> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
> + - reg: should contain address and length of the standard XHCI
> +   register set for the device.
> + - interrupts: one XHCI interrupt should be described here.
> +
> +Optional properties:
> + - clocks: reference to a platform clocks that should be
> enabled/configured
> +   upon interface initialization. May not exist on all platforms.

 This is probably block clock then ?

 Otherwise,
 Acked-by: Marek Vasut 
>>> Otherwise the the internal SoC clock does not require gating/muxing or
>>> any other configuration for making this USB host adapter running.
>>> Not sure if I understood your question well.
>>
>> Well,  do these clock drive the USB block or do they drive the register
>> interface or what ?
> This entry is generic and applicable to all XHCI controllers, so it is
> hard to answer your question.  It supposes to be a clock that drives the
> data transfer. It can be directly connected to the internal clock
> generator and divider or pass though an additional gate/mux. In the last
> case it can be inhibited or redirected.

So it's a PHY clock then ? Or XHCI block clock ?

marvell.xhci-usb.txt probably doesn't contain generic stuff, but marvell
XHCI implementation specific stuff, right ?

No, in this particular case this entry is generic. That is why I proposed to 
remove it in the past.
For the purpose of mvebu XHCI driver this entry is not required.
In general and in Marvell case particularly, every unit is driven by some kind 
of internal clock.


> + - vbus-supply : If present, specifies the fixed regulator to be
> turned on
> +   for providing power to the USB VBUS rail.
> +
> +Example:
> +cpm_usb3_0: usb3@50 {
> +compatible = "marvell,armada-8k-xhci",
> + "generic-xhci";
> +reg = <0x50 0x4000>;
> +interrupts = ;
> +clocks = <_syscon0 1 22>;
> +vbus-supply = <_usb3h0_vbus>;
> +status = "disabled";
> +};
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 5129a57..0bf8274 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>  bool "MVEBU USB 3.0 support"
>  default y
>  depends on ARCH_MVEBU
> +select DM_REGULATOR
>  help
>Choose this option to add support for USB 3.0 driver on mvebu
>SoCs, which includes Armada8K, Armada3700 and other Armada
> diff --git a/drivers/usb/host/xhci-mvebu.c
> b/drivers/usb/host/xhci-mvebu.c
> index 46eb937..d880af1 100644
> --- a/drivers/usb/host/xhci-mvebu.c
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 04:54 PM, Konstantin Porotchkin wrote:
> 
> On 02/09/2017 05:36 PM, Marek Vasut wrote:
>> On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:
>> >
>> >
>> > On 02/09/2017 03:37 PM, Marek Vasut wrote:
>> >> On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
>> >>> From: Konstantin Porotchkin 
>> >>>
>> >>> The USB device should linked to VBUS regulator through "vbus-supply"
>> >>> DTS property.
>> >>> This patch adds handling for "vbus-supply" property inside the USB
>> >>> device entry for turning on the VBUS regulator upon the host adapter
>> >>> probe.
>> >>>
>> >>> Signed-off-by: Konstantin Porotchkin 
>> >>> Cc: Stefan Roese 
>> >>> Cc: Marek Vasut 
>> >>> Cc: Nadav Haklai 
>> >>> Cc: Neta Zur Hershkovits 
>> >>> Cc: Igal Liberman 
>> >>> Cc: Haim Boot 
>> >>> ---
>> >>> Changes for v5:
>> >>> - Extended clocks description in documentation
>> >>> - Removed print for regulator not found case
>> >>>
>> >>>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
>> >>> +++
>> >>>  drivers/usb/host/Kconfig  |  1 +
>> >>>  drivers/usb/host/xhci-mvebu.c | 13 +-
>> >>>  3 files changed, 42 insertions(+), 1 deletion(-)
>> >>>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> >>>
>> >>> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> >>> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> >>> new file mode 100644
>> >>> index 000..6cc370c
>> >>> --- /dev/null
>> >>> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>> >>> @@ -0,0 +1,29 @@
>> >>> +Marvell SOC USB controllers
>> >>> +
>> >>> +This controller is integrated in Armada 3700/8K.
>> >>> +It uses the same properties as a generic XHCI host controller
>> >>> +
>> >>> +Required properties :
>> >>> + - compatible: should be one or more of:
>> >>> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
>> >>> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
>> >>> + - reg: should contain address and length of the standard XHCI
>> >>> +   register set for the device.
>> >>> + - interrupts: one XHCI interrupt should be described here.
>> >>> +
>> >>> +Optional properties:
>> >>> + - clocks: reference to a platform clocks that should be
>> >>> enabled/configured
>> >>> +   upon interface initialization. May not exist on all platforms.
>> >>
>> >> This is probably block clock then ?
>> >>
>> >> Otherwise,
>> >> Acked-by: Marek Vasut 
>> > Otherwise the the internal SoC clock does not require gating/muxing or
>> > any other configuration for making this USB host adapter running.
>> > Not sure if I understood your question well.
>>
>> Well,  do these clock drive the USB block or do they drive the register
>> interface or what ?
> This entry is generic and applicable to all XHCI controllers, so it is
> hard to answer your question.  It supposes to be a clock that drives the
> data transfer. It can be directly connected to the internal clock
> generator and divider or pass though an additional gate/mux. In the last
> case it can be inhibited or redirected.

So it's a PHY clock then ? Or XHCI block clock ?

marvell.xhci-usb.txt probably doesn't contain generic stuff, but marvell
XHCI implementation specific stuff, right ?

>> >>> + - vbus-supply : If present, specifies the fixed regulator to be
>> >>> turned on
>> >>> +   for providing power to the USB VBUS rail.
>> >>> +
>> >>> +Example:
>> >>> +cpm_usb3_0: usb3@50 {
>> >>> +compatible = "marvell,armada-8k-xhci",
>> >>> + "generic-xhci";
>> >>> +reg = <0x50 0x4000>;
>> >>> +interrupts = ;
>> >>> +clocks = <_syscon0 1 22>;
>> >>> +vbus-supply = <_usb3h0_vbus>;
>> >>> +status = "disabled";
>> >>> +};
>> >>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> >>> index 5129a57..0bf8274 100644
>> >>> --- a/drivers/usb/host/Kconfig
>> >>> +++ b/drivers/usb/host/Kconfig
>> >>> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>> >>>  bool "MVEBU USB 3.0 support"
>> >>>  default y
>> >>>  depends on ARCH_MVEBU
>> >>> +select DM_REGULATOR
>> >>>  help
>> >>>Choose this option to add support for USB 3.0 driver on mvebu
>> >>>SoCs, which includes Armada8K, Armada3700 and other Armada
>> >>> diff --git a/drivers/usb/host/xhci-mvebu.c
>> >>> b/drivers/usb/host/xhci-mvebu.c
>> >>> index 46eb937..d880af1 100644
>> >>> --- a/drivers/usb/host/xhci-mvebu.c
>> >>> +++ b/drivers/usb/host/xhci-mvebu.c
>> >>> @@ -10,6 +10,7 @@
>> >>>  #include 
>> >>>  #include 
>> >>>  #include 
>> >>> +#include 
>> >>>  #include 
>> >>>
>> >>>  #include "xhci.h"
>> >>> @@ -44,12 +45,22 @@ static int xhci_usb_probe(struct udevice *dev)
>> >>>  struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
>> 

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Konstantin Porotchkin]

On 02/09/2017 05:36 PM, Marek Vasut wrote:

On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:
>
>
> On 02/09/2017 03:37 PM, Marek Vasut wrote:
>> On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
>>> From: Konstantin Porotchkin 
>>>
>>> The USB device should linked to VBUS regulator through "vbus-supply"
>>> DTS property.
>>> This patch adds handling for "vbus-supply" property inside the USB
>>> device entry for turning on the VBUS regulator upon the host adapter
>>> probe.
>>>
>>> Signed-off-by: Konstantin Porotchkin 
>>> Cc: Stefan Roese 
>>> Cc: Marek Vasut 
>>> Cc: Nadav Haklai 
>>> Cc: Neta Zur Hershkovits 
>>> Cc: Igal Liberman 
>>> Cc: Haim Boot 
>>> ---
>>> Changes for v5:
>>> - Extended clocks description in documentation
>>> - Removed print for regulator not found case
>>>
>>>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
>>> +++
>>>  drivers/usb/host/Kconfig  |  1 +
>>>  drivers/usb/host/xhci-mvebu.c | 13 +-
>>>  3 files changed, 42 insertions(+), 1 deletion(-)
>>>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>>
>>> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> new file mode 100644
>>> index 000..6cc370c
>>> --- /dev/null
>>> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> @@ -0,0 +1,29 @@
>>> +Marvell SOC USB controllers
>>> +
>>> +This controller is integrated in Armada 3700/8K.
>>> +It uses the same properties as a generic XHCI host controller
>>> +
>>> +Required properties :
>>> + - compatible: should be one or more of:
>>> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
>>> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
>>> + - reg: should contain address and length of the standard XHCI
>>> +   register set for the device.
>>> + - interrupts: one XHCI interrupt should be described here.
>>> +
>>> +Optional properties:
>>> + - clocks: reference to a platform clocks that should be
>>> enabled/configured
>>> +   upon interface initialization. May not exist on all platforms.
>>
>> This is probably block clock then ?
>>
>> Otherwise,
>> Acked-by: Marek Vasut 
> Otherwise the the internal SoC clock does not require gating/muxing or
> any other configuration for making this USB host adapter running.
> Not sure if I understood your question well.

Well,  do these clock drive the USB block or do they drive the register
interface or what ?

This entry is generic and applicable to all XHCI controllers, so it is hard to 
answer your question.  It supposes to be a clock that drives the data transfer. 
It can be directly connected to the internal clock generator and divider or 
pass though an additional gate/mux. In the last case it can be inhibited or 
redirected.


>>> + - vbus-supply : If present, specifies the fixed regulator to be
>>> turned on
>>> +   for providing power to the USB VBUS rail.
>>> +
>>> +Example:
>>> +cpm_usb3_0: usb3@50 {
>>> +compatible = "marvell,armada-8k-xhci",
>>> + "generic-xhci";
>>> +reg = <0x50 0x4000>;
>>> +interrupts = ;
>>> +clocks = <_syscon0 1 22>;
>>> +vbus-supply = <_usb3h0_vbus>;
>>> +status = "disabled";
>>> +};
>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>>> index 5129a57..0bf8274 100644
>>> --- a/drivers/usb/host/Kconfig
>>> +++ b/drivers/usb/host/Kconfig
>>> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>>>  bool "MVEBU USB 3.0 support"
>>>  default y
>>>  depends on ARCH_MVEBU
>>> +select DM_REGULATOR
>>>  help
>>>Choose this option to add support for USB 3.0 driver on mvebu
>>>SoCs, which includes Armada8K, Armada3700 and other Armada
>>> diff --git a/drivers/usb/host/xhci-mvebu.c
>>> b/drivers/usb/host/xhci-mvebu.c
>>> index 46eb937..d880af1 100644
>>> --- a/drivers/usb/host/xhci-mvebu.c
>>> +++ b/drivers/usb/host/xhci-mvebu.c
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  #include "xhci.h"
>>> @@ -44,12 +45,22 @@ static int xhci_usb_probe(struct udevice *dev)
>>>  struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
>>>  struct mvebu_xhci *ctx = dev_get_priv(dev);
>>>  struct xhci_hcor *hcor;
>>> -int len;
>>> +int len, ret;
>>> +struct udevice *regulator;
>>>
>>>  ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
>>>  len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
>>>  hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
>>>
>>> +ret = device_get_supply_regulator(dev, "vbus-supply", );
>>> +if (!ret) {
>>> +ret = regulator_set_enable(regulator, true);
>>> +if (ret) {
>>> +printf("Failed to 

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote:
> 
> 
> On 02/09/2017 03:37 PM, Marek Vasut wrote:
>> On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
>>> From: Konstantin Porotchkin 
>>>
>>> The USB device should linked to VBUS regulator through "vbus-supply"
>>> DTS property.
>>> This patch adds handling for "vbus-supply" property inside the USB
>>> device entry for turning on the VBUS regulator upon the host adapter
>>> probe.
>>>
>>> Signed-off-by: Konstantin Porotchkin 
>>> Cc: Stefan Roese 
>>> Cc: Marek Vasut 
>>> Cc: Nadav Haklai 
>>> Cc: Neta Zur Hershkovits 
>>> Cc: Igal Liberman 
>>> Cc: Haim Boot 
>>> ---
>>> Changes for v5:
>>> - Extended clocks description in documentation
>>> - Removed print for regulator not found case
>>>
>>>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
>>> +++
>>>  drivers/usb/host/Kconfig  |  1 +
>>>  drivers/usb/host/xhci-mvebu.c | 13 +-
>>>  3 files changed, 42 insertions(+), 1 deletion(-)
>>>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>>
>>> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> new file mode 100644
>>> index 000..6cc370c
>>> --- /dev/null
>>> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> @@ -0,0 +1,29 @@
>>> +Marvell SOC USB controllers
>>> +
>>> +This controller is integrated in Armada 3700/8K.
>>> +It uses the same properties as a generic XHCI host controller
>>> +
>>> +Required properties :
>>> + - compatible: should be one or more of:
>>> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
>>> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
>>> + - reg: should contain address and length of the standard XHCI
>>> +   register set for the device.
>>> + - interrupts: one XHCI interrupt should be described here.
>>> +
>>> +Optional properties:
>>> + - clocks: reference to a platform clocks that should be
>>> enabled/configured
>>> +   upon interface initialization. May not exist on all platforms.
>>
>> This is probably block clock then ?
>>
>> Otherwise,
>> Acked-by: Marek Vasut 
> Otherwise the the internal SoC clock does not require gating/muxing or
> any other configuration for making this USB host adapter running.
> Not sure if I understood your question well.

Well,  do these clock drive the USB block or do they drive the register
interface or what ?

>>> + - vbus-supply : If present, specifies the fixed regulator to be
>>> turned on
>>> +   for providing power to the USB VBUS rail.
>>> +
>>> +Example:
>>> +cpm_usb3_0: usb3@50 {
>>> +compatible = "marvell,armada-8k-xhci",
>>> + "generic-xhci";
>>> +reg = <0x50 0x4000>;
>>> +interrupts = ;
>>> +clocks = <_syscon0 1 22>;
>>> +vbus-supply = <_usb3h0_vbus>;
>>> +status = "disabled";
>>> +};
>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>>> index 5129a57..0bf8274 100644
>>> --- a/drivers/usb/host/Kconfig
>>> +++ b/drivers/usb/host/Kconfig
>>> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>>>  bool "MVEBU USB 3.0 support"
>>>  default y
>>>  depends on ARCH_MVEBU
>>> +select DM_REGULATOR
>>>  help
>>>Choose this option to add support for USB 3.0 driver on mvebu
>>>SoCs, which includes Armada8K, Armada3700 and other Armada
>>> diff --git a/drivers/usb/host/xhci-mvebu.c
>>> b/drivers/usb/host/xhci-mvebu.c
>>> index 46eb937..d880af1 100644
>>> --- a/drivers/usb/host/xhci-mvebu.c
>>> +++ b/drivers/usb/host/xhci-mvebu.c
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  #include "xhci.h"
>>> @@ -44,12 +45,22 @@ static int xhci_usb_probe(struct udevice *dev)
>>>  struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
>>>  struct mvebu_xhci *ctx = dev_get_priv(dev);
>>>  struct xhci_hcor *hcor;
>>> -int len;
>>> +int len, ret;
>>> +struct udevice *regulator;
>>>
>>>  ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
>>>  len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
>>>  hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
>>>
>>> +ret = device_get_supply_regulator(dev, "vbus-supply", );
>>> +if (!ret) {
>>> +ret = regulator_set_enable(regulator, true);
>>> +if (ret) {
>>> +printf("Failed to turn ON the VBUS regulator\n");
>>> +return ret;
>>> +}
>>> +}
>>> +
>>>  /* Enable USB xHCI (VBUS, reset etc) in board specific code */
>>>  board_xhci_enable();
>>>
>>>
>>
>>


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH 2/6] usb: host: xhci-omap: fix double weak board_usb_init functions

[Tom Rini]

On Thu, Feb 09, 2017 at 02:35:30PM +0100, Marek Vasut wrote:
> On 02/09/2017 12:36 PM, Uri Mashiach wrote:
> > Hello Marek,
> 
> 
> Hi!
> 
> [...]
> 
> >>> diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
> >>> index b881b19..ceee12a 100644
> >>> --- a/drivers/usb/host/xhci-omap.c
> >>> +++ b/drivers/usb/host/xhci-omap.c
> >>> @@ -27,12 +27,31 @@ DECLARE_GLOBAL_DATA_PTR;
> >>>
> >>>  static struct omap_xhci omap;
> >>>
> >>> -__weak int __board_usb_init(int index, enum usb_init_type init)
> >>> +__weak int __omap_xhci_board_usb_init(int index, enum usb_init_type
> >>> init)
> >>>  {
> >>>  return 0;
> >>>  }
> >>> +
> >>> +int omap_xhci_board_usb_init(int index, enum usb_init_type init)
> >>> +__attribute__((weak, alias("__omap_xhci_board_usb_init")));
> >>
> >> You can just use __weak instead of this attribute block .
> >>
> > 
> > With the attribute block it is possible to call to
> > __omap_xhci_board_usb_init from the board file.
> > Do you think it's redundant?
> 
> Yes, but feel free to prove me wrong, I'm not an omap expert.

This isn't an omap issue, it's a compiler issue.  IFF we need both
omap_xhci_board_usb_init and __omap_xhci_board_usb_init then we need the
above declaration as that provides both.  IFF we only need one function,
name it as needed and use __weak.  __weak just sets the weak attribute
(and __alias(foo) will just set the alias attribute).

-- 
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 v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Konstantin Porotchkin]

On 02/09/2017 03:37 PM, Marek Vasut wrote:

On 02/09/2017 12:32 PM, kos...@marvell.com wrote:

From: Konstantin Porotchkin 

The USB device should linked to VBUS regulator through "vbus-supply"
DTS property.
This patch adds handling for "vbus-supply" property inside the USB
device entry for turning on the VBUS regulator upon the host adapter probe.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Marek Vasut 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v5:
- Extended clocks description in documentation
- Removed print for regulator not found case

 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 +++
 drivers/usb/host/Kconfig  |  1 +
 drivers/usb/host/xhci-mvebu.c | 13 +-
 3 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt

diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000..6cc370c
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,29 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+   register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a platform clocks that should be enabled/configured
+   upon interface initialization. May not exist on all platforms.


This is probably block clock then ?

Otherwise,
Acked-by: Marek Vasut 
Otherwise the the internal SoC clock does not require gating/muxing or 
any other configuration for making this USB host adapter running.

Not sure if I understood your question well.



+ - vbus-supply : If present, specifies the fixed regulator to be turned on
+   for providing power to the USB VBUS rail.
+
+Example:
+   cpm_usb3_0: usb3@50 {
+   compatible = "marvell,armada-8k-xhci",
+"generic-xhci";
+   reg = <0x50 0x4000>;
+   interrupts = ;
+   clocks = <_syscon0 1 22>;
+   vbus-supply = <_usb3h0_vbus>;
+   status = "disabled";
+   };
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5129a57..0bf8274 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y
depends on ARCH_MVEBU
+   select DM_REGULATOR
help
  Choose this option to add support for USB 3.0 driver on mvebu
  SoCs, which includes Armada8K, Armada3700 and other Armada
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 46eb937..d880af1 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "xhci.h"
@@ -44,12 +45,22 @@ static int xhci_usb_probe(struct udevice *dev)
struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
struct mvebu_xhci *ctx = dev_get_priv(dev);
struct xhci_hcor *hcor;
-   int len;
+   int len, ret;
+   struct udevice *regulator;

ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);

+   ret = device_get_supply_regulator(dev, "vbus-supply", );
+   if (!ret) {
+   ret = regulator_set_enable(regulator, true);
+   if (ret) {
+   printf("Failed to turn ON the VBUS regulator\n");
+   return ret;
+   }
+   }
+
/* Enable USB xHCI (VBUS, reset etc) in board specific code */
board_xhci_enable();






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

Re: [U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 12:32 PM, kos...@marvell.com wrote:
> From: Konstantin Porotchkin 
> 
> The USB device should linked to VBUS regulator through "vbus-supply"
> DTS property.
> This patch adds handling for "vbus-supply" property inside the USB
> device entry for turning on the VBUS regulator upon the host adapter probe.
> 
> Signed-off-by: Konstantin Porotchkin 
> Cc: Stefan Roese 
> Cc: Marek Vasut 
> Cc: Nadav Haklai 
> Cc: Neta Zur Hershkovits 
> Cc: Igal Liberman 
> Cc: Haim Boot 
> ---
> Changes for v5:
> - Extended clocks description in documentation
> - Removed print for regulator not found case
> 
>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 
> +++
>  drivers/usb/host/Kconfig  |  1 +
>  drivers/usb/host/xhci-mvebu.c | 13 +-
>  3 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> 
> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> new file mode 100644
> index 000..6cc370c
> --- /dev/null
> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> @@ -0,0 +1,29 @@
> +Marvell SOC USB controllers
> +
> +This controller is integrated in Armada 3700/8K.
> +It uses the same properties as a generic XHCI host controller
> +
> +Required properties :
> + - compatible: should be one or more of:
> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
> + - reg: should contain address and length of the standard XHCI
> +   register set for the device.
> + - interrupts: one XHCI interrupt should be described here.
> +
> +Optional properties:
> + - clocks: reference to a platform clocks that should be enabled/configured
> +   upon interface initialization. May not exist on all platforms.

This is probably block clock then ?

Otherwise,
Acked-by: Marek Vasut 

> + - vbus-supply : If present, specifies the fixed regulator to be turned on
> +   for providing power to the USB VBUS rail.
> +
> +Example:
> + cpm_usb3_0: usb3@50 {
> + compatible = "marvell,armada-8k-xhci",
> +  "generic-xhci";
> + reg = <0x50 0x4000>;
> + interrupts = ;
> + clocks = <_syscon0 1 22>;
> + vbus-supply = <_usb3h0_vbus>;
> + status = "disabled";
> + };
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 5129a57..0bf8274 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>   bool "MVEBU USB 3.0 support"
>   default y
>   depends on ARCH_MVEBU
> + select DM_REGULATOR
>   help
> Choose this option to add support for USB 3.0 driver on mvebu
> SoCs, which includes Armada8K, Armada3700 and other Armada
> diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
> index 46eb937..d880af1 100644
> --- a/drivers/usb/host/xhci-mvebu.c
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "xhci.h"
> @@ -44,12 +45,22 @@ static int xhci_usb_probe(struct udevice *dev)
>   struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
>   struct mvebu_xhci *ctx = dev_get_priv(dev);
>   struct xhci_hcor *hcor;
> - int len;
> + int len, ret;
> + struct udevice *regulator;
>  
>   ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
>   len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
>   hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
>  
> + ret = device_get_supply_regulator(dev, "vbus-supply", );
> + if (!ret) {
> + ret = regulator_set_enable(regulator, true);
> + if (ret) {
> + printf("Failed to turn ON the VBUS regulator\n");
> + return ret;
> + }
> + }
> +
>   /* Enable USB xHCI (VBUS, reset etc) in board specific code */
>   board_xhci_enable();
>  
> 


-- 
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 v4 0/2] SPL: Add support to boot a partition type

[Marek Vasut]

On 02/09/2017 03:28 PM, Dalon Westergreen wrote:
> On Thu, 2017-02-09 at 11:06 +0100, Marek Vasut wrote:
>> On 02/09/2017 01:15 AM, Dalon Westergreen wrote:
>>>
>>> On Fri, 2017-02-03 at 10:36 -0800, Dalon Westergreen wrote:

 From: Dalon Westergreen 

 This adds support for the spl to seach for and boot from an arbitrary 
 partition type rather then a specific partition number.  When
 USE_PARTITION_TYPE is enabled, splwill search for the partition type but
 fallback to the specified partition number.

 In addition to the above, move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to
 Kconfig.

 Dalon Westergreen (2):
   SPL: add support to boot from a partition type
   SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig

  common/spl/Kconfig   | 33 +
  common/spl/spl_mmc.c | 27 ++-
  configs/db-88f6820-gp_defconfig  |  1 +
  configs/kc1_defconfig|  2 ++
  configs/sniper_defconfig |  2 ++
  disk/part_dos.c  |  1 +
  include/configs/db-88f6820-gp.h  |  1 -
  include/configs/kc1.h|  2 --
  include/configs/sniper.h |  2 --
  include/configs/socfpga_common.h |  2 --
  include/part.h   |  3 +++
  11 files changed, 60 insertions(+), 16 deletions(-)
>>>
>>> Marek, I was wondering if you have had a chance to look this over?
>>
>> Looks generally OK, just a few minor nits.
> 
> thanks, i will clean them up.

Thanks!


-- 
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 2/6] usb: host: xhci-omap: fix double weak board_usb_init functions

[Marek Vasut]

On 02/09/2017 12:36 PM, Uri Mashiach wrote:
> Hello Marek,


Hi!

[...]

>>> diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
>>> index b881b19..ceee12a 100644
>>> --- a/drivers/usb/host/xhci-omap.c
>>> +++ b/drivers/usb/host/xhci-omap.c
>>> @@ -27,12 +27,31 @@ DECLARE_GLOBAL_DATA_PTR;
>>>
>>>  static struct omap_xhci omap;
>>>
>>> -__weak int __board_usb_init(int index, enum usb_init_type init)
>>> +__weak int __omap_xhci_board_usb_init(int index, enum usb_init_type
>>> init)
>>>  {
>>>  return 0;
>>>  }
>>> +
>>> +int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>>> +__attribute__((weak, alias("__omap_xhci_board_usb_init")));
>>
>> You can just use __weak instead of this attribute block .
>>
> 
> With the attribute block it is possible to call to
> __omap_xhci_board_usb_init from the board file.
> Do you think it's redundant?

Yes, but feel free to prove me wrong, I'm not an omap expert.

>>>  int board_usb_init(int index, enum usb_init_type init)
>>> -__attribute__((weak, alias("__board_usb_init")));
>>> +{
>>> +return omap_xhci_board_usb_init(index, init);
>>> +}
>>> +
>>> +__weak int __omap_xhci_board_usb_cleanup(int index, enum
>>> usb_init_type init)
>>> +{
>>> +return 0;
>>> +}
>>> +
>>> +int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
>>> +__attribute__((weak, alias("__omap_xhci_board_usb_cleanup")));
>>> +
>>> +int board_usb_cleanup(int index, enum usb_init_type init)
>>> +{
>>> +return omap_xhci_board_usb_cleanup(index, init);
>>> +}
>>>
>>>  static int omap_xhci_core_init(struct omap_xhci *omap)
>>>  {
>>>
>>
>>
> 


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

Re: [U-Boot] [PATCH v3 2/6] spl: Add option to enable SPL Legacy image support

[Andrew F. Davis]

On 02/08/2017 10:22 PM, Lokesh Vutla wrote:
> 
> 
> On Wednesday 08 February 2017 10:51 PM, Andrew F. Davis wrote:
>> Add a Kconfig option that enables Legacy image support, this allows
>> boards to explicitly disable this, for instance when needed for
>> security reasons.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>  Kconfig  | 8 
>>  common/spl/spl.c | 9 +++--
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/Kconfig b/Kconfig
>> index 8ce2d8c3bb..62fa667b7f 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -299,6 +299,14 @@ config SPL_RAW_IMAGE_SUPPORT
>>is y. If this is not set, SPL will move on to other available
>>boot media to find a suitable image.
>>  
>> +config SPL_LEGACY_IMAGE_SUPPORT
>> +bool "Support SPL loading and booting of Legacy images"
>> +default y
>> +help
>> +  SPL will support loading and booting Legacy images when this option
>> +  is y. If this is not set, SPL will move on to other available
>> +  boot media to find a suitable image.
>> +
> 
> This as well can be moved under spl. Or is there any specific reason you
> keep it here?
> 

I think this is the best spot. It is under "Boot images", like FIT
support options above this, the SPL image loading support defines what
type of images U-Boot should be built into. At some point we should have
the U-Boot build types depend on the SPL support for that type.

Thanks,
Andrew

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

Re: [U-Boot] [PATCH v4 0/2] SPL: Add support to boot a partition type

[Dalon Westergreen]

On Thu, 2017-02-09 at 11:06 +0100, Marek Vasut wrote:
> On 02/09/2017 01:15 AM, Dalon Westergreen wrote:
> > 
> > On Fri, 2017-02-03 at 10:36 -0800, Dalon Westergreen wrote:
> > > 
> > > From: Dalon Westergreen 
> > > 
> > > This adds support for the spl to seach for and boot from an arbitrary 
> > > partition type rather then a specific partition number.  When
> > > USE_PARTITION_TYPE is enabled, splwill search for the partition type but
> > > fallback to the specified partition number.
> > > 
> > > In addition to the above, move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to
> > > Kconfig.
> > > 
> > > Dalon Westergreen (2):
> > >   SPL: add support to boot from a partition type
> > >   SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig
> > > 
> > >  common/spl/Kconfig   | 33 +
> > >  common/spl/spl_mmc.c | 27 ++-
> > >  configs/db-88f6820-gp_defconfig  |  1 +
> > >  configs/kc1_defconfig|  2 ++
> > >  configs/sniper_defconfig |  2 ++
> > >  disk/part_dos.c  |  1 +
> > >  include/configs/db-88f6820-gp.h  |  1 -
> > >  include/configs/kc1.h|  2 --
> > >  include/configs/sniper.h |  2 --
> > >  include/configs/socfpga_common.h |  2 --
> > >  include/part.h   |  3 +++
> > >  11 files changed, 60 insertions(+), 16 deletions(-)
> > 
> > Marek, I was wondering if you have had a chance to look this over?
> 
> Looks generally OK, just a few minor nits.

thanks, i will clean them up.

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

Re: [U-Boot] [PATCH] defconfig: am43xx_hs_evm: Sync HS defconfig with non-HS defconfig

[Tom Rini]

On Thu, Feb 09, 2017 at 09:45:26AM +0530, Lokesh Vutla wrote:
> 
> 
> On Thursday 09 February 2017 02:02 AM, Andrew F. Davis wrote:
> > The non-HS defconfig has been modified without equivalent changes being
> > applied to the HS defconfig. Sync these here.
> > 
> > Signed-off-by: Andrew F. Davis 
> 
> Reviewed-by: Lokesh Vutla 
> 
> I am sure we might encounter this problem again after some time :(

Well, the good news is I think we can do something about this soon now.
In the kernel we now have:
commit 237e3ad0f195d8fd34f1299e45f04793832a16fc
Author: Nicolas Pitre 
Date:   Fri Nov 11 00:10:05 2016 -0500

Kconfig: Introduce the "imply" keyword

And cherry-picking this, and maybe the preceding commit will let us move
lots of these logic into arch/arm/Kconfig where we can imply lots of
features that an SoC has but still allow them to be turned off.

-- 
Tom


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

[U-Boot] [PATCH] qemu-x86_64_defconfig: Disable CONFIG_BOARD_EARLY_INIT_F

[Tom Rini]

The qemu-x86* targets do not want to enable this.

Signed-off-by: Tom Rini 
---
 configs/qemu-x86_64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 484e2e9716b9..790f21cbbcfc 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -20,6 +20,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_BOARD_EARLY_INIT_F is not set
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_CPU_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 0/5] ARM: DRA7: AM57xx: Enable SPL_DM

[Lokesh Vutla]

Hi Tom,

On Thursday 09 February 2017 09:30 AM, Lokesh Vutla wrote:
> - Enable SPL_DM on all DRA7 and AM57xx based platforms.
> - SPL uses a generic dts on all platforms with same defconfig.
> - After this series SPL size is increased by ~8KB.
> 
> Verified MMC, eMMC boot on DRA74-evm, DRA72-evm.
> MMC boot on AM57xx-evm.
> 
> Changes since v1:
> - Instead of creating a new dts file for each platform, created a omap5
>   specific common dtsi that will be included automatically.

I see a problem with this approach. We want this omap5-u-boot.dtsi only
for SPL. But Makefile.lib tries to append this for each dtb in proper
U-Boot as well. As we might not need any of these in U-Boot before
relocation, the behavior is unexpected(sometimes U-boot does not comes
up ). I would like to go ahead with V1 of this series, what do you say?

Thanks and regards,
Lokesh

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

[U-Boot] [GIT PULL] Please pull u-boot-mmc master

[Jaehoon Chung]

Dear Tom,

Could you pull these patches on your master branch?
These patch are related to pmic and mmc. (Tested buildman.)

If you are ok, i will send the split PR at next time.
(One is u-boot-mmc master, other is u-boot-mmc pmic)
What do you think about? Plz let me know.

The following changes since commit 21342d4aed6c77a4aa7a5b2579b3c23e21aea31a:

  Merge git://git.denx.de/u-boot-dm (2017-02-08 16:24:44 -0500)

are available in the git repository at:

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

for you to fetch changes up to a0269bb6e891c6c3b984a2f3d6a12c07e244484a:

  mmc: init mmc block devices on probe (2017-02-09 20:37:06 +0900)


Adam Ford (1):
  drivers: mmc: omap_hsmmc: Fix IO Buffer on OMAP36xx

Fiach Antaw (1):
  mmc: init mmc block devices on probe

Jaehoon Chung (4):
  power: pmic: add the max8997 controller for DM
  arm: dts: trats: add the pmic node for using DM
  mmc: mmc-uclass: use the fixed devnum with alias node
  mmc: ftsdc021_sdhci: remove the ftsdc021_sdhci.c

 arch/arm/dts/exynos4210-trats.dts | 150 --
 configs/omap3_logic_defconfig |   1 +
 drivers/mmc/Kconfig   |  12 +++
 drivers/mmc/Makefile  |   1 -
 drivers/mmc/ftsdc021_sdhci.c  |  34 -
 drivers/mmc/mmc-uclass.c  |  25 ++-
 drivers/mmc/omap_hsmmc.c  |  18 +
 drivers/power/pmic/Kconfig|  15 
 drivers/power/pmic/Makefile   |   1 +
 drivers/power/pmic/max8997.c  |  61 
 drivers/power/pmic/max8998.c  |   2 +-
 11 files changed, 273 insertions(+), 47 deletions(-)
 delete mode 100644 drivers/mmc/ftsdc021_sdhci.c
 create mode 100644 drivers/power/pmic/max8997.c

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

Re: [U-Boot] [PATCH 2/6] usb: host: xhci-omap: fix double weak board_usb_init functions

[Uri Mashiach]

Hello Marek,

On 02/09/2017 10:35 AM, Marek Vasut wrote:

On 02/09/2017 08:01 AM, Uri Mashiach wrote:

A weak version of the function board_usb_init is implemented in:
common/usb.c
drivers/usb/host/xhci-omap.c

To fix the double implementations:
* Convert the board_usb_init function in drivers/usb/host/xhci-omap.c
  normal (not weak).
* The function board_usb_init in drivers/usb/host/xhci-omap.c calls to
  the weak function omap_xhci_board_usb_init.
* Rename board version of the function board_usb_init to
  omap_xhci_board_usb_init.
  Done only for boards that defines CONFIG_USB_XHCI_OMAP.

To achieve the same flexibility with the function board_usb_cleanup:
* Add a normal (not weak) implementation of the function
  board_usb_cleanup in drivers/usb/host/xhci-omap.c
* The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls
  to the weak function omap_xhci_board_usb_cleanup.
* Rename board version of the function board_usb_cleanup to
  omap_xhci_board_usb_cleanup.
  Done only for boards that defines CONFIG_USB_XHCI_OMAP.

Signed-off-by: Uri Mashiach 
---
 board/compulab/cl-som-am57x/cl-som-am57x.c |  2 +-
 board/ti/am43xx/board.c|  4 ++--
 board/ti/am57xx/board.c|  4 ++--
 board/ti/dra7xx/evm.c  |  4 ++--
 drivers/usb/host/xhci-omap.c   | 23 +--
 5 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/board/compulab/cl-som-am57x/cl-som-am57x.c 
b/board/compulab/cl-som-am57x/cl-som-am57x.c
index bdd0a2b..fe1468f 100644
--- a/board/compulab/cl-som-am57x/cl-som-am57x.c
+++ b/board/compulab/cl-som-am57x/cl-som-am57x.c
@@ -54,7 +54,7 @@ int board_mmc_init(bd_t *bis)
 #endif /* CONFIG_GENERIC_MMC */

 #ifdef CONFIG_USB_XHCI_OMAP
-int board_usb_init(int index, enum usb_init_type init)
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
setbits_le32((*prcm)->cm_l3init_usb_otg_ss1_clkctrl,
 OTG_SS_CLKCTRL_MODULEMODE_HW | OPTFCLKEN_REFCLK960M);
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 390cc16..2572029 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -694,7 +694,7 @@ int usb_gadget_handle_interrupts(int index)
 #endif /* CONFIG_USB_DWC3 */

 #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
-int board_usb_init(int index, enum usb_init_type init)
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
 #ifdef CONFIG_USB_DWC3
@@ -725,7 +725,7 @@ int board_usb_init(int index, enum usb_init_type init)
return 0;
 }

-int board_usb_cleanup(int index, enum usb_init_type init)
+int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_USB_DWC3
switch (index) {
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 5f2d4df..96fad0f 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -616,7 +616,7 @@ int usb_gadget_handle_interrupts(int index)
 #endif /* CONFIG_USB_DWC3 */

 #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
-int board_usb_init(int index, enum usb_init_type init)
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
switch (index) {
@@ -650,7 +650,7 @@ int board_usb_init(int index, enum usb_init_type init)
return 0;
 }

-int board_usb_cleanup(int index, enum usb_init_type init)
+int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_USB_DWC3
switch (index) {
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index bd1c809..21fa824 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -727,7 +727,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
.index = 1,
 };

-int board_usb_init(int index, enum usb_init_type init)
+int  omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
switch (index) {
@@ -764,7 +764,7 @@ int board_usb_init(int index, enum usb_init_type init)
return 0;
 }

-int board_usb_cleanup(int index, enum usb_init_type init)
+int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
switch (index) {
case 0:
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index b881b19..ceee12a 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -27,12 +27,31 @@ DECLARE_GLOBAL_DATA_PTR;

 static struct omap_xhci omap;

-__weak int __board_usb_init(int index, enum usb_init_type init)
+__weak int __omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
return 0;
 }
+
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
+   __attribute__((weak, alias("__omap_xhci_board_usb_init")));


You can just use __weak instead of this attribute block .



With the attribute block it is possible to call to 
__omap_xhci_board_usb_init from the 

[U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[kostap]

From: Konstantin Porotchkin 

The USB device should linked to VBUS regulator through "vbus-supply"
DTS property.
This patch adds handling for "vbus-supply" property inside the USB
device entry for turning on the VBUS regulator upon the host adapter probe.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Marek Vasut 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v5:
- Extended clocks description in documentation
- Removed print for regulator not found case

 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 +++
 drivers/usb/host/Kconfig  |  1 +
 drivers/usb/host/xhci-mvebu.c | 13 +-
 3 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt

diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000..6cc370c
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,29 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+   register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a platform clocks that should be enabled/configured
+   upon interface initialization. May not exist on all platforms.
+ - vbus-supply : If present, specifies the fixed regulator to be turned on
+   for providing power to the USB VBUS rail.
+
+Example:
+   cpm_usb3_0: usb3@50 {
+   compatible = "marvell,armada-8k-xhci",
+"generic-xhci";
+   reg = <0x50 0x4000>;
+   interrupts = ;
+   clocks = <_syscon0 1 22>;
+   vbus-supply = <_usb3h0_vbus>;
+   status = "disabled";
+   };
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5129a57..0bf8274 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y
depends on ARCH_MVEBU
+   select DM_REGULATOR
help
  Choose this option to add support for USB 3.0 driver on mvebu
  SoCs, which includes Armada8K, Armada3700 and other Armada
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 46eb937..d880af1 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "xhci.h"
@@ -44,12 +45,22 @@ static int xhci_usb_probe(struct udevice *dev)
struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
struct mvebu_xhci *ctx = dev_get_priv(dev);
struct xhci_hcor *hcor;
-   int len;
+   int len, ret;
+   struct udevice *regulator;
 
ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
 
+   ret = device_get_supply_regulator(dev, "vbus-supply", );
+   if (!ret) {
+   ret = regulator_set_enable(regulator, true);
+   if (ret) {
+   printf("Failed to turn ON the VBUS regulator\n");
+   return ret;
+   }
+   }
+
/* Enable USB xHCI (VBUS, reset etc) in board specific code */
board_xhci_enable();
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 11:46 AM, Konstantin Porotchkin wrote:
> 
> 
> On 02/09/2017 12:39 PM, Marek Vasut wrote:
>> On 02/09/2017 11:39 AM, kos...@marvell.com wrote:
>>> From: Konstantin Porotchkin 
>>>
>>> The USB device should linked to VBUS regulator through "vbus-supply"
>>> DTS property.
>>> This patch adds handling for "vbus-supply" property inside the USB
>>> device entry for turning on the VBUS regulator upon the host adapter
>>> probe.
>>>
>>> Signed-off-by: Konstantin Porotchkin 
>>> Cc: Stefan Roese 
>>> Cc: Marek Vasut 
>>> Cc: Nadav Haklai 
>>> Cc: Neta Zur Hershkovits 
>>> Cc: Igal Liberman 
>>> Cc: Haim Boot 
>>> ---
>>> Changes for v4:
>>> - Move the VBUS supply handling to use regulator framework
>>> - Select DM_REGULATOR by Kconfig for mvebu XHCI driver
>>>
>>>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29
>>> +++
>>>  drivers/usb/host/Kconfig  |  1 +
>>>  drivers/usb/host/xhci-mvebu.c | 14 ++-
>>>  3 files changed, 43 insertions(+), 1 deletion(-)
>>>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>>
>>> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> new file mode 100644
>>> index 000..cd21115
>>> --- /dev/null
>>> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
>>> @@ -0,0 +1,29 @@
>>> +Marvell SOC USB controllers
>>> +
>>> +This controller is integrated in Armada 3700/8K.
>>> +It uses the same properties as a generic XHCI host controller
>>> +
>>> +Required properties :
>>> + - compatible: should be one or more of:
>>> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
>>> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
>>> + - reg: should contain address and length of the standard XHCI
>>> +   register set for the device.
>>> + - interrupts: one XHCI interrupt should be described here.
>>> +
>>> +Optional properties:
>>> + - clocks: reference to a clock
>>
>> I asked in the previous version , multiple times , what clock are these?
> Yep, we discussed these clocks already. Do you want me to add a notice
> here?
> Like "the platform clocks that should be enabled upon initialization.
> may not exist on all platforms"

Any description than opaque "reference to a clock" is better. I guess
these clock have a description in the datasheet , so something like that
would do.

>>> + - vbus-supply : If present, specifies the fixed regulator to be
>>> turned on
>>> +   for providing power to the USB VBUS rail.
>>> +
>>> +Example:
>>> +cpm_usb3_0: usb3@50 {
>>> +compatible = "marvell,armada-8k-xhci",
>>> + "generic-xhci";
>>> +reg = <0x50 0x4000>;
>>> +interrupts = ;
>>> +clocks = <_syscon0 1 22>;
>>> +vbus-supply = <_usb3h0_vbus>;
>>> +status = "disabled";
>>> +};
>>> +
>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>>> index 5129a57..0bf8274 100644
>>> --- a/drivers/usb/host/Kconfig
>>> +++ b/drivers/usb/host/Kconfig
>>> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>>>  bool "MVEBU USB 3.0 support"
>>>  default y
>>>  depends on ARCH_MVEBU
>>> +select DM_REGULATOR
>>>  help
>>>Choose this option to add support for USB 3.0 driver on mvebu
>>>SoCs, which includes Armada8K, Armada3700 and other Armada
>>> diff --git a/drivers/usb/host/xhci-mvebu.c
>>> b/drivers/usb/host/xhci-mvebu.c
>>> index 46eb937..35d89ab 100644
>>> --- a/drivers/usb/host/xhci-mvebu.c
>>> +++ b/drivers/usb/host/xhci-mvebu.c
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  #include "xhci.h"
>>> @@ -44,12 +45,23 @@ static int xhci_usb_probe(struct udevice *dev)
>>>  struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
>>>  struct mvebu_xhci *ctx = dev_get_priv(dev);
>>>  struct xhci_hcor *hcor;
>>> -int len;
>>> +int len, ret;
>>> +struct udevice *regulator;
>>>
>>>  ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
>>>  len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
>>>  hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
>>>
>>> +ret = device_get_supply_regulator(dev, "vbus-supply", );
>>> +if (!ret) {
>>> +ret = regulator_set_enable(regulator, true);
>>> +if (ret) {
>>> +printf("Failed to turn ON the VBUS regulator\n");
>>> +return ret;
>>> +}
>>> +} else
>>> +printf("No VBUS regulator found\n");
>>
>> This should be debug() , looks good otherwise.
> OK, will change it to "debug"

Hm , in fact, you can drop it altogether . It's not really useful.

>>>  /* Enable USB xHCI (VBUS, reset etc) in board specific code */
>>>  board_xhci_enable();
>>>
>>>
>>
>>


-- 
Best 

Re: [U-Boot] [PATCH v4 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Konstantin Porotchkin]

On 02/09/2017 12:39 PM, Marek Vasut wrote:

On 02/09/2017 11:39 AM, kos...@marvell.com wrote:

From: Konstantin Porotchkin 

The USB device should linked to VBUS regulator through "vbus-supply"
DTS property.
This patch adds handling for "vbus-supply" property inside the USB
device entry for turning on the VBUS regulator upon the host adapter probe.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Marek Vasut 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v4:
- Move the VBUS supply handling to use regulator framework
- Select DM_REGULATOR by Kconfig for mvebu XHCI driver

 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 +++
 drivers/usb/host/Kconfig  |  1 +
 drivers/usb/host/xhci-mvebu.c | 14 ++-
 3 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt

diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000..cd21115
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,29 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+   register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a clock


I asked in the previous version , multiple times , what clock are these?

Yep, we discussed these clocks already. Do you want me to add a notice here?
Like "the platform clocks that should be enabled upon initialization. 
may not exist on all platforms"



+ - vbus-supply : If present, specifies the fixed regulator to be turned on
+   for providing power to the USB VBUS rail.
+
+Example:
+   cpm_usb3_0: usb3@50 {
+   compatible = "marvell,armada-8k-xhci",
+"generic-xhci";
+   reg = <0x50 0x4000>;
+   interrupts = ;
+   clocks = <_syscon0 1 22>;
+   vbus-supply = <_usb3h0_vbus>;
+   status = "disabled";
+   };
+
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5129a57..0bf8274 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y
depends on ARCH_MVEBU
+   select DM_REGULATOR
help
  Choose this option to add support for USB 3.0 driver on mvebu
  SoCs, which includes Armada8K, Armada3700 and other Armada
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 46eb937..35d89ab 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "xhci.h"
@@ -44,12 +45,23 @@ static int xhci_usb_probe(struct udevice *dev)
struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
struct mvebu_xhci *ctx = dev_get_priv(dev);
struct xhci_hcor *hcor;
-   int len;
+   int len, ret;
+   struct udevice *regulator;

ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);

+   ret = device_get_supply_regulator(dev, "vbus-supply", );
+   if (!ret) {
+   ret = regulator_set_enable(regulator, true);
+   if (ret) {
+   printf("Failed to turn ON the VBUS regulator\n");
+   return ret;
+   }
+   } else
+   printf("No VBUS regulator found\n");


This should be debug() , looks good otherwise.

OK, will change it to "debug"



/* Enable USB xHCI (VBUS, reset etc) in board specific code */
board_xhci_enable();






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

[U-Boot] unused-const-variable warnings in FSL I2C driver

[Thomas Schaefer]

Hi all,


When compiling latest u-boot with gcc 6.3 for a T1024RDB system, I get a 
'unused-const-variable' warning in the FSL I2C driver. Affected variable is 
fsl_i2c_speed_map.

I guess this warning can be fixed with the patch applied, but I'm not sure. 
What do you think?

Best regards,
Thomas


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

Re: [U-Boot] [PATCH v3 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Konstantin Porotchkin]

On 02/09/2017 11:09 AM, Marek Vasut wrote:

On 02/09/2017 10:08 AM, Konstantin Porotchkin wrote:



On 02/09/2017 10:32 AM, Marek Vasut wrote:

On 02/09/2017 09:00 AM, Konstantin Porotchkin wrote:



On 02/08/2017 06:42 PM, Marek Vasut wrote:

On 02/08/2017 05:28 PM, Konstantin Porotchkin wrote:

Hi, Marek,

On 02/08/2017 06:04 PM, Marek Vasut wrote:

On 02/08/2017 04:45 PM, Konstantin Porotchkin wrote:

Hi, Marek,

On 02/08/2017 05:35 PM, Marek Vasut wrote:

On 02/08/2017 04:34 PM, kos...@marvell.com wrote:

From: Konstantin Porotchkin 

The USB device should linked to VBUS regulator through
"vbus-supply"
DTS property.
This patch adds handling for "vbus-supply" property inside the USB
device entry for turning on the VBUS regulator upon the host
adapter

probe.


Change-Id: Ibcf72d82298be42353ca03fee064ae8077a7b9de
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Marek Vasut 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v3:
- Moved VBUS control from private GPIO to a fixed regulator
- Rebase on top of master branch


 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 28



 drivers/usb/host/xhci-mvebu.c | 31

+++

 2 files changed, 59 insertions(+)
 create mode 100644
doc/device-tree-bindings/usb/marvell.xhci-usb.txt

diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt

b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt

new file mode 100644
index 000..672a829
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,28 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx
SoCs
+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+   register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a clock


What clock ? Why are clock optional ?
This probably needs clock-names too.

This is the way it defined in Linux Kernel.


Then it probably could use fixing there too. Like seriously, what
clock
are those ? And why are they optional ? If neither you or me
understand
that from the documentation, then the documentation is crap and needs
fixing. It being the same way in Linux is not an argument for
sticking
to it.

From my point of view this clock entry is optional too.
I am not handling it in any way and the core XHCI driver doesn't uses
it.


DT is describing the hardware, not the software that is using it. These
two things are separate. If the clock are mandatory for the hardware to
work, they must be mandatory in the DT.

I see what you saying. I will move the "clocks" entry to the "mandatory"
section.


Why ? What clock are those ? Are they mandatory ?


They are not mandatory. This entry can be used for enabling gated clocks
on a specific platform. However Kernel code does not handle missing
clock entry as an error. It just assumes that the clock is not gated and
therefore should not be enabled upon host controller probe.
So maybe I got you wrong. My feeling was that you requested to make this
entry mandatory.


I have no idea what close those are (based on the description), so I
cannot decide either way. If this is something which is present only
on selected platforms, then they are optional indeed.


Please keep in mind that it will not be currently enforced by
the SW. For USB 3.0 case the clock parameters are actually defined by
SERDES configuration, which has a separate DTS entry.


Then why are these clock here at all ?

Because this is an optional parameter and can be used for enabling gated
clock if one is defined.


So these are different clock from the SERDES clock, yes ?
As far as I know the SERDES entry defines the clock speed, which affects 
the initialization flow including the clock dividers.

The clock in USb entry looks like for gating only.



Should I simply remove this property from the text file?


See above.


I took the Documentation/devicetree/bindings/usb/usb-xhci.txt file
as a
base for my add-on



+ - vbus-supply : If present, specifies the fixed regulator to be

turned on

+   for providing power to the USB VBUS rail.
+
+Example:
+cpm_usb3_0: usb3@50 {
+compatible = "marvell,armada-8k-xhci",
+ "generic-xhci";
+reg = <0x50 0x4000>;
+interrupts = ;
+clocks = <_syscon0 1 22>;
+vbus-supply = <_usb3h0_vbus>;
+status = "disabled";
+};
diff --git a/drivers/usb/host/xhci-mvebu.c

b/drivers/usb/host/xhci-mvebu.c

index 

Re: [U-Boot] [PATCH v4 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

On 02/09/2017 11:39 AM, kos...@marvell.com wrote:
> From: Konstantin Porotchkin 
> 
> The USB device should linked to VBUS regulator through "vbus-supply"
> DTS property.
> This patch adds handling for "vbus-supply" property inside the USB
> device entry for turning on the VBUS regulator upon the host adapter probe.
> 
> Signed-off-by: Konstantin Porotchkin 
> Cc: Stefan Roese 
> Cc: Marek Vasut 
> Cc: Nadav Haklai 
> Cc: Neta Zur Hershkovits 
> Cc: Igal Liberman 
> Cc: Haim Boot 
> ---
> Changes for v4:
> - Move the VBUS supply handling to use regulator framework
> - Select DM_REGULATOR by Kconfig for mvebu XHCI driver
> 
>  doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 
> +++
>  drivers/usb/host/Kconfig  |  1 +
>  drivers/usb/host/xhci-mvebu.c | 14 ++-
>  3 files changed, 43 insertions(+), 1 deletion(-)
>  create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> 
> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> new file mode 100644
> index 000..cd21115
> --- /dev/null
> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
> @@ -0,0 +1,29 @@
> +Marvell SOC USB controllers
> +
> +This controller is integrated in Armada 3700/8K.
> +It uses the same properties as a generic XHCI host controller
> +
> +Required properties :
> + - compatible: should be one or more of:
> +   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
> +   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
> + - reg: should contain address and length of the standard XHCI
> +   register set for the device.
> + - interrupts: one XHCI interrupt should be described here.
> +
> +Optional properties:
> + - clocks: reference to a clock

I asked in the previous version , multiple times , what clock are these?

> + - vbus-supply : If present, specifies the fixed regulator to be turned on
> +   for providing power to the USB VBUS rail.
> +
> +Example:
> + cpm_usb3_0: usb3@50 {
> + compatible = "marvell,armada-8k-xhci",
> +  "generic-xhci";
> + reg = <0x50 0x4000>;
> + interrupts = ;
> + clocks = <_syscon0 1 22>;
> + vbus-supply = <_usb3h0_vbus>;
> + status = "disabled";
> + };
> +
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 5129a57..0bf8274 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
>   bool "MVEBU USB 3.0 support"
>   default y
>   depends on ARCH_MVEBU
> + select DM_REGULATOR
>   help
> Choose this option to add support for USB 3.0 driver on mvebu
> SoCs, which includes Armada8K, Armada3700 and other Armada
> diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
> index 46eb937..35d89ab 100644
> --- a/drivers/usb/host/xhci-mvebu.c
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "xhci.h"
> @@ -44,12 +45,23 @@ static int xhci_usb_probe(struct udevice *dev)
>   struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
>   struct mvebu_xhci *ctx = dev_get_priv(dev);
>   struct xhci_hcor *hcor;
> - int len;
> + int len, ret;
> + struct udevice *regulator;
>  
>   ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
>   len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
>   hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
>  
> + ret = device_get_supply_regulator(dev, "vbus-supply", );
> + if (!ret) {
> + ret = regulator_set_enable(regulator, true);
> + if (ret) {
> + printf("Failed to turn ON the VBUS regulator\n");
> + return ret;
> + }
> + } else
> + printf("No VBUS regulator found\n");

This should be debug() , looks good otherwise.

>   /* Enable USB xHCI (VBUS, reset etc) in board specific code */
>   board_xhci_enable();
>  
> 


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

[U-Boot] unused-const-variable warnings in FSL DDR driver

[Thomas Schaefer]

Hi York,

When compiling latest u-boot with gcc 6.3 compiler, I get several 
'unused-const-variable' warnings in options.c file of FSL DDR driver. Affected 
variables are for (DIMM_SLOTS_PER_CTLR==2) configuration (e.g. dual_0S[4]) and 
warnings could be fixed with the patch applied.

What do you think?

Best regards,
Thomas



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

[U-Boot] [PATCH v4 5/6] arm64: mvebu: dts: Add DTS file for MACCHIATOBin board

[kostap]

From: Rabeeh Khoury 

Added A8040 dts file for community board MACCHIATIBin.
The patch includes the following features:
AP -  Serial console (connected to onboard FTDI usb to serial)
CP0 - PCIe x4, SATA, I2C and 10G KR
  (connected to Marvell 3310 10G copper / SFP+ phy)
CP1 - Boot SPI, USB3 host, 2xSATA, 10G KR
  (connected to Marvell 3310 10G copper / SFP+ phy),
  SGMII connected to onboard 1512 1Gbps copper phy,
  and additional SGMII connected to SFP
  (default 1Gbps can be configured to 2.5Gbps).

Network interface naming -
egiga0 - CP0 KR
egiga1 - CP1 KR
egiga2 - CP1 RJ45 1Gbps connector (recommended for TFTP boot)
egiga3 - CP1 SFP default 1Gbps and can be modified to 2.5Gbps

Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Rabeeh Khoury 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes dor v4:
- Put USB VBUS regulator inside the "simple bus" block

 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/armada-8040-mcbin.dts | 293 +
 2 files changed, 294 insertions(+)
 create mode 100644 arch/arm/dts/armada-8040-mcbin.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 397a0ae..a3b139b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=   \
armada-385-amc.dtb  \
armada-7040-db.dtb  \
armada-8040-db.dtb  \
+   armada-8040-mcbin.dtb   \
armada-xp-gp.dtb\
armada-xp-maxbcm.dtb\
armada-xp-synology-ds414.dtb\
diff --git a/arch/arm/dts/armada-8040-mcbin.dts 
b/arch/arm/dts/armada-8040-mcbin.dts
new file mode 100644
index 000..e42b092
--- /dev/null
+++ b/arch/arm/dts/armada-8040-mcbin.dts
@@ -0,0 +1,293 @@
+/*
+ * Copyright (C) 2016 Marvell International Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ * https://spdx.org/licenses
+ */
+
+#include "armada-8040.dtsi" /* include SoC device tree */
+
+/ {
+   model = "MACCHIATOBin-8040";
+   compatible = "marvell,armada8040-mcbin",
+"marvell,armada8040";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   i2c0 = _i2c0;
+   i2c1 = _i2c1;
+   spi0 = _spi1;
+   gpio0 = _gpio0;
+   gpio1 = _gpio0;
+   gpio2 = _gpio1;
+   };
+
+   memory@ {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   simple-bus {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_usb3h0_vbus: usb3-vbus0 {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_xhci_vbus_pins>;
+   regulator-name = "reg-usb3h0-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   startup-delay-us = <50>;
+   enable-active-high;
+   regulator-always-on;
+   regulator-boot-on;
+   gpio = <_gpio1 15 GPIO_ACTIVE_HIGH>; /* GPIO[47] */
+   };
+   };
+};
+
+/* Accessible over the mini-USB CON9 connector on the main board */
+ {
+   status = "okay";
+};
+
+_pinctl {
+   /*
+* MPP Bus:
+* eMMC [0-10]
+* UART0 [11,19]
+*/
+ /* 0 1 2 3 4 5 6 7 8 9 */
+   pin-func = < 1 1 1 1 1 1 1 1 1 1
+1 3 0 0 0 0 0 0 0 3 >;
+};
+
+/* on-board eMMC */
+_sdhci0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_emmc_pins>;
+   bus-width= <8>;
+   status = "okay";
+};
+
+_pinctl {
+   /*
+* MPP Bus:
+* [0-31] = 0xff: Keep default CP0_shared_pins:
+* [11] CLKOUT_MPP_11 (out)
+* [23] LINK_RD_IN_CP2CP (in)
+* [25] CLKOUT_MPP_25 (out)
+* [29] AVS_FB_IN_CP2CP (in)
+* [32,34] SMI
+* [33]MSS power down
+* [35-38] CP0 I2C1 and I2C0
+* [39] MSS CKE Enable
+* [40,41] CP0 UART1 TX/RX
+* [42,43] XSMI (controls two 10G phys)
+* [47] USB VBUS EN
+* [48] FAN PWM
+* [49] 10G port 1 interrupt
+* [50] 10G port 0 interrupt
+* [51] 2.5G SFP TX fault
+* [52] PCIe reset out
+* [53] 2.5G SFP mode
+* [54] 2.5G SFP LOS
+* [55] Micro SD card detect
+* [56-61] Micro SD
+* [62] CP1 KR SFP FAULT
+*/
+   /*   

[U-Boot] [PATCH v4 6/6] arm64: mvebu: Add default configuraton for MACCHIATOBin board

[kostap]

From: Konstantin Porotchkin 

Add default configuration for MACHHIATOBin community board
based on Aramda-8040 SoC.

Change-Id: Ic6b562065c0929ec338492452f765115c15a6188
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v4:
- Remove CONFIG_DM_REGULATOR, it is handled by XHCI Kconfig

 configs/mvebu_mcbin-88f8040_defconfig | 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 configs/mvebu_mcbin-88f8040_defconfig

diff --git a/configs/mvebu_mcbin-88f8040_defconfig 
b/configs/mvebu_mcbin-88f8040_defconfig
new file mode 100644
index 000..0de3d9e
--- /dev/null
+++ b/configs/mvebu_mcbin-88f8040_defconfig
@@ -0,0 +1,74 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_TARGET_MVEBU_ARMADA_8K=y
+CONFIG_DEFAULT_DEVICE_TREE="armada-8040-mcbin"
+CONFIG_SMBIOS_PRODUCT_NAME=""
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_ARCH_EARLY_INIT_R=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_MVEBU_BUBT=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_BLOCK_CACHE=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_MVTWSI=y
+CONFIG_DM_GPIO=y
+CONFIG_MVEBU_GPIO=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_XENON=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_PCIE_DW_MVEBU=y
+CONFIG_MVEBU_COMPHY_SUPPORT=y
+CONFIG_PINCTRL=y
+# CONFIG_SPL_SERIAL_PRESENT is not set
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0xf0512000
+CONFIG_DEBUG_UART_CLOCK=2
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_SMBIOS_MANUFACTURER=""
-- 
2.7.4

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

[U-Boot] [PATCH v4 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[kostap]

From: Konstantin Porotchkin 

The USB device should linked to VBUS regulator through "vbus-supply"
DTS property.
This patch adds handling for "vbus-supply" property inside the USB
device entry for turning on the VBUS regulator upon the host adapter probe.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Marek Vasut 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Igal Liberman 
Cc: Haim Boot 
---
Changes for v4:
- Move the VBUS supply handling to use regulator framework
- Select DM_REGULATOR by Kconfig for mvebu XHCI driver

 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 +++
 drivers/usb/host/Kconfig  |  1 +
 drivers/usb/host/xhci-mvebu.c | 14 ++-
 3 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt

diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000..cd21115
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,29 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+   register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a clock
+ - vbus-supply : If present, specifies the fixed regulator to be turned on
+   for providing power to the USB VBUS rail.
+
+Example:
+   cpm_usb3_0: usb3@50 {
+   compatible = "marvell,armada-8k-xhci",
+"generic-xhci";
+   reg = <0x50 0x4000>;
+   interrupts = ;
+   clocks = <_syscon0 1 22>;
+   vbus-supply = <_usb3h0_vbus>;
+   status = "disabled";
+   };
+
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5129a57..0bf8274 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -25,6 +25,7 @@ config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y
depends on ARCH_MVEBU
+   select DM_REGULATOR
help
  Choose this option to add support for USB 3.0 driver on mvebu
  SoCs, which includes Armada8K, Armada3700 and other Armada
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 46eb937..35d89ab 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "xhci.h"
@@ -44,12 +45,23 @@ static int xhci_usb_probe(struct udevice *dev)
struct mvebu_xhci_platdata *plat = dev_get_platdata(dev);
struct mvebu_xhci *ctx = dev_get_priv(dev);
struct xhci_hcor *hcor;
-   int len;
+   int len, ret;
+   struct udevice *regulator;
 
ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
len = HC_LENGTH(xhci_readl(>hcd->cr_capbase));
hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
 
+   ret = device_get_supply_regulator(dev, "vbus-supply", );
+   if (!ret) {
+   ret = regulator_set_enable(regulator, true);
+   if (ret) {
+   printf("Failed to turn ON the VBUS regulator\n");
+   return ret;
+   }
+   } else
+   printf("No VBUS regulator found\n");
+
/* Enable USB xHCI (VBUS, reset etc) in board specific code */
board_xhci_enable();
 
-- 
2.7.4

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