Re: [U-Boot] [PATCH v2 00/10] splash screen on the stm32f769 disco board

2018-03-05 Thread Patrice CHOTARD
Hi Anatolij

On 03/05/2018 11:51 PM, Anatolij Gustschin wrote:
> On Fri, 2 Mar 2018 16:44:01 +0100
> yannick fertre yannick.fer...@st.com wrote:
> 
>> Version 2:
>> - Replace debug log by pr_error, pr_warn or pr_info.
>> - Rework bridge between ltdc & dsi panel
>> - Rework backligh management (with or witout gpio)
>> - Rework panel otm8009a
>> - Add new panel raydium rm68200
>>
>> Version 1:
>> - Initial commit
>>
>> This serie contains all patchsets needed for displaying a splash screen
>> on the stm32f769 disco board.
>>
>> yannick fertre (10):
>>video: stm32: stm32_ltdc: add bridge to display controller
>>video: stm32: stm32_ltdc: update debug log
>>video: add support of MIPI DSI interface
>>video: add support of panel OTM8009A
>>video: add MIPI DSI host controller bridge
>>video: add support of STM32 MIPI DSI controller driver
>>video: add support of panel rm68200
>>arm: dts: stm32: add dsi for STM32F746
>>arm: dts: stm32: add display for STM32F769 disco board
>>board: Add STM32F769 SoC, discovery board support
> 
> With this series applied some dtbs fail to build:
> ...
>DTC arch/arm/dts/stm32f746-disco.dtb
>DTC arch/arm/dts/stm32f769-disco.dtb
> Error: arch/arm/dts/stm32f746.dtsi:339.20-21 syntax error
> FATAL ERROR: Unable to parse input tree
> scripts/Makefile.lib:329: recipe for target 
> 'arch/arm/dts/stm32f746-disco.dtb' failed
> make[2]: *** [arch/arm/dts/stm32f746-disco.dtb] Error 1
> make[2]: *** Waiting for unfinished jobs
> Error: arch/arm/dts/stm32f746.dtsi:339.20-21 syntax error
> FATAL ERROR: Unable to parse input tree
> scripts/Makefile.lib:329: recipe for target 
> 'arch/arm/dts/stm32f769-disco.dtb' failed
> make[2]: *** [arch/arm/dts/stm32f769-disco.dtb] Error 1
> dts/Makefile:46: recipe for target 'arch-dtbs' failed
> make[1]: *** [arch-dtbs] Error 2
> Makefile:880: recipe for target 'dts/dt.dtb' failed
> make: *** [dts/dt.dtb] Error 2
> 
> There seems to be a dependency on patch for 
> include/dt-bindings/mfd/stm32f7-rcc.h
> adding some new macros. Is it also submitted to the list?

Right, needed patches are already on the list 
http://patchwork.ozlabs.org/patch/870938/

Patrice

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


Re: [U-Boot] [PATCH 2/2] usb: xhci-dwc3: Enable USB3 PHY when available

2018-03-05 Thread Bin Meng
Hi Vignesh,

On Mon, Mar 5, 2018 at 7:27 PM, Vignesh R  wrote:
> DWC3 USB3 controllers will need USB3 PHY to be enabled, in addition to
> USB2 PHY, to be functional. Therefore enable USB3 PHY when available.
>
> Signed-off-by: Vignesh R 
> ---
>  drivers/usb/host/xhci-dwc3.c | 35 +++
>  1 file changed, 35 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
> index cf1986bebd07..e7bc0bc35a86 100644
> --- a/drivers/usb/host/xhci-dwc3.c
> +++ b/drivers/usb/host/xhci-dwc3.c
> @@ -23,6 +23,7 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  struct xhci_dwc3_platdata {
> struct phy usb_phy;
> +   struct phy usb3_phy;
>  };
>
>  void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
> @@ -145,6 +146,26 @@ static int xhci_dwc3_probe(struct udevice *dev)
> }
> }
>
> +   ret = generic_phy_get_by_index(dev, 1, >usb3_phy);
> +   if (ret) {
> +   if (ret != -ENOENT) {
> +   pr_err("Failed to get USB3 PHY for %s\n", dev->name);
> +   return ret;
> +   }
> +   } else {
> +   ret = generic_phy_init(>usb3_phy);
> +   if (ret) {
> +   pr_err("Can't init USB3 PHY for %s\n", dev->name);
> +   return ret;
> +   }
> +
> +   ret = generic_phy_power_on(>usb3_phy);
> +   if (ret) {
> +   pr_err("Can't power on USB3 PHY for %s\n", dev->name);
> +   return ret;
> +   }
> +   }

This looks superfluous. Can we abstract the PHY operation to a new
function, and pass the phy pointer and index in?

> +
> dwc3_reg = (struct dwc3 *)((char *)(hccr) + DWC3_REG_OFFSET);
>
> dwc3_core_init(dwc3_reg);
> @@ -178,6 +199,20 @@ static int xhci_dwc3_remove(struct udevice *dev)
> }
> }
>
> +   if (generic_phy_valid(>usb3_phy)) {
> +   ret = generic_phy_power_off(>usb3_phy);
> +   if (ret) {
> +   pr_err("Can't poweroff USB3 PHY for %s\n", dev->name);
> +   return ret;
> +   }
> +
> +   ret = generic_phy_exit(>usb3_phy);
> +   if (ret) {
> +   pr_err("Can't deinit USB3 PHY for %s\n", dev->name);
> +   return ret;
> +   }
> +   }
> +

ditto

> return xhci_deregister(dev);
>  }
>

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


Re: [U-Boot] [PATCH 1/2] usb: xhci-dwc3: Power on USB PHY before using

2018-03-05 Thread Bin Meng
On Mon, Mar 5, 2018 at 7:27 PM, Vignesh R  wrote:
> It is wrong that expect phy init to also power on the PHY. Therefore,
> explicitly, call generic_phy_power_on() after generic_phy_power_init() in
> order to power on PHY before using it.
>
> Signed-off-by: Vignesh R 
> ---
>  drivers/usb/host/xhci-dwc3.c | 12 
>  1 file changed, 12 insertions(+)
>

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


[U-Boot] [PATCH] treewide: Fix gdsys mail addresses

2018-03-05 Thread Mario Six
From: Mario Six 

The @gdsys.cc addresses are supposed to be used for mailing lists.
Switch all occurrences of @gdsys.de mail addresses to their @gdsys.cc
equivalent.

Also, Dirk's address was wrong in one place; fix that as well.

Signed-off-by: Mario Six 
---
 board/gdsys/a38x/MAINTAINERS| 4 ++--
 board/gdsys/common/adv7611.c| 2 +-
 board/gdsys/common/fanctrl.c| 2 +-
 board/gdsys/common/fpga.c   | 2 +-
 board/gdsys/common/ihs_mdio.c   | 2 +-
 board/gdsys/common/ioep-fpga.c  | 2 +-
 board/gdsys/common/miiphybb.c   | 2 +-
 board/gdsys/common/osd.c| 2 +-
 board/gdsys/common/osd.h| 2 +-
 board/gdsys/common/phy.c| 2 +-
 board/gdsys/mpc8308/MAINTAINERS | 2 +-
 board/gdsys/mpc8308/Makefile| 2 +-
 board/gdsys/mpc8308/hrcon.c | 2 +-
 board/gdsys/mpc8308/mpc8308.c   | 2 +-
 board/gdsys/mpc8308/strider.c   | 2 +-
 board/gdsys/p1022/MAINTAINERS   | 2 +-
 drivers/gpio/mpc8xxx_gpio.c | 2 +-
 drivers/gpio/pca9698.c  | 2 +-
 drivers/i2c/ihs_i2c.c   | 2 +-
 drivers/tpm/tpm_atmel_twi.c | 2 +-
 include/configs/hrcon.h | 2 +-
 include/configs/strider.h   | 2 +-
 include/gdsys_fpga.h| 2 +-
 include/pca9698.h   | 2 +-
 24 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/board/gdsys/a38x/MAINTAINERS b/board/gdsys/a38x/MAINTAINERS
index 3cb9b63ff0..d31e675ddc 100644
--- a/board/gdsys/a38x/MAINTAINERS
+++ b/board/gdsys/a38x/MAINTAINERS
@@ -1,6 +1,6 @@
 A38X BOARD
-M: Dirk Eibach 
-M: Mario Six 
+M: Dirk Eibach 
+M: Mario Six 
 S: Maintained
 F: board/gdsys/a38x/
 F: include/configs/controlcenterdc.h
diff --git a/board/gdsys/common/adv7611.c b/board/gdsys/common/adv7611.c
index b728274cce..5355292280 100644
--- a/board/gdsys/common/adv7611.c
+++ b/board/gdsys/common/adv7611.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2014
- * Dirk Eibach, Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/fanctrl.c b/board/gdsys/common/fanctrl.c
index 44569bb1ab..52a4f33836 100644
--- a/board/gdsys/common/fanctrl.c
+++ b/board/gdsys/common/fanctrl.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2015
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/fpga.c b/board/gdsys/common/fpga.c
index e10c105feb..09c0446f90 100644
--- a/board/gdsys/common/fpga.c
+++ b/board/gdsys/common/fpga.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2013
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/ihs_mdio.c b/board/gdsys/common/ihs_mdio.c
index 262ead5516..822517d4b2 100644
--- a/board/gdsys/common/ihs_mdio.c
+++ b/board/gdsys/common/ihs_mdio.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2014
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/ioep-fpga.c b/board/gdsys/common/ioep-fpga.c
index f72a01e5b2..7ebce04a8a 100644
--- a/board/gdsys/common/ioep-fpga.c
+++ b/board/gdsys/common/ioep-fpga.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2014
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/miiphybb.c b/board/gdsys/common/miiphybb.c
index 310562902b..09b62253cd 100644
--- a/board/gdsys/common/miiphybb.c
+++ b/board/gdsys/common/miiphybb.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2010
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/osd.c b/board/gdsys/common/osd.c
index add9574369..454468ea3b 100644
--- a/board/gdsys/common/osd.c
+++ b/board/gdsys/common/osd.c
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2010
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/osd.h b/board/gdsys/common/osd.h
index 5b3f14bf05..a3b0e3d5ae 100644
--- a/board/gdsys/common/osd.h
+++ b/board/gdsys/common/osd.h
@@ -1,6 +1,6 @@
 /*
  * (C) Copyright 2010
- * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
diff --git a/board/gdsys/common/phy.c b/board/gdsys/common/phy.c
index fb92658178..45d2b81f37 

[U-Boot] [PATCH] core: ofnode: Fix translation for #size-cells == 0

2018-03-05 Thread Mario Six
Commit 286ede6 ("drivers: core: Add translation in live tree case") made
dev_get_addr always use proper bus translations for addresses read from
the device tree. But this leads to problems with certain busses, e.g.
I2C busses, which run into an error during translation, and hence stop
working.

It turns out that of_translate_address() and fdt_translate_address()
stop the address translation with an error when they're asked to
translate addresses for busses where #size-cells == 0 (comment from
drivers/core/of_addr.c):

 * Note: We consider that crossing any level with #size-cells == 0 to mean
 * that translation is impossible (that is we are not dealing with a value
 * that can be mapped to a cpu physical address). This is not really specified
 * that way, but this is traditionally the way IBM at least do things

To fix this case, we check in both the live-tree and non-live tree-case,
whether the bus of the device whose address is about to be translated
has size-cell size zero. If this is the case, we just read the address
as a plain integer and return it, and only apply bus translations if the
size-cell size if greater than zero.

Signed-off-by: Mario Six 
Signed-off-by: Martin Fuzzey 
Reported-by: Martin Fuzzey 
Fixes: 286ede6 ("drivers: core: Add translation in live tree case")
---
 drivers/core/fdtaddr.c | 17 +++--
 drivers/core/ofnode.c  |  5 -
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 3847dd836e..9a3b4c312a 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -49,12 +49,17 @@ fdt_addr_t devfdt_get_addr_index(struct udevice *dev, int 
index)
 
reg += index * (na + ns);
 
-   /*
-* Use the full-fledged translate function for complex
-* bus setups.
-*/
-   addr = fdt_translate_address((void *)gd->fdt_blob,
-dev_of_offset(dev), reg);
+   if (ns) {
+   /*
+* Use the full-fledged translate function for complex
+* bus setups.
+*/
+   addr = fdt_translate_address((void *)gd->fdt_blob,
+dev_of_offset(dev), reg);
+   } else {
+   /* Non translatable if #size-cells == 0 */
+   addr = fdt_read_number(reg, na);
+   }
} else {
/*
 * Use the "simple" translate function for less complex
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 98f4b539ea..b2f6ffe385 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -200,13 +200,16 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
uint flags;
u64 size;
int na;
+   int ns;
 
prop_val = of_get_address(ofnode_to_np(node), index, ,
  );
if (!prop_val)
return FDT_ADDR_T_NONE;
 
-   if (IS_ENABLED(CONFIG_OF_TRANSLATE)) {
+   ns = of_n_size_cells(ofnode_to_np(node));
+
+   if (IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0) {
return of_translate_address(ofnode_to_np(node), 
prop_val);
} else {
na = of_n_addr_cells(ofnode_to_np(node));
-- 
2.11.0

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


Re: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support

2018-03-05 Thread Jagan Teki
On Wed, Feb 28, 2018 at 3:12 PM, Prabhakar Kushwaha
 wrote:
> [Resending on correct patch of the patch-set]
>
> Dear Jagan,
>
>
>> -Original Message-
>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jagan
>> Teki
>> Sent: Thursday, December 28, 2017 11:42 AM
>> To: u-boot@lists.denx.de
>> Cc: Tom Rini 
>> Subject: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support
>>
>> Some of the SPI device drivers at drivers/spi not a real spi controllers, 
>> Unlike
>> normal/generic SPI controllers they operates only with SPI-NOR flash
>> devices. these were technically termed as SPI-NOR controllers, Ex:
>> drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire SPI layer
>> becomes SPI-NOR flash oriented which is absolutely a wrong indication
>> where SPI layer getting effected more with flash operations - So this SPI-NOR
>> core will resolve this issue by separating all SPI-NOR flash operations from 
>> spi
>> layer and creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR controller
>> driver. The idea is taken from Linux spi-nor framework.
>>
>> ===
>>  cmd/spinor.c
>> ===
>>  mtd-uclass.c
>> ===
>>spi-nor-uclass.c
>> ===
>>   spi-nor.c
>> ===
>> m25p80.czynq_qspinor.c
>> ===
>> spi-uclass.c
>> ===
>> zynq_qspi.c
>> ===
>> #SPI NOR chip##
>> ===
>>
>
> As per this patch-set, fsl_qspi is looks to be getting proposed in 
> driver/mtd/spi-nor/ folder.
>
> fsl_qspi is supporting both flash and fpga.  We are not sure about its 
> location.
>
> There is an on-going effort for similar type of requirement in Linux by Boris 
> Brezillon . It is dealing with controllers supporting NORs, NANDs, SRAMs etc.
> http://patchwork.ozlabs.org/project/linux-mtd/list/?series=27088
>
> Borris has also ported fsl_qspi in driver/spi to use this new framework. It 
> is still not completely tested.
> https://github.com/bbrezillon/linux/commit/43cc45764b975bfbb191de3f6a37e073da1a2706

These look going in reverse direction, since
drivers/mtd/spi-nor/fsl_qspi was meant for SPI-NOR flash(from initial
version SPI-NOR framework patches) and now it going in driver/spi..
look like it need more discussion with respective people who involved
on these.

>
>
> Will you also follow similar approach as being done in 
> http://patchwork.ozlabs.org/project/linux-mtd/list/?series=27088 for longer 
> term?
>
> For Now, We are planning to update fsl_qspi driver to support dynamic LUT. 
> Similar patch is in progress in Linux 
> http://patchwork.ozlabs.org/project/linux-mtd/list/?series=26084
> Now we are confused, should be port fsl_qspi in driver/mtd/spi-nor and then 
> update driver Or We update driver/spi/fsl_qspi for dynamic LUTs. We may need 
> to modify existing framework to get all required info for dynamic LUT.

As of now, I would like to write it in driver/mtd/spi-nor assuming all
LUT or fsl related changes donesn't harm core areas so-that moving
back to drivers/spi might be easy if Linux does.

>
> Also we want some change in framework like support of
>  -  4 byte address and SFDP :  
> http://patchwork.ozlabs.org/project/uboot/list/?series=19621=*
>  -  SMPT : in discussion in Linux http://patchwork.ozlabs.org/patch/869718/
>  Which code base should we use?   u-boot-spi.git branch mtd-spinor-working  
> or u-boot.git master branch

Pls use this https://github.com/openedev/u-boot-spi/commits/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support

2018-03-05 Thread Prabhakar Kushwaha
Dear Jagan,


> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Wednesday, February 28, 2018 5:40 PM
> To: Prabhakar Kushwaha ; Jagan Teki
> ; Cyrille Pitchen
> 
> Cc: u-boot@lists.denx.de; Suresh Gupta ; Yogesh
> Narayan Gaur ; Poonam Aggrwal
> ; Ashish Kumar ;
> Han Xu ; Frieder Schrempf
> ; Boris Brezillon  electrons.com>
> Subject: Re: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support
> 
> Prabhakar, Jagan,
> 
> On Wed, 28 Feb 2018 09:42:11 +
> Prabhakar Kushwaha  wrote:
> 
> > [Resending on correct patch of the patch-set]
> >
> > Dear Jagan,
> >
> >
> > > -Original Message-
> > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> > > Jagan Teki
> > > Sent: Thursday, December 28, 2017 11:42 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Tom Rini 
> > > Subject: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support
> > >
> > > Some of the SPI device drivers at drivers/spi not a real spi
> > > controllers, Unlike normal/generic SPI controllers they operates
> > > only with SPI-NOR flash devices. these were technically termed as
> > > SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> 
> Okay, I've been working a bit with this controller, and can say it's
> not quite true. This controller supports any kind of device that
> expects memory-like operations (or whatever you want to call them),
> that is, everything that is formed of one opcode, X address cycles, Y
> dummy cycles and Z data in/out cycles (X, Y and Z can be zero).

> Actually, I even think it could support regular SPI transfers, all we'd
> have to do is use READ/WRITE instructions to do the transfers.

> > > 
> > > The problem with these were resides at drivers/spi is entire SPI
> > > layer becomes SPI-NOR flash oriented which is absolutely a wrong
> > > indication where SPI layer getting effected more with flash
> > > operations - So this SPI-NOR core will resolve this issue by
> > > separating all SPI-NOR flash operations from spi layer and creats a
> > > generic layer called SPI-NOR core which can be used to interact
> > > SPI-NOR to SPI driver interface layer and the SPI-NOR controller
> > > driver. The idea is taken from Linux spi-nor framework.

> I've discussed it privately with Cyrille before I sent the spi-mem
> extension proposal, and he seemed to agree with the approach. I don't
> know what his opinion is now that the RFC has been posted, but if he
> hasn't changed his mind, that means Linux implementation is going in
> the opposite direction. So it's probably worth reconsidering this move.

> Cyrille, could you clarify your opinion? I'm also waiting your feedback
> on the RFC to send a v2 addressing the comments I had from other people.

> > > 
> > > ===
> > > cmd/spinor.c
> > > ===
> > >  mtd-uclass.c
> > > ===
> > >   spi-nor-uclass.c
> > > ===
> > >   spi-nor.c
> > > ===
> > > m25p80.czynq_qspinor.c
> > > ===
> > > spi-uclass.c
> > > ===
> > > zynq_qspi.c
> > > ===
> > > #SPI NOR chip##
> > > ===
> > >   
> 
> > As per this patch-set, fsl_qspi is looks to be getting proposed in
> > driver/mtd/spi-nor/ folder.
> > 
> > fsl_qspi is supporting both flash and fpga.  We are not sure about
> > its location. 
> > 
> > There is an on-going effort for similar type of requirement in Linux
> > by Boris Brezillon . It is dealing with controllers supporting NORs,
> > NANDs, SRAMs etc.
> > http://patchwork.ozlabs.org/project/linux-mtd/list/?series=27088
> > 
> > Borris has also ported fsl_qspi in driver/spi to use this new
> > framework. It is still not completely tested.
> > https://github.com/bbrezillon/linux/commit/43cc45764b975bfbb191de3f6a37e073da1a2706
> > 
> > 
> > Will you also follow similar approach as being done in
> > http://patchwork.ozlabs.org/project/linux-mtd/list/?series=27088 for
> > longer term?

> That would be great if the code base could converge.

Please help us with your strategy towards qspi framework.
We are waiting for your direction before creating/sending patches of qspi 
driver & framework in upstream. 

--pk


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


Re: [U-Boot] [PATCH 0/3] clk: at91: add usb and plladiv drivers

2018-03-05 Thread Wenyou Yang

Hi,

Do you have any comments?


On 2/9/2018 11:34 AM, Wenyou Yang wrote:

In order to provide the clocks UHP48MHz and UHP12MHz to the USB
Host OHCI, add the USB clock and PLLADIV clock driver.


Wenyou Yang (3):
   clk: at91: add USB Host clock driver
   clk: at91: add PLLADIV driver
   clk: at91: clk-system: add set/get_rate operations

  arch/arm/mach-at91/include/mach/at91_pmc.h |   6 ++
  drivers/clk/at91/Kconfig   |   8 ++
  drivers/clk/at91/Makefile  |   3 +-
  drivers/clk/at91/clk-plladiv.c |  88 +
  drivers/clk/at91/clk-system.c  |  26 +
  drivers/clk/at91/clk-usb.c | 146 +
  6 files changed, 276 insertions(+), 1 deletion(-)
  create mode 100644 drivers/clk/at91/clk-plladiv.c
  create mode 100644 drivers/clk/at91/clk-usb.c



Best Regards,
Wenyou Yang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] mmc: add HS400 support

2018-03-05 Thread Peng Fan
Hi, 
On Mon, Mar 05, 2018 at 05:29:08PM +0100, Jean-Jacques Hiblot wrote:
>Hi Peng,
>
>I'm glad you are adding HS400 support. Thanks.
>
>
>On 05/03/2018 10:11, Peng Fan wrote:
>>Add HS400 support.
>>Selecting HS400 needs first select HS199 according to spec, so use
>>a dedicated function for HS400.
>>Add HS400 related macros.
>>Remove the restriction of only using the low 6 bits of
>>EXT_CSD_CARD_TYPE, using all the 8 bits.
>>
>>Signed-off-by: Peng Fan 
>>Cc: Jaehoon Chung 
>>Cc: Jean-Jacques Hiblot 
>>Cc: Stefano Babic 
>>Cc: Simon Glass 
>>Cc: Kishon Vijay Abraham I 
>>Cc: Bin Meng 
>>---
>>  drivers/mmc/Kconfig |   7 +++
>>  drivers/mmc/mmc.c   | 133 
>> ++--
>>  include/mmc.h   |  12 +
>>  3 files changed, 127 insertions(+), 25 deletions(-)
>>
>>diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>index 5f67e336db..e9be18b333 100644
>>--- a/drivers/mmc/Kconfig
>>+++ b/drivers/mmc/Kconfig
>>@@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
>>cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
>>frequency can go up to 208MHz (SDR104)
>>+config MMC_HS400_SUPPORT
>>+ bool "enable HS400 support"
>>+ select MMC_HS200_SUPPORT
>I'd use "depends on" instead of select or maybe use the same option
>for both HS200 and HS400
>>+ help
>>+   The HS400 mode is support by some eMMC. The bus frequency is up to
>>+   200MHz. This mode requires tuning the IO.
>>+
>>  config MMC_HS200_SUPPORT
>>  bool "enable HS200 support"
>>  help
>>diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>index 92ea78b8af..eef229c8b4 100644
>>--- a/drivers/mmc/mmc.c
>>+++ b/drivers/mmc/mmc.c
>>@@ -169,6 +169,7 @@ const char *mmc_mode_name(enum bus_mode mode)
>>[MMC_HS_52]   = "MMC High Speed (52MHz)",
>>[MMC_DDR_52]  = "MMC DDR52 (52MHz)",
>>[MMC_HS_200]  = "HS200 (200MHz)",
>>+   [MMC_HS_400]  = "HS400 (200MHz)",
>>  };
>>  if (mode >= MMC_MODES_END)
>>@@ -193,6 +194,7 @@ static uint mmc_mode2freq(struct mmc *mmc, enum bus_mode 
>>mode)
>>[UHS_DDR50]   = 5000,
>>[UHS_SDR104]  = 20800,
>>[MMC_HS_200]  = 2,
>>+   [MMC_HS_400]  = 2,
>>  };
>>  if (mode == MMC_LEGACY)
>>@@ -790,6 +792,11 @@ static int mmc_set_card_speed(struct mmc *mmc, enum 
>>bus_mode mode)
>>  case MMC_HS_200:
>>  speed_bits = EXT_CSD_TIMING_HS200;
>>  break;
>>+#endif
>>+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
>>+ case MMC_HS_400:
>>+ speed_bits = EXT_CSD_TIMING_HS400;
>>+ break;
>>  #endif
>>  case MMC_LEGACY:
>>  speed_bits = EXT_CSD_TIMING_LEGACY;
>>@@ -837,7 +844,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
>>  mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
>>- cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0x3f;
>>+ cardtype = ext_csd[EXT_CSD_CARD_TYPE];
>>  mmc->cardtype = cardtype;
>>  #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
>>@@ -845,6 +852,12 @@ static int mmc_get_capabilities(struct mmc *mmc)
>>  EXT_CSD_CARD_TYPE_HS200_1_8V)) {
>>  mmc->card_caps |= MMC_MODE_HS200;
>>  }
>>+#endif
>>+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
>>+ if (cardtype & (EXT_CSD_CARD_TYPE_HS400_1_2V |
>>+ EXT_CSD_CARD_TYPE_HS400_1_8V)) {
>>+ mmc->card_caps |= MMC_MODE_HS400;
>>+ }
>>  #endif
>>  if (cardtype & EXT_CSD_CARD_TYPE_52) {
>>  if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
>>@@ -1748,6 +1761,12 @@ static int mmc_set_lowest_voltage(struct mmc *mmc, 
>>enum bus_mode mode,
>>  u32 card_mask = 0;
>>  switch (mode) {
>>+ case MMC_HS_400:
>>+ if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS400_1_8V)
>>+ card_mask |= MMC_SIGNAL_VOLTAGE_180;
>>+ if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS400_1_2V)
>>+ card_mask |= MMC_SIGNAL_VOLTAGE_120;
>>+ break;
>>  case MMC_HS_200:
>>  if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS200_1_8V)
>>  card_mask |= MMC_SIGNAL_VOLTAGE_180;
>>@@ -1787,6 +1806,13 @@ static inline int mmc_set_lowest_voltage(struct mmc 
>>*mmc, enum bus_mode mode,
>>  #endif
>>  static const struct mode_width_tuning mmc_modes_by_pref[] = {
>>+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
>>+ {
>>+ .mode = MMC_HS_400,
>>+ .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
>>+ .tuning = MMC_CMD_SEND_TUNING_BLOCK_HS200
>>+ },
>>+#endif
>>  #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
>>  {
>>  .mode = MMC_HS_200,
>>@@ -1830,6 +1856,54 @@ static const struct ext_csd_bus_width {
>>  {MMC_MODE_1BIT, false, EXT_CSD_BUS_WIDTH_1},
>>  };
>>+#if 

[U-Boot] [ANN] U-Boot v2018.03-rc4 released

2018-03-05 Thread Tom Rini
Hey all,

It's release day and I've released v2018.03-rc4.  I've included a few
different regression fixes I've seen along with some fixes and cleanups.
I would like to do the release on March 12th, and likely will so long as
no big regressions show up.  I am worried about the RPi3 issue I've seen
reported.  Are there any other issues people know of currently?

And to repeat myself again, boards and SoC families, etc, that have been
orphaned for more than a year should probably get dropped.  I've
contacted a few people off-list (which is why we've had a few pickups of
late) for things, but if you know someone that would be interested in
something, please speak up.

Thanks all!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


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

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 09:33:12PM +0100, Marek Vasut wrote:

> Hi,
> 
> below is the final PR for 2018.03 from me. It adds R8A77965 M3N and a
> matching board. All that are mostly various IDs, since on this level the
> SoC is ~compatible with 7796 . There are two critical fixes though, the
> PFC one and the PHY reset GPIO.
> 
> btw it'd be nice if the release didn't overlap with ELC.
> 
> The following changes since commit 77bba970e2372b01156c66585db3d6fc751c7178:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-socfpga (2018-03-01
> 15:50:52 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to b2c38dc3d3693578e8067ca2333ab3f6e6cc00d4:
> 
>   ARM: dts: rmobile: Add PHY reset GPIO (2018-03-05 11:48:53 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 00/16] arm: stm32mp1: add initial support for STM32MP157

2018-03-05 Thread Vikas Manocha
Hi Patrick,

On 03/05/2018 06:24 AM, Patrick Delaunay wrote:
> 
> This patch-set adds initial support of STMicroelectronics STM32MP157
> microprocessor (MPU)
> - add new arm arch stm32mp1 (based on armv7)
> - support for stm32mp157 SOC (based on Cortex-A7)
> - add minimal support for board evaluation board STM32MP157C-ED1
I see patches for ram driver, armv7 generic, stm32f7  etc. in this patchset.
Please split the stuff other than STM32MP1 support in separate patch/patchset.

Cheers,
Vikas

> 
> 
> Patrick Delaunay (16):
>   tools/mkimage: add support for STM32 image format
>   spl: add SPL_RESET_SUPPORT
>   common: add a prototype for mach_cpu_init()
>   arm: armv7: solve issue for timer_rate_hz in arch timer
>   dm: gpio: Convert stm32f7 driver to livetree
>   gpio: stm32f7_gpio: handle node ngpios
>   stm32mp: stm32f7_i2c: use calloc instead of kmalloc
>   arm: stm32: add new architecture for STM32MP family
>   ram: stm32mp1: add driver
>   pmic: add stpmu1 support
>   pinctrl: stm32: update pincontrol for stmp32mp157
>   reset: stm32: adapt driver for stm32mp1
>   clk: add driver for stm32mp1
>   clk: stm32mp1: add clock tree initialization
>   dts: add device tree for STM32MP157C-ED1 board
>   board: st: add generic board for STM32MP1 family
> 
>  MAINTAINERS|7 +
>  arch/arm/Kconfig   |   25 +-
>  arch/arm/Makefile  |1 +
>  arch/arm/cpu/armv7/arch_timer.c|   22 +-
>  arch/arm/dts/Makefile  |3 +
>  arch/arm/dts/stm32mp15-ddr.dtsi|  155 ++
>  arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi   |  122 ++
>  arch/arm/dts/stm32mp157-u-boot.dtsi|  134 ++
>  arch/arm/dts/stm32mp157.dtsi   |  303 
>  arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   |  133 ++
>  arch/arm/dts/stm32mp157c-ed1.dts   |  167 ++
>  arch/arm/mach-stm32mp/Kconfig  |   43 +
>  arch/arm/mach-stm32mp/Makefile |   10 +
>  arch/arm/mach-stm32mp/config.mk|   14 +
>  arch/arm/mach-stm32mp/cpu.c|  139 ++
>  arch/arm/mach-stm32mp/dram_init.c  |   34 +
>  arch/arm/mach-stm32mp/include/mach/ddr.h   |   12 +
>  arch/arm/mach-stm32mp/include/mach/gpio.h  |  115 ++
>  arch/arm/mach-stm32mp/include/mach/stm32.h |   27 +
>  arch/arm/mach-stm32mp/spl.c|   60 +
>  board/st/stm32mp1/Kconfig  |   12 +
>  board/st/stm32mp1/MAINTAINERS  |7 +
>  board/st/stm32mp1/Makefile |   13 +
>  board/st/stm32mp1/README   |  191 +++
>  board/st/stm32mp1/board.c  |   75 +
>  board/st/stm32mp1/spl.c|   33 +
>  board/st/stm32mp1/stm32mp1.c   |   27 +
>  common/image.c |1 +
>  common/spl/Kconfig |9 +
>  configs/stm32mp15_basic_defconfig  |   36 +
>  doc/device-tree-bindings/clock/st,stm32mp1.txt |  226 +++
>  doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt   |  299 
>  drivers/Makefile   |1 +
>  drivers/clk/Kconfig|8 +
>  drivers/clk/Makefile   |1 +
>  drivers/clk/clk_stm32mp1.c | 1733 
> 
>  drivers/gpio/Kconfig   |2 +-
>  drivers/gpio/stm32f7_gpio.c|   15 +-
>  drivers/i2c/Kconfig|2 +-
>  drivers/i2c/stm32f7_i2c.c  |4 +-
>  drivers/pinctrl/pinctrl_stm32.c|9 +-
>  drivers/power/pmic/Kconfig |8 +
>  drivers/power/pmic/Makefile|1 +
>  drivers/power/pmic/stpmu1.c|   62 +
>  drivers/ram/Kconfig|2 +
>  drivers/ram/Makefile   |1 +
>  drivers/ram/stm32mp1/Kconfig   |   12 +
>  drivers/ram/stm32mp1/Makefile  |8 +
>  drivers/ram/stm32mp1/stm32mp1_ddr.c|  496 ++
>  drivers/ram/stm32mp1/stm32mp1_ddr.h|  210 +++
>  drivers/ram/stm32mp1/stm32mp1_ddr_regs.h   |  365 +
>  drivers/ram/stm32mp1/stm32mp1_ram.c|  197 +++
>  drivers/reset/Kconfig  |2 +-
>  drivers/reset/stm32-reset.c|   36 +-
>  drivers/serial/Kconfig |6 +-
>  include/common.h   |   10 +
>  include/configs/stm32mp1.h |   97 ++
>  include/dt-bindings/clock/stm32mp1-clks.h  |  243 +++
>  

Re: [U-Boot] Whitelist scripting

2018-03-05 Thread Tuomas Tynkkynen
Hi,

On Mon, 5 Mar 2018 14:08:20 -0600
Adam Ford  wrote:

...
> 
> What I was hoping to do was help clean the whitelist table by first
> searching for #defines that are never used anywhere and/or are dead.I
> will be the first person to admit that I am not very good with shell
> scripts, so I thought I'd solicit a favor.
> 
> Does someone have any cool scripts that we can use the scan through
> the and look for #defines that have no #ifdef, Makefile dependancy, or
> linker script attachment?  These seem like they'd be obvious chunks of
> code to eliminate.

I personally started with a lower-hanging fruit: config symbols that
are referenced exactly once. For that I use the following hacks
that I just pick from the shell history with Ctrl-R every now and then :)

rm -rf grep-counts; mkdir grep-counts; for f in $(cat 
scripts/config_whitelist.txt); do git grep $f > grep-counts/$f; done

This just builds a "database" of occurences for each symbol in the whitelist. 
Then:

for f in $(wc -l grep-counts/* | awk '$1 == 2' | tr / ' ' | awk '{print $3}'); 
do cat grep-counts/$f; done | grep ':#define'

This lists all the symbols from the database that are only #define'd exactly 
once
(it checks for '2' to account for the match in config_whitelist.txt).

Hope that helps. Don't try to remove the same symbols I removed in my latest 3
patches to the list though :)

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


[U-Boot] [PATCH 3/3] ARM: Drop unreferenced CONFIG_* defines named after boards

2018-03-05 Thread Tuomas Tynkkynen
The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_AT91SAM9263EK
CONFIG_AT91SAM9RLEK
CONFIG_BARIX_IPAM390
CONFIG_BOARD_H2200
CONFIG_EP9301
CONFIG_KZM_A9_GT
CONFIG_PICOSAM
CONFIG_PLATINUM_PICON
CONFIG_PLATINUM_TITANIUM
CONFIG_PM9261
CONFIG_PM9263
CONFIG_PM9G45
CONFIG_SIEMENS_DRACO
CONFIG_SIEMENS_PXM2
CONFIG_SIEMENS_RUT
CONFIG_SMDKC100
CONFIG_SMDKV310
CONFIG_STM32F4DISCOVERY

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/at91sam9263ek.h   |  2 --
 include/configs/at91sam9rlek.h|  2 --
 include/configs/draco.h   |  1 -
 include/configs/edb93xx.h |  1 -
 include/configs/h2200.h   |  1 -
 include/configs/ipam390.h |  1 -
 include/configs/kzm9g.h   |  1 -
 include/configs/picosam9g45.h |  2 --
 include/configs/platinum_picon.h  |  1 -
 include/configs/platinum_titanium.h   |  1 -
 include/configs/pm9261.h  |  1 -
 include/configs/pm9263.h  |  1 -
 include/configs/pm9g45.h  |  1 -
 include/configs/pxm2.h|  1 -
 include/configs/rut.h |  1 -
 include/configs/smdkc100.h|  1 -
 include/configs/smdkv310.h|  1 -
 include/configs/stm32f429-discovery.h |  2 --
 include/configs/stm32f469-discovery.h |  2 --
 scripts/config_whitelist.txt  | 18 --
 20 files changed, 42 deletions(-)

diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
index b6691feb68..7fe51c2c0b 100644
--- a/include/configs/at91sam9263ek.h
+++ b/include/configs/at91sam9263ek.h
@@ -21,8 +21,6 @@
 #define CONFIG_SYS_AT91_MAIN_CLOCK 16367660 /* 16.367 MHz crystal */
 #define CONFIG_SYS_AT91_SLOW_CLOCK 32768
 
-#define CONFIG_AT91SAM9263EK   1   /* It's an AT91SAM9263EK Board */
-
 #define CONFIG_ARCH_CPU_INIT
 
 #define CONFIG_CMDLINE_TAG 1   /* enable passing of ATAGs  */
diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h
index 08c8f48bb5..6f8fd2a035 100644
--- a/include/configs/at91sam9rlek.h
+++ b/include/configs/at91sam9rlek.h
@@ -17,8 +17,6 @@
 #define CONFIG_SYS_AT91_SLOW_CLOCK 32768   /* slow clock xtal */
 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200/* main clock xtal */
 
-#define CONFIG_AT91SAM9RLEK1   /* It's an AT91SAM9RLEK Board */
-
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
diff --git a/include/configs/draco.h b/include/configs/draco.h
index 3278196b3a..c1816409a9 100644
--- a/include/configs/draco.h
+++ b/include/configs/draco.h
@@ -13,7 +13,6 @@
 #ifndef __CONFIG_DRACO_H
 #define __CONFIG_DRACO_H
 
-#define CONFIG_SIEMENS_DRACO
 #define CONFIG_SIEMENS_MACH_TYPE   MACH_TYPE_DRACO
 
 #include "siemens-am33x-common.h"
diff --git a/include/configs/edb93xx.h b/include/configs/edb93xx.h
index 6e024d1b2f..18ec6cb758 100644
--- a/include/configs/edb93xx.h
+++ b/include/configs/edb93xx.h
@@ -34,7 +34,6 @@
 #define CONFIG_SYS_LDSCRIPT"board/cirrus/edb93xx/u-boot.lds"
 
 #ifdef CONFIG_EDB9301
-#define CONFIG_EP9301
 #define CONFIG_MACH_TYPE   MACH_TYPE_EDB9301
 #define CONFIG_ENV_SECT_SIZE   0x0002
 #elif defined(CONFIG_EDB9302)
diff --git a/include/configs/h2200.h b/include/configs/h2200.h
index 608f5eec32..4b380beee2 100644
--- a/include/configs/h2200.h
+++ b/include/configs/h2200.h
@@ -12,7 +12,6 @@
 #define CONFIG_MACH_TYPE   MACH_TYPE_H2200
 
 #define CONFIG_CPU_PXA25X  1
-#define CONFIG_BOARD_H2200
 
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0xa000 /* SDRAM Bank #1 */
diff --git a/include/configs/ipam390.h b/include/configs/ipam390.h
index 82ab24c688..c8e99513f0 100644
--- a/include/configs/ipam390.h
+++ b/include/configs/ipam390.h
@@ -19,7 +19,6 @@
  * Board
  */
 #define CONFIG_DRIVER_TI_EMAC
-#define CONFIG_BARIX_IPAM390
 
 /*
  * SoC Configuration
diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
index 0d8de370dd..82984f4d17 100644
--- a/include/configs/kzm9g.h
+++ b/include/configs/kzm9g.h
@@ -11,7 +11,6 @@
 #undef DEBUG
 
 #define CONFIG_SH73A0
-#define CONFIG_KZM_A9_GT
 #define CONFIG_ARCH_RMOBILE_BOARD_STRING   "KMC KZM-A9-GT"
 #define CONFIG_MACH_TYPE MACH_TYPE_KZM9G
 
diff --git a/include/configs/picosam9g45.h b/include/configs/picosam9g45.h
index 06ee8e7f9e..0d4fc119ac 100644
--- a/include/configs/picosam9g45.h
+++ b/include/configs/picosam9g45.h
@@ -22,8 +22,6 @@
 #define CONFIG_SYS_AT91_SLOW_CLOCK  32768
 #define CONFIG_SYS_AT91_MAIN_CLOCK  1200 /* from 12 MHz crystal */
 
-#define CONFIG_PICOSAM
-
 #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs  */
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
diff --git a/include/configs/platinum_picon.h 

[U-Boot] [PATCH 1/3] MIPS: Drop unreferenced CONFIG_* defines

2018-03-05 Thread Tuomas Tynkkynen
The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_DBAU1X00
CONFIG_PB1X00

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/dbau1x00.h   | 1 -
 include/configs/pb1x00.h | 1 -
 scripts/config_whitelist.txt | 2 --
 3 files changed, 4 deletions(-)

diff --git a/include/configs/dbau1x00.h b/include/configs/dbau1x00.h
index ebd2c23960..f00111a8c4 100644
--- a/include/configs/dbau1x00.h
+++ b/include/configs/dbau1x00.h
@@ -12,7 +12,6 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_DBAU1X001
 #define CONFIG_SOC_AU1X00  1  /* alchemy series cpu */
 
 #ifdef CONFIG_DBAU1000
diff --git a/include/configs/pb1x00.h b/include/configs/pb1x00.h
index 972c13a625..8adb7d7cfa 100644
--- a/include/configs/pb1x00.h
+++ b/include/configs/pb1x00.h
@@ -12,7 +12,6 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_PB1X00  1
 #define CONFIG_SOC_AU1X00  1  /* alchemy series cpu */
 
 #ifdef CONFIG_PB1000
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index a42b64d209..f63d95f967 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -325,7 +325,6 @@ CONFIG_DA850_AM18X_EVM
 CONFIG_DA850_EVM_MAX_CPU_CLK
 CONFIG_DA8XX_GPIO
 CONFIG_DBAU1000
-CONFIG_DBAU1X00
 CONFIG_DBGU
 CONFIG_DBG_MONITOR
 CONFIG_DB_784MP_GP
@@ -1496,7 +1495,6 @@ CONFIG_PARAVIRT
 CONFIG_PB1000
 CONFIG_PB1100
 CONFIG_PB1500
-CONFIG_PB1X00
 CONFIG_PCA953X
 CONFIG_PCA9698
 CONFIG_PCI1
-- 
2.16.1

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


[U-Boot] [PATCH 2/3] ARM: Drop unreferenced CONFIG_* defines named after SoCs

2018-03-05 Thread Tuomas Tynkkynen
The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_ARM926EJS
CONFIG_CPUAT91
CONFIG_EXYNOS5800
CONFIG_SYS_CORTEX_R4

Most of them are config symbols named after the respective SoCs which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/at91rm9200ek.h  | 1 -
 include/configs/exynos5420-common.h | 2 --
 include/configs/omapl138_lcdk.h | 1 -
 include/configs/stv0991.h   | 2 --
 scripts/config_whitelist.txt| 4 
 5 files changed, 10 deletions(-)

diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h
index 9ce0a8f9bf..8c27122c00 100644
--- a/include/configs/at91rm9200ek.h
+++ b/include/configs/at91rm9200ek.h
@@ -44,7 +44,6 @@
 /* CPU configuration */
 #define CONFIG_AT91RM9200
 #define CONFIG_AT91RM9200EK
-#define CONFIG_CPUAT91
 #define USE_920T_MMU
 
 #include   /* needed for port definitions */
diff --git a/include/configs/exynos5420-common.h 
b/include/configs/exynos5420-common.h
index ae9ead53f6..e13092515a 100644
--- a/include/configs/exynos5420-common.h
+++ b/include/configs/exynos5420-common.h
@@ -10,8 +10,6 @@
 #define __CONFIG_EXYNOS5420_H
 
 #define CONFIG_EXYNOS5420
-/* A variant of Exynos5420 (Exynos5 Family) */
-#define CONFIG_EXYNOS5800
 
 #define CONFIG_EXYNOS5_DT
 
diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index 837286bd78..ea7bdf133d 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -23,7 +23,6 @@
  * SoC Configuration
  */
 #define CONFIG_MACH_OMAPL138_LCDK
-#define CONFIG_ARM926EJS   /* arm926ejs CPU core */
 #define CONFIG_SYS_CLK_FREQclk_get(DAVINCI_ARM_CLKID)
 #define CONFIG_SYS_OSCIN_FREQ  2400
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
index 0c08556d21..2401dbd619 100644
--- a/include/configs/stv0991.h
+++ b/include/configs/stv0991.h
@@ -10,8 +10,6 @@
 #define CONFIG_SYS_DCACHE_OFF
 #define CONFIG_SYS_EXCEPTION_VECTORS_HIGH
 
-#define CONFIG_SYS_CORTEX_R4
-
 /* ram memory-related information */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index f63d95f967..6ea78bd14e 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -50,7 +50,6 @@ CONFIG_ARCH_USE_BUILTIN_BSWAP
 CONFIG_ARC_MMU_VER
 CONFIG_ARC_SERIAL
 CONFIG_ARIES_M28_V10
-CONFIG_ARM926EJS
 CONFIG_ARMADA100
 CONFIG_ARMADA100_FEC
 CONFIG_ARMADA168
@@ -272,7 +271,6 @@ CONFIG_CORTINA_FW_LENGTH
 CONFIG_CPLD_BR_PRELIM
 CONFIG_CPLD_OR_PRELIM
 CONFIG_CPM2
-CONFIG_CPUAT91
 CONFIG_CPU_ARCHS34
 CONFIG_CPU_ARMV8
 CONFIG_CPU_CAVIUM_OCTEON
@@ -598,7 +596,6 @@ CONFIG_EXYNOS4210
 CONFIG_EXYNOS5
 CONFIG_EXYNOS5250
 CONFIG_EXYNOS5420
-CONFIG_EXYNOS5800
 CONFIG_EXYNOS5_DT
 CONFIG_EXYNOS7420
 CONFIG_EXYNOS_ACE_SHA
@@ -2255,7 +2252,6 @@ CONFIG_SYS_CMXFCR_VALUE2
 CONFIG_SYS_CMXFCR_VALUE3
 CONFIG_SYS_CORE_SRAM
 CONFIG_SYS_CORE_SRAM_SIZE
-CONFIG_SYS_CORTEX_R4
 CONFIG_SYS_CORTINA_FW_IN_MMC
 CONFIG_SYS_CORTINA_FW_IN_NAND
 CONFIG_SYS_CORTINA_FW_IN_NOR
-- 
2.16.1

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


Re: [U-Boot] [PATCH v2 00/10] splash screen on the stm32f769 disco board

2018-03-05 Thread Anatolij Gustschin
On Fri, 2 Mar 2018 16:44:01 +0100
yannick fertre yannick.fer...@st.com wrote:

> Version 2:
> - Replace debug log by pr_error, pr_warn or pr_info.
> - Rework bridge between ltdc & dsi panel
> - Rework backligh management (with or witout gpio)
> - Rework panel otm8009a
> - Add new panel raydium rm68200
> 
> Version 1:
> - Initial commit
> 
> This serie contains all patchsets needed for displaying a splash screen 
> on the stm32f769 disco board.
> 
> yannick fertre (10):
>   video: stm32: stm32_ltdc: add bridge to display controller
>   video: stm32: stm32_ltdc: update debug log
>   video: add support of MIPI DSI interface
>   video: add support of panel OTM8009A
>   video: add MIPI DSI host controller bridge
>   video: add support of STM32 MIPI DSI controller driver
>   video: add support of panel rm68200
>   arm: dts: stm32: add dsi for STM32F746
>   arm: dts: stm32: add display for STM32F769 disco board
>   board: Add STM32F769 SoC, discovery board support

With this series applied some dtbs fail to build:
...
  DTC arch/arm/dts/stm32f746-disco.dtb
  DTC arch/arm/dts/stm32f769-disco.dtb
Error: arch/arm/dts/stm32f746.dtsi:339.20-21 syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:329: recipe for target 'arch/arm/dts/stm32f746-disco.dtb' 
failed
make[2]: *** [arch/arm/dts/stm32f746-disco.dtb] Error 1
make[2]: *** Waiting for unfinished jobs
Error: arch/arm/dts/stm32f746.dtsi:339.20-21 syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:329: recipe for target 'arch/arm/dts/stm32f769-disco.dtb' 
failed
make[2]: *** [arch/arm/dts/stm32f769-disco.dtb] Error 1
dts/Makefile:46: recipe for target 'arch-dtbs' failed
make[1]: *** [arch-dtbs] Error 2
Makefile:880: recipe for target 'dts/dt.dtb' failed
make: *** [dts/dt.dtb] Error 2

There seems to be a dependency on patch for 
include/dt-bindings/mfd/stm32f7-rcc.h
adding some new macros. Is it also submitted to the list?

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


Re: [U-Boot] [PATCH v2 0/9] splash screen on the stm32f746 disco board

2018-03-05 Thread Anatolij Gustschin
On Fri, 2 Mar 2018 15:59:20 +0100
yannick fertre yannick.fer...@st.com wrote:

> Version 2:
> - Add patch to display bitmap stmicroelectronics_uboot_logo_8bit_rle
> - Add patch to defconfig to add splash screen
> - Rename panel in dts.
> 
> Version 1:
> - Initial commit
> 
> This serie contains all patchsets needed for displaying a splash screen 
> on the stm32f746 disco board & some display features (reset, blending & line
> interrupt position).
> 
> Philippe CORNU (1):
>   arm: dts: stm32: add ltdc for STM32F746
> 
> yannick fertre (8):
>   video: stm32: stm32_ltdc: add reset
>   video: stm32: stm32_ltdc: update file header & footer
>   video: stm32: stm32_ltdc: set rate of the pixel clock
>   video: stm32: stm32_ltdc: missing set of line interrupt position
>   video: stm32: stm32_ltdc: set the blending factor
>   arm: dts: stm32: add display for STM32F746 disco board
>   stm32f7: board: add splash screen
>   board: Add display to STM32F746 SoC discovery board

Series applied to u-boot-video/next, thanks!

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


Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

2018-03-05 Thread Jon Cormier
Because someone was wondering what the usb speed was in linux.  My
kernel is based on 3.2. Note I have USB DMA disabled so that doesn't
help the speed.  Not sure if u-boot is using DMA but I'd guess not.

ADB over usb
$ time adb -s 16019491 push userdata.img /mnt/obb/
userdata.img: 1 file pushed. 3.5 MB/s (45007716 bytes in 12.391s)

ADB over rndis
 $ time adb -s 192.168.2.1 push userdata.img /mnt/obb/
userdata.img: 1 file pushed. 2.9 MB/s (45007716 bytes in 14.900s)

Netcat over rndis
1|root@android:/ # time busybox nc 192.168.2.2 12345 > /mnt/obb/userdata.img
0m11.12s real 0m0.11s user 0m8.30s system
~3.9MB/s

On Mon, Mar 5, 2018 at 3:45 PM, Ruslan Bilovol  wrote:
> On Mon, Mar 5, 2018 at 6:00 PM, Jonathan Cormer
>  wrote:
>> On Sat, 2018-03-03 at 12:00 +, u-boot-requ...@lists.denx.de wrote:
>>>
>>> On 1 March 2018 at 16:33, Tom Rini  wrote:
>>> >
>>> > On Thu, Mar 01, 2018 at 04:10:44PM +0200, Ruslan Bilovol wrote:
>>> > >
>>> > > Hi Lukasz,
>>> > >
>>> > > On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski 
>>> > > wrote:
>>> > > >
>>> > > > Hi Ruslan,
>>> > > >
>>> > > > >
>>> > > > > Remove busy looping during watchdog reset.
>>> > > > > Each polling of W_PEND_WTGR bit ("finish posted
>>> > > > > write") after watchdog reset takes 120-140us
>>> > > > > on BeagleBone Black board. Current U-Boot code
>>> > > > > has watchdog resets in random places and often
>>> > > > > there is situation when watchdog is reset
>>> > > > > few times in a row in nested functions.
>>> > > > > This adds extra delays and slows the whole system.
>>> > > > >
>>> > > > > Instead of polling W_PEND_WTGR bit, we skip
>>> > > > > watchdog reset if the bit is set. Anyway, watchdog
>>> > > > > is in the middle of reset *right now*, so we can
>>> > > > > just return.
>>> > > > It seems like similar problem may be in the Linux kernel
>>> > > > driver:
>>> > > > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74
>>> > > >
>>> > > > Linux driver also waits for the write.
>>> > > Right, Linux driver has similar code but it doesn't affect
>>> > > performance.
>>> > > This is because of watchdog usage in Linux, it is enabled and
>>> > > reset by userspace. This is quite rare event.
>>> > > Moreover, since Linux has interrupts enabled and has scheduling,
>>> > > such busy loops in the omap driver are not very different to
>>> > > just mdelay() usage. The system can handle interrupts, and can
>>> > > even do preemption if PREEMPT is enabled.
>>> > > So use of such busy loops in that particular case shouldn't cause
>>> > > any noticeable performance issues.
>>> > True.  But, can you also submit a patch to the kernel side (and CC
>>> > me) ?
>>> > That's far more likely to get the attention of the engineers that
>>> > might
>>> > know of corner cases with the various SoC families where we might
>>> > need
>>> > to keep doing what we're doing or other possible problems.  Thanks!
>>> >
>>> Some additional input from my side.
>>>
>>> My previous measurements were wrong, due to usage of slow USB hub
>>> port
>>> on my laptop. Using another USB port I have next transfer speed for
>>> "fastboot flash" operation:
>>>  - without patch: 2.84 MiB/sec
>>>  - with patch: 7.81  MiB/sec
>>>
>>> So it gives us about 2.75 times improvement, as stated by Ruslan in
>>> his commit message. Also, I tested that WDT continues to work
>>> correctly, and it does (tried several use-cases, and also debug patch
>>> with infinite loop). So again:
>>>
>>> Tested-by: Sam Protsenko 
>>>
>>> Also:
>>>
>>> Reviewed-by: Sam Protsenko 
>>>
>>> I checked the code and I can say that there shouldn't be any concerns
>>> about WDT functionality with this patch. By the way, in my opinion,
>>> for kernel this patch doesn't make much sense, and there might be
>>> even
>>> confusion in case we send it... If there any concerns about it, we
>>> can
>>> invite related engineers in this discussion, asking them to review
>>> this.
>>>
>>> Overall, I think this patch is "must have" in U-Boot, as it gives us
>>> dramatic improvement without any drawbacks, especially for AM335x
>>> boards. It's probably the best approach for WDT reset procedure until
>>> interrupts are enabled for ARM architecture (if we even consider it).
>> Tested patch with AM335x on custom u-boot-2013.10 based branch. Patch
>> cleanly applied, obviously not much in this wdt driver has changed
>> since then.
>>
>> Fastboot flash
>> Before patch: 2.89MiB/s
>> After patch: 8.68MiB/s
>
> Cool, that's even a little bit better than I've got on my setup!
> Thanks for testing.
>
> Regards,
> Ruslan



-- 
Jonathan Cormier
Software Engineer

Voice:  315.425.4045 x222


http://www.CriticalLink.com
6712 Brooklawn Parkway, Syracuse, NY 13211
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] U-Boot

2018-03-05 Thread Mariano Coromac
I changed fdt_high but got the same result.
I wrote my device tree, added it into the makefile and copy the
sama5d2.config with my board name. I also got rid of all the unnecessary
stuff.
I'm now using the correct .dtb file (in arch/arm/boot/dts/)
My device tree stdout-path does point into my flexcom1 serial port.
Do you see something wrong?
flx1: flexcom@f8038000 {
atmel,flexcom-mode = ;
status = "okay";

uart5: serial@200 {
compatible = "atmel,at91sam9260-usart";
reg = <0x200 0x200>;
interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <_clk>;
pinctrl-names = "default";
pinctrl-0 = <_flx0_default>;
atmel,fifo-size = <16>;
status = "okay";
};
};
Here's a new log if it is of any use:
AT91Bootstrap 3.8.9-00026-gd7a52fb-dirty (mié feb 21 10:03:49 CST 2018)

SD/MMC: Image: Read file u-boot.bin to 0x26f0
MMC: Specification Version 1.2
SD/MMC: Done to load image
 MMC:   sdio-host@a000: 0

** Unable to use mmc 0:1 for loading the env **
Using default environment

In:serial@f8038200
Out:   serial@f8038200
Err:   serial@f8038200
stdin
stdout
stderr
Hit any key to stop autoboot:  0
reading p_a5_tab_reva.dtb
26135 bytes read in 18 ms (1.4 MiB/s)
reading zImage
2452336 bytes read in 198 ms (11.8 MiB/s)
## Current stack ends at 0x27b84588 *  kernel: cmdline image address =
0x2200
## Flattened Device Tree blob at 2100
   Booting using the fdt blob at 0x2100
using: FDT
   Loading Device Tree to 27b79000, end 27b82616 ... OK
## Transferring control to Linux (at address 2200)...

Starting kernel ...

As my understanding goes those are the only things I need, my device tree
and the linux image. I think my main problem is that I don't have the
console in my serial port, that's why it appears like it hangs but I'm not
so sure about that.
I also defined the following inside my config file:
CONFIG_DEBUG_UART_PHYS=0xf8038200
CONFIG_DEBUG_UART_VIRT=0xf7038200

Any help would be appreciated.


On Fri, Mar 2, 2018 at 11:58 AM, Nicolas Ferre 
wrote:

> On 01/03/2018 at 20:55, Mariano Coromac wrote:
>
>> I found the problem. In my header file I was reading from eMMC device 1.
>> Not 0. That's why the operations with mmc worked in command line but did
>> not on startup.
>> Please correct me if I'm mistaken but I have a couple questions.
>> 1) Do I need a partition in my eMMC in order to boot the Linux kernel?
>> When I run "mmc part" it shows no partition at all.
>> 2) When U-Boot finishes compiling it generates a .dtb with the name of my
>> custom board. I need to write this file (alongside zImage) inside my eMMC
>> for my Linux Kernel to boot right?
>>
>
> Actually no: the .dtb from U-Boot is for U-Boot to use. For loading the
> Linux kernel, you must use the .dtb that is produced by the compilation of
> the kernel (in arch/arm/boot/dts/)
>
>
>
> When I try to boot the kernel it hangs in here:
>> => boot
>> reading p_a5_tab_reva.dtb
>> 13699 bytes read in 18 ms (743.2 KiB/s)
>> reading zImage
>> 3749624 bytes read in 298 ms (12 MiB/s)
>> ## Flattened Device Tree blob at 2100
>> Booting using the fdt blob at 0x2100
>> Loading Device Tree to 27b7d000, end 27b83582 ... OK
>>
>> Starting kernel ...
>>
>> What do you think of this? Perhaps is regarding the kernel itself or
>> maybe is a UBoot configuration?
>>
>
>
> --
> Nicolas Ferre
>



-- 
Mariano Coromac 
I of Electronics Engineer
mcoro...@stsa.info
+502 41544712
www.gps.gt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] ARM: qemu-arm: Increase CONFIG_SYS_CBSIZE

2018-03-05 Thread Tuomas Tynkkynen
CONFIG_SYS_CBSIZE determines the maximum length of the kernel command
line, and the default value of 256 is too small for booting some Linux
images in the wild.

Signed-off-by: Tuomas Tynkkynen 
--
Hoping to get this in 2018.03.
---
 include/configs/qemu-arm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index c968aa76ac..839bc10a18 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -47,4 +47,6 @@
"ramdisk_addr_r=0x4400\0" \
BOOTENV
 
+#define CONFIG_SYS_CBSIZE 512
+
 #endif /* __CONFIG_H */
-- 
2.16.1

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


[U-Boot] Default CONFIG_SYS_CBSIZE too low

2018-03-05 Thread Tuomas Tynkkynen
Hi,

I was playing around with qemu_arm and qemu_arm64 and noticed some images
using the distro bootcmd infrastructure failed to boot there due to the buffer
for kernel command line arguments (which is determined by CONFIG_SYS_CBSIZE)
was too small. I found this odd given the images worked on some other boards
but turns out all of them bump it up from the default of 256:

include/configs/tegra-common.h:#define CONFIG_SYS_CBSIZE(1024 * 
2) /* Console I/O Buffer Size */
include/configs/sunxi-common.h:#define CONFIG_SYS_CBSIZE1024/* 
Console I/O Buffer Size */
include/configs/mx6_common.h:#define CONFIG_SYS_CBSIZE  512
include/configs/rpi.h:#define CONFIG_SYS_CBSIZE 1024

For 2018.03 I'll send a patch to increase it for qemu-arm too but I think
for the next release we should increase default (in config_fallbacks.h) so
that the user experience is consistent on all boards. But, I wonder how
safe it is to increase it for these boards low on RAM and stack? 
Should it perhaps be increased only for boards with CONFIG_DISTRO_DEFAULTS
that are expected to have enough resources for everything and the kitchen
sink? Or decoupling the kernel command line length from CONFIG_SYS_CBSIZE
and using malloc()? Other ideas?

Thanks,
- Tuomas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] Cleanup Whitelist entries

2018-03-05 Thread Adam Ford
There are several items in the whitelist which don't appear to be
used anywhere outside of the whitelist itself.  These include:

CONFIG_IMX_NAND
CONFIG_MXS_AUART
CONFIG_MXS_AUART_BASE
CONFIG_NORFLASH_PS32BIT
CONFIG_QSPI
CONFIG_REV3
CONFIG_SIMU
CONFIG_STV0991
CONFIG_SYS_MEMORY_TOP
CONFIG_SYS_SERIAL_BOOT
CONFIG_SYS_TEXT_ADDR
CONFIG_SYS_USBCTRL
CONFIG_SYS_VIDEO

Signed-off-by: Adam Ford 

diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 295681c..6f9baea 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1002,7 +1002,6 @@ CONFIG_IMAGE_FORMAT_LEGACY
 CONFIG_IMX
 CONFIG_IMX6_PWM_PER_CLK
 CONFIG_IMX_HDMI
-CONFIG_IMX_NAND
 CONFIG_IMX_OTP
 CONFIG_IMX_VIDEO_SKIP
 CONFIG_IMX_WATCHDOG
@@ -1403,8 +1402,6 @@ CONFIG_MXC_USB_FLAGS
 CONFIG_MXC_USB_PORT
 CONFIG_MXC_USB_PORTSC
 CONFIG_MXS
-CONFIG_MXS_AUART
-CONFIG_MXS_AUART_BASE
 CONFIG_MXS_GPIO
 CONFIG_MXS_OCOTP
 CONFIG_MX_CYCLIC
@@ -1459,7 +1456,6 @@ CONFIG_NFS_TIMEOUT
 CONFIG_NOBQFMAN
 CONFIG_NON_SECURE
 CONFIG_NORBOOT
-CONFIG_NORFLASH_PS32BIT
 CONFIG_NO_ETH
 CONFIG_NO_RELOCATION
 CONFIG_NO_WAIT
@@ -1670,7 +1666,6 @@ CONFIG_QBMAN_CLK_DIV
 CONFIG_QE
 CONFIG_QEMU_MIPS
 CONFIG_QIXIS_I2C_ACCESS
-CONFIG_QSPI
 CONFIG_QSPI_QUAD_SUPPORT
 CONFIG_QSPI_SEL_GPIO
 CONFIG_QUOTA
@@ -1716,7 +1711,6 @@ CONFIG_RESET_VECTOR_ADDRESS
 CONFIG_RESTORE_FLASH
 CONFIG_RES_BLOCK_SIZE
 CONFIG_REV1
-CONFIG_REV3
 CONFIG_REVISION_TAG
 CONFIG_RFSPART
 CONFIG_RIO
@@ -1870,7 +1864,6 @@ CONFIG_SIEMENS_DRACO
 CONFIG_SIEMENS_MACH_TYPE
 CONFIG_SIEMENS_PXM2
 CONFIG_SIEMENS_RUT
-CONFIG_SIMU
 CONFIG_SKIP_LOCAL_MAC_RANDOMIZATION
 CONFIG_SKIP_LOWLEVEL_INIT
 CONFIG_SKIP_LOWLEVEL_INIT_ONLY
@@ -2083,7 +2076,6 @@ CONFIG_STRIDER_CPU
 CONFIG_STRIDER_CPU_DP
 CONFIG_STRIDER_FANS
 CONFIG_STUART
-CONFIG_STV0991
 CONFIG_STV0991_HZ
 CONFIG_STV0991_HZ_CLOCK
 CONFIG_ST_SMI
@@ -3535,7 +3527,6 @@ CONFIG_SYS_MECR_VAL
 CONFIG_SYS_MEMAC_LITTLE_ENDIAN
 CONFIG_SYS_MEMORY_BASE
 CONFIG_SYS_MEMORY_SIZE
-CONFIG_SYS_MEMORY_TOP
 CONFIG_SYS_MEMTEST_END
 CONFIG_SYS_MEMTEST_SCRATCH
 CONFIG_SYS_MEMTEST_START
@@ -4314,7 +4305,6 @@ CONFIG_SYS_SDRC_TR_VAL2
 CONFIG_SYS_SD_VOLTAGE
 CONFIG_SYS_SEC_MON_ADDR
 CONFIG_SYS_SEC_MON_OFFSET
-CONFIG_SYS_SERIAL_BOOT
 CONFIG_SYS_SFP_ADDR
 CONFIG_SYS_SFP_OFFSET
 CONFIG_SYS_SGMII1_PHY_ADDR
@@ -4403,7 +4393,6 @@ CONFIG_SYS_SUPPORT_64BIT_DATA
 CONFIG_SYS_SXCNFG_VAL
 CONFIG_SYS_TBIPA_VALUE
 CONFIG_SYS_TCLK
-CONFIG_SYS_TEXT_ADDR
 CONFIG_SYS_TEXT_BASE_NOR
 CONFIG_SYS_TEXT_BASE_SPL
 CONFIG_SYS_TIMERBASE
@@ -4496,7 +4485,6 @@ CONFIG_SYS_ULB_CLK
 CONFIG_SYS_UNIFY_CACHE
 CONFIG_SYS_UNSPEC_PHYID
 CONFIG_SYS_UNSPEC_STRID
-CONFIG_SYS_USBCTRL
 CONFIG_SYS_USBD_BASE
 CONFIG_SYS_USB_EHCI_CPU_INIT
 CONFIG_SYS_USB_EHCI_REGS_BASE
@@ -4545,7 +4533,6 @@ CONFIG_SYS_VCXK_RESET_DDR
 CONFIG_SYS_VCXK_RESET_PIN
 CONFIG_SYS_VCXK_RESET_PORT
 CONFIG_SYS_VGA_RAM_EN
-CONFIG_SYS_VIDEO
 CONFIG_SYS_VIDEO_LOGO_MAX_SIZE
 CONFIG_SYS_VSC7385_BASE
 CONFIG_SYS_VSC7385_BASE_PHYS
-- 
2.7.4

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


Re: [U-Boot] [PATCH v3 13/13] configs: ls1012a: add pfe configuration for LS1012A

2018-03-05 Thread Joe Hershberger
On Sat, Mar 3, 2018 at 11:43 AM, Calvin Johnson  wrote:
> Add configurations for PFE.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 10/13] armv8: fsl-lsch2: add pfe macros and update ccsr_scfg structure

2018-03-05 Thread Joe Hershberger
On Sat, Mar 3, 2018 at 11:43 AM, Calvin Johnson  wrote:
> SoC specific PFE macros are defined and structure ccsr_scfg
> is updated with members defined for PFE.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 09/13] board: freescale: ls1012a2g5rdb: enable network support on ls1012a2g5rdb

2018-03-05 Thread Joe Hershberger
On Sat, Mar 3, 2018 at 11:43 AM, Calvin Johnson  wrote:
> This patch enables ethernet support for ls1012a2g5rdb.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Bhaskar Upadhaya 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

2018-03-05 Thread Ruslan Bilovol
On Mon, Mar 5, 2018 at 6:00 PM, Jonathan Cormer
 wrote:
> On Sat, 2018-03-03 at 12:00 +, u-boot-requ...@lists.denx.de wrote:
>>
>> On 1 March 2018 at 16:33, Tom Rini  wrote:
>> >
>> > On Thu, Mar 01, 2018 at 04:10:44PM +0200, Ruslan Bilovol wrote:
>> > >
>> > > Hi Lukasz,
>> > >
>> > > On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski 
>> > > wrote:
>> > > >
>> > > > Hi Ruslan,
>> > > >
>> > > > >
>> > > > > Remove busy looping during watchdog reset.
>> > > > > Each polling of W_PEND_WTGR bit ("finish posted
>> > > > > write") after watchdog reset takes 120-140us
>> > > > > on BeagleBone Black board. Current U-Boot code
>> > > > > has watchdog resets in random places and often
>> > > > > there is situation when watchdog is reset
>> > > > > few times in a row in nested functions.
>> > > > > This adds extra delays and slows the whole system.
>> > > > >
>> > > > > Instead of polling W_PEND_WTGR bit, we skip
>> > > > > watchdog reset if the bit is set. Anyway, watchdog
>> > > > > is in the middle of reset *right now*, so we can
>> > > > > just return.
>> > > > It seems like similar problem may be in the Linux kernel
>> > > > driver:
>> > > > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74
>> > > >
>> > > > Linux driver also waits for the write.
>> > > Right, Linux driver has similar code but it doesn't affect
>> > > performance.
>> > > This is because of watchdog usage in Linux, it is enabled and
>> > > reset by userspace. This is quite rare event.
>> > > Moreover, since Linux has interrupts enabled and has scheduling,
>> > > such busy loops in the omap driver are not very different to
>> > > just mdelay() usage. The system can handle interrupts, and can
>> > > even do preemption if PREEMPT is enabled.
>> > > So use of such busy loops in that particular case shouldn't cause
>> > > any noticeable performance issues.
>> > True.  But, can you also submit a patch to the kernel side (and CC
>> > me) ?
>> > That's far more likely to get the attention of the engineers that
>> > might
>> > know of corner cases with the various SoC families where we might
>> > need
>> > to keep doing what we're doing or other possible problems.  Thanks!
>> >
>> Some additional input from my side.
>>
>> My previous measurements were wrong, due to usage of slow USB hub
>> port
>> on my laptop. Using another USB port I have next transfer speed for
>> "fastboot flash" operation:
>>  - without patch: 2.84 MiB/sec
>>  - with patch: 7.81  MiB/sec
>>
>> So it gives us about 2.75 times improvement, as stated by Ruslan in
>> his commit message. Also, I tested that WDT continues to work
>> correctly, and it does (tried several use-cases, and also debug patch
>> with infinite loop). So again:
>>
>> Tested-by: Sam Protsenko 
>>
>> Also:
>>
>> Reviewed-by: Sam Protsenko 
>>
>> I checked the code and I can say that there shouldn't be any concerns
>> about WDT functionality with this patch. By the way, in my opinion,
>> for kernel this patch doesn't make much sense, and there might be
>> even
>> confusion in case we send it... If there any concerns about it, we
>> can
>> invite related engineers in this discussion, asking them to review
>> this.
>>
>> Overall, I think this patch is "must have" in U-Boot, as it gives us
>> dramatic improvement without any drawbacks, especially for AM335x
>> boards. It's probably the best approach for WDT reset procedure until
>> interrupts are enabled for ARM architecture (if we even consider it).
> Tested patch with AM335x on custom u-boot-2013.10 based branch. Patch
> cleanly applied, obviously not much in this wdt driver has changed
> since then.
>
> Fastboot flash
> Before patch: 2.89MiB/s
> After patch: 8.68MiB/s

Cool, that's even a little bit better than I've got on my setup!
Thanks for testing.

Regards,
Ruslan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 06/13] board: freescale: ls1012aqds: enable network support on ls1012aqds

2018-03-05 Thread Joe Hershberger
On Sat, Mar 3, 2018 at 11:43 AM, Calvin Johnson  wrote:
> This patch enables ethernet support for ls1012aqds.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 05/13] drivers: net: pfe_eth: LS1012A PFE headers

2018-03-05 Thread Joe Hershberger
On Sat, Mar 3, 2018 at 11:43 AM, Calvin Johnson  wrote:
> Contains all the pfe header files.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 
>
> ---
>
> Changes in v3:
> -Move pfe_eth header files to include/net/pfe_eth
> -Use BIT macro wherever applicable
>
> Changes in v2:
> -Add pfe_rx_done to clear bd after packet processing
> -remove unused code under CONFIG_UTIL_PE_DISABLED
> -Used BIT and GENMASK macros wherever applicable
> -Removed generic definitions that pollutes namespace
> -File names pfe.h renamed to pfe_hw.h to be more clear as it contains
>  low level functions that directly access pfe hardware block
> -Added pfe_dm_eth.h for new driver model
>
>  include/dm/platform_data/pfe_dm_eth.h|  21 
>  include/net/pfe_eth/pfe/cbus.h   |  77 +
>  include/net/pfe_eth/pfe/cbus/bmu.h   |  40 +++
>  include/net/pfe_eth/pfe/cbus/class_csr.h | 180 
> +++
>  include/net/pfe_eth/pfe/cbus/emac.h  | 140 
>  include/net/pfe_eth/pfe/cbus/gpi.h   |  62 +++
>  include/net/pfe_eth/pfe/cbus/hif.h   |  68 
>  include/net/pfe_eth/pfe/cbus/hif_nocpy.h |  40 +++
>  include/net/pfe_eth/pfe/cbus/tmu_csr.h   | 148 +
>  include/net/pfe_eth/pfe/cbus/util_csr.h  |  47 
>  include/net/pfe_eth/pfe/pfe_hw.h | 163 
>  include/net/pfe_eth/pfe_driver.h |  59 ++
>  include/net/pfe_eth/pfe_eth.h| 104 ++
>  include/net/pfe_eth/pfe_firmware.h   |  17 +++
>  include/net/pfe_eth/pfe_mdio.h   |  13 +++

I assume that since you kept all the duplicated "pfe" in the path to
the files that it is valuable to do it... so:

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Whitelist scripting

2018-03-05 Thread Adam Ford
I went through my boards to look for junk #defines in the header that
do nothing and/or are dead.
I then created a pretty poor script that runs through and scans the
whitelist and greps the code searching for C code that uses the
defines.

I started isolating sections and found that in some places we have C
code that does the check for a #define, but it never gets defined
anywhere, and in other places, we have #defines that aren't used.

What I was hoping to do was help clean the whitelist table by first
searching for #defines that are never used anywhere and/or are dead.I
will be the first person to admit that I am not very good with shell
scripts, so I thought I'd solicit a favor.

Does someone have any cool scripts that we can use the scan through
the and look for #defines that have no #ifdef, Makefile dependancy, or
linker script attachment?  These seem like they'd be obvious chunks of
code to eliminate.

Conversely, does anyone have any cool scripts that we can scan through
the code and look for #ifdefs that are never defined?  Those seem like
other low-hanging fruit but possible still useful.

As people are going through and using moveconfig to migrate to Kconfig
it seems like there might be a lot of work saved by eliminating a junk
from the whitelist.

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


[U-Boot] [PATCH v5 11/15] bmips: bcm6348: add support for bcm6348-enet

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6348.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6348.dtsi b/arch/mips/dts/brcm,bcm6348.dtsi
index d774c59665..e540865019 100644
--- a/arch/mips/dts/brcm,bcm6348.dtsi
+++ b/arch/mips/dts/brcm,bcm6348.dtsi
@@ -162,6 +162,32 @@
u-boot,dm-pre-reloc;
};
 
+   enet0: ethernet@fffe6000 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe6000 0x2dc>;
+   dmas = < BCM6348_DMA_ENET0_RX>,
+  < BCM6348_DMA_ENET0_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
+   enet1: ethernet@fffe6800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe6800 0x2dc>;
+   dmas = < BCM6348_DMA_ENET1_RX>,
+  < BCM6348_DMA_ENET1_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
iudma: dma-controller@fffe7000 {
compatible = "brcm,bcm6348-iudma";
reg = <0xfffe7000 0x1c>,
-- 
2.11.0

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


Re: [U-Boot] [RFC v3 01/15] dma: move dma_ops to dma-uclass.h

2018-03-05 Thread Álvaro Fernández Rojas

Hi Grygorii,

Thanks for reporting that, it should be fixed on v5.

Regards,

Álvaro.


El 05/03/2018 a las 20:35, Grygorii Strashko escribió:


On 02/22/2018 10:18 AM, Simon Glass wrote:

On 21 February 2018 at 09:10, Álvaro Fernández Rojas  wrote:

Move dma_ops to a separate header file, following other uclass implementations.
While doing so, this patch also improves dma_ops documentation.

Signed-off-by: Álvaro Fernández Rojas 
---
   v3: Introduce changes reported by Simon Glass:
- Improve dma-uclass.h documentation.
- Switch to live tree API.

   drivers/dma/dma-uclass.c |  3 ++-
   include/dma-uclass.h | 39 +++
   include/dma.h| 22 --
   3 files changed, 41 insertions(+), 23 deletions(-)
   create mode 100644 include/dma-uclass.h

Reviewed-by: Simon Glass 

this patch will break build of existing DMA drivers, as
the do not have #include .

drivers/dma/ti-edma3.c:563:21: error: variable 'ti_edma3_ops' has initializer 
but incomplete type
  static const struct dma_ops ti_edma3_ops = {
  ^~~
drivers/dma/ti-edma3.c:564:2: error: unknown field 'transfer' specified in 
initializer
   .transfer = ti_edma3_transfer,
   ^
drivers/dma/ti-edma3.c:564:14: warning: excess elements in struct initializer
   .transfer = ti_edma3_transfer,
   ^
drivers/dma/ti-edma3.c:564:14: note: (near initialization for 'ti_edma3_ops')
drivers/dma/ti-edma3.c:563:29: error: storage size of 'ti_edma3_ops' isn't known
  static const struct dma_ops ti_edma3_ops = {
  ^~~~
make[1]: *** [drivers/dma/ti-edma3.o] Error 1




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


[U-Boot] [PATCH v5 12/15] bmips: enable ct-5361 enet support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/comtrend,ct-5361.dts| 12 
 configs/comtrend_ct5361_ram_defconfig |  8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/comtrend,ct-5361.dts 
b/arch/mips/dts/comtrend,ct-5361.dts
index 74dc09046c..a78aa877fc 100644
--- a/arch/mips/dts/comtrend,ct-5361.dts
+++ b/arch/mips/dts/comtrend,ct-5361.dts
@@ -35,6 +35,18 @@
};
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/comtrend_ct5361_ram_defconfig 
b/configs/comtrend_ct5361_ram_defconfig
index 8b842606f5..0737772dd2 100644
--- a/configs/comtrend_ct5361_ram_defconfig
+++ b/configs/comtrend_ct5361_ram_defconfig
@@ -26,11 +26,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -38,6 +41,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6348_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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


[U-Boot] [PATCH v5 10/15] bmips: enable f@st1704 enet support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/sagem,f...@st1704.dts | 12 
 configs/sagem_f@st1704_ram_defconfig |  9 -
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/sagem,f...@st1704.dts 
b/arch/mips/dts/sagem,f...@st1704.dts
index dd0e5b8b7c..99d031f10a 100644
--- a/arch/mips/dts/sagem,f...@st1704.dts
+++ b/arch/mips/dts/sagem,f...@st1704.dts
@@ -40,6 +40,18 @@
};
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enetphy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/sagem_f@st1704_ram_defconfig 
b/configs/sagem_f@st1704_ram_defconfig
index 0adcd46d51..1a640781b7 100644
--- a/configs/sagem_f@st1704_ram_defconfig
+++ b/configs/sagem_f@st1704_ram_defconfig
@@ -28,11 +28,15 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
-# CONFIG_CMD_NET is not set
+CONFIG_CMD_DHCP=y
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -41,6 +45,9 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_MTD=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_BCM6345=y
 # CONFIG_SPL_SERIAL_PRESENT is not set
-- 
2.11.0

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


[U-Boot] [PATCH v5 14/15] bmips: enable hg556a enet support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/huawei,hg556a.dts | 12 
 configs/huawei_hg556a_ram_defconfig |  8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/huawei,hg556a.dts b/arch/mips/dts/huawei,hg556a.dts
index a1e9c15ab9..2f99e0905c 100644
--- a/arch/mips/dts/huawei,hg556a.dts
+++ b/arch/mips/dts/huawei,hg556a.dts
@@ -94,6 +94,18 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/huawei_hg556a_ram_defconfig 
b/configs/huawei_hg556a_ram_defconfig
index 7f7f34ed61..c7c7c6554f 100644
--- a/configs/huawei_hg556a_ram_defconfig
+++ b/configs/huawei_hg556a_ram_defconfig
@@ -26,11 +26,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -38,6 +41,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6358_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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


[U-Boot] [PATCH v5 13/15] bmips: bcm6358: add support for bcm6348-enet

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6358.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6358.dtsi b/arch/mips/dts/brcm,bcm6358.dtsi
index 1468e4f63a..04329864c2 100644
--- a/arch/mips/dts/brcm,bcm6358.dtsi
+++ b/arch/mips/dts/brcm,bcm6358.dtsi
@@ -193,6 +193,34 @@
status = "disabled";
};
 
+   enet0: ethernet@fffe4000 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe4000 0x2dc>;
+   clocks = <_clk BCM6358_CLK_ENET0>;
+   dmas = < BCM6358_DMA_ENET0_RX>,
+  < BCM6358_DMA_ENET0_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
+   enet1: ethernet@fffe4800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe4800 0x2dc>;
+   clocks = <_clk BCM6358_CLK_ENET1>;
+   dmas = < BCM6358_DMA_ENET1_RX>,
+  < BCM6358_DMA_ENET1_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
iudma: dma-controller@fffe5000 {
compatible = "brcm,bcm6348-iudma";
reg = <0xfffe5000 0x24>,
-- 
2.11.0

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


[U-Boot] [PATCH v5 09/15] bmips: bcm6338: add support for bcm6348-enet

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6338.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6338.dtsi b/arch/mips/dts/brcm,bcm6338.dtsi
index 4125f71d9f..621278c9d1 100644
--- a/arch/mips/dts/brcm,bcm6338.dtsi
+++ b/arch/mips/dts/brcm,bcm6338.dtsi
@@ -145,5 +145,20 @@
dma-channels = <6>;
resets = <_rst BCM6338_RST_DMAMEM>;
};
+
+   enet: ethernet@fffe2800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe2800 0x2dc>;
+   clocks = <_clk BCM6338_CLK_ENET>;
+   resets = <_rst BCM6338_RST_ENET>;
+   dmas = < BCM6338_DMA_ENET_RX>,
+  < BCM6338_DMA_ENET_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
};
 };
-- 
2.11.0

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


[U-Boot] [PATCH v5 05/15] bmips: bcm6348: add bcm6348-iudma support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6348.dtsi   | 16 
 include/dt-bindings/dma/bcm6348-dma.h | 17 +
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6348-dma.h

diff --git a/arch/mips/dts/brcm,bcm6348.dtsi b/arch/mips/dts/brcm,bcm6348.dtsi
index 92fb91afc1..d774c59665 100644
--- a/arch/mips/dts/brcm,bcm6348.dtsi
+++ b/arch/mips/dts/brcm,bcm6348.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -160,5 +161,20 @@
reg = <0xfffe2300 0x38>;
u-boot,dm-pre-reloc;
};
+
+   iudma: dma-controller@fffe7000 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe7000 0x1c>,
+ <0xfffe7100 0x40>,
+ <0xfffe7200 0x40>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <4>;
+   clocks = <_clk BCM6348_CLK_ENET>;
+   resets = <_rst BCM6348_RST_ENET>,
+<_rst BCM6348_RST_DMAMEM>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6348-dma.h 
b/include/dt-bindings/dma/bcm6348-dma.h
new file mode 100644
index 00..a1d3a6456d
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6348-dma.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6348_H
+#define __DT_BINDINGS_DMA_BCM6348_H
+
+#define BCM6348_DMA_ENET0_RX   0
+#define BCM6348_DMA_ENET0_TX   1
+#define BCM6348_DMA_ENET1_RX   2
+#define BCM6348_DMA_ENET1_TX   3
+
+#endif /* __DT_BINDINGS_DMA_BCM6348_H */
-- 
2.11.0

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


[U-Boot] [PATCH v5 08/15] net: add support for bcm6348-enet

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: Receive as much packets as possible from bcm6348-eth and cache them in
 net_rx_packets. This is needed in order to fix flow control issues.
 v4: Fix issues reported by Grygorii Strashko and other fixes:
  - Copy received dma buffer to net_rx_packets in order to avoid possible
  dma overwrites.
  - Reset dma rx channel when sending a new packet to prevent flow control
  issues.
  - Fix packet casting on bcm6348_eth_recv/send.
 v3: no changes
 v2: select DMA_CHANNELS.

 drivers/net/Kconfig|  10 +
 drivers/net/Makefile   |   1 +
 drivers/net/bcm6348-eth.c  | 575 +
 include/configs/bmips_common.h |   5 +-
 4 files changed, 590 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/bcm6348-eth.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index de1947ccc1..e532332d78 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -71,6 +71,16 @@ config BCM_SF2_ETH_GMAC
  by the BCM_SF2_ETH driver.
  Say Y to any bcmcygnus based platforms.
 
+config BCM6348_ETH
+   bool "BCM6348 EMAC support"
+   depends on DM_ETH && ARCH_BMIPS
+   select DMA
+   select DMA_CHANNELS
+   select MII
+   select PHYLIB
+   help
+ This driver supports the BCM6348 Ethernet MAC.
+
 config DWC_ETH_QOS
bool "Synopsys DWC Ethernet QOS device support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ac5443c752..282adbc775 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
 obj-$(CONFIG_AG7XXX) += ag7xxx.o
 obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
+obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
 obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
 obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
 obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
diff --git a/drivers/net/bcm6348-eth.c b/drivers/net/bcm6348-eth.c
new file mode 100644
index 00..43518f7b2d
--- /dev/null
+++ b/drivers/net/bcm6348-eth.c
@@ -0,0 +1,575 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c:
+ * Copyright (C) 2008 Maxime Bizon 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ETH_RX_DESCPKTBUFSRX
+#define ETH_MAX_MTU_SIZE   1518
+#define ETH_TIMEOUT100
+#define ETH_TX_WATERMARK   32
+
+/* ETH Receiver Configuration register */
+#define ETH_RXCFG_REG  0x00
+#define ETH_RXCFG_ENFLOW_SHIFT 5
+#define ETH_RXCFG_ENFLOW_MASK  (1 << ETH_RXCFG_ENFLOW_SHIFT)
+
+/* ETH Receive Maximum Length register */
+#define ETH_RXMAXLEN_REG   0x04
+#define ETH_RXMAXLEN_SHIFT 0
+#define ETH_RXMAXLEN_MASK  (0x7ff << ETH_RXMAXLEN_SHIFT)
+
+/* ETH Transmit Maximum Length register */
+#define ETH_TXMAXLEN_REG   0x08
+#define ETH_TXMAXLEN_SHIFT 0
+#define ETH_TXMAXLEN_MASK  (0x7ff << ETH_TXMAXLEN_SHIFT)
+
+/* MII Status/Control register */
+#define MII_SC_REG 0x10
+#define MII_SC_MDCFREQDIV_SHIFT0
+#define MII_SC_MDCFREQDIV_MASK (0x7f << MII_SC_MDCFREQDIV_SHIFT)
+#define MII_SC_PREAMBLE_EN_SHIFT   7
+#define MII_SC_PREAMBLE_EN_MASK(1 << MII_SC_PREAMBLE_EN_SHIFT)
+
+/* MII Data register */
+#define MII_DAT_REG0x14
+#define MII_DAT_DATA_SHIFT 0
+#define MII_DAT_DATA_MASK  (0x << MII_DAT_DATA_SHIFT)
+#define MII_DAT_TA_SHIFT   16
+#define MII_DAT_TA_MASK(0x3 << MII_DAT_TA_SHIFT)
+#define MII_DAT_REG_SHIFT  18
+#define MII_DAT_REG_MASK   (0x1f << MII_DAT_REG_SHIFT)
+#define MII_DAT_PHY_SHIFT  23
+#define MII_DAT_PHY_MASK   (0x1f << MII_DAT_PHY_SHIFT)
+#define MII_DAT_OP_SHIFT   28
+#define MII_DAT_OP_WRITE   (0x5 << MII_DAT_OP_SHIFT)
+#define MII_DAT_OP_READ(0x6 << MII_DAT_OP_SHIFT)
+
+/* ETH Interrupts Mask register */
+#define ETH_IRMASK_REG 0x18
+
+/* ETH Interrupts register */
+#define ETH_IR_REG 0x1c
+#define ETH_IR_MII_SHIFT   0
+#define ETH_IR_MII_MASK(1 << ETH_IR_MII_SHIFT)
+
+/* ETH Control register */
+#define ETH_CTL_REG0x2c
+#define ETH_CTL_ENABLE_SHIFT   0
+#define ETH_CTL_ENABLE_MASK(1 << ETH_CTL_ENABLE_SHIFT)
+#define ETH_CTL_DISABLE_SHIFT  1
+#define ETH_CTL_DISABLE_MASK   (1 << ETH_CTL_DISABLE_SHIFT)
+#define ETH_CTL_RESET_SHIFT2
+#define ETH_CTL_RESET_MASK (1 << ETH_CTL_RESET_SHIFT)
+#define 

[U-Boot] [PATCH v5 15/15] bmips: enable nb4-ser enet support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/sfr,nb4-ser.dts | 24 
 configs/sfr_nb4-ser_ram_defconfig |  8 +++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/sfr,nb4-ser.dts b/arch/mips/dts/sfr,nb4-ser.dts
index 473372faa1..73db45f9ea 100644
--- a/arch/mips/dts/sfr,nb4-ser.dts
+++ b/arch/mips/dts/sfr,nb4-ser.dts
@@ -54,6 +54,30 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "internal";
+
+   enet0phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/sfr_nb4-ser_ram_defconfig 
b/configs/sfr_nb4-ser_ram_defconfig
index fc323d879d..07b49a1a77 100644
--- a/configs/sfr_nb4-ser_ram_defconfig
+++ b/configs/sfr_nb4-ser_ram_defconfig
@@ -27,11 +27,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -40,6 +43,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6358_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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


[U-Boot] [PATCH v5 03/15] dma: add bcm6348-iudma support

2018-03-05 Thread Álvaro Fernández Rojas
BCM6348 IUDMA controller is present on multiple BMIPS (BCM63xx) SoCs.

Signed-off-by: Álvaro Fernández Rojas 
---
 v5: Several fixes and improvements:
  - Remove unused defines.
  - Increment rx descriptors.
  - Fix flow control issues.
  - Error checking now depends on hw.
  - Remove unneeded interrupts.
 v4: Fix issues reported by Grygorii Strashko and other fixes:
  - Remove usage of net_rx_packets as buffer.
  - Allocate dynamic rx buffer.
  - Check dma errors and discard invalid packets.
 v3: no changes
 v2: Fix dma rx burst config and select DMA_CHANNELS.

 drivers/dma/Kconfig |   9 +
 drivers/dma/Makefile|   1 +
 drivers/dma/bcm6348-iudma.c | 532 
 3 files changed, 542 insertions(+)
 create mode 100644 drivers/dma/bcm6348-iudma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 21b2c0dcaa..9afa158b51 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -19,6 +19,15 @@ config DMA_CHANNELS
  Enable channels support for DMA. Some DMA controllers have multiple
  channels which can either transfer data to/from different devices.
 
+config BCM6348_IUDMA
+   bool "BCM6348 IUDMA driver"
+   depends on ARCH_BMIPS
+   select DMA_CHANNELS
+   help
+ Enable the BCM6348 IUDMA driver.
+ This driver support data transfer from devices to
+ memory and from memory to devices.
+
 config TI_EDMA3
bool "TI EDMA3 driver"
help
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 39b78b2a3d..b2b4147349 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DMA) += dma-uclass.o
 
 obj-$(CONFIG_FSLDMAFEC) += MCD_tasksInit.o MCD_dmaApi.o MCD_tasks.o
 obj-$(CONFIG_APBH_DMA) += apbh_dma.o
+obj-$(CONFIG_BCM6348_IUDMA) += bcm6348-iudma.o
 obj-$(CONFIG_FSL_DMA) += fsl_dma.o
 obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
diff --git a/drivers/dma/bcm6348-iudma.c b/drivers/dma/bcm6348-iudma.c
new file mode 100644
index 00..962d7ae3e5
--- /dev/null
+++ b/drivers/dma/bcm6348-iudma.c
@@ -0,0 +1,532 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/dma/bcm63xx-iudma.c:
+ * Copyright (C) 2015 Simon Arlott 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c:
+ * Copyright (C) 2008 Maxime Bizon 
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
+ * Copyright (C) 2000-2010 Broadcom Corporation
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/bcmdrivers/opensource/net/enet/impl4/bcmenet.c:
+ * Copyright (C) 2010 Broadcom Corporation
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DMA_RX_DESC6
+#define DMA_TX_DESC1
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ALIGN_END_ADDR(type, ptr, size)\
+   ((unsigned long)(ptr) + roundup((size) * sizeof(type), \
+ARCH_DMA_MINALIGN))
+
+/* DMA Channels */
+#define DMA_CHAN_FLOWC(x)  ((x) >> 1)
+#define DMA_CHAN_MAX   16
+#define DMA_CHAN_SIZE  0x10
+#define DMA_CHAN_TOUT  500
+
+/* DMA Global Configuration register */
+#define DMA_CFG_REG0x00
+#define  DMA_CFG_ENABLE_SHIFT  0
+#define  DMA_CFG_ENABLE_MASK   (1 << DMA_CFG_ENABLE_SHIFT)
+#define  DMA_CFG_FLOWC_ENABLE(x)   BIT(DMA_CHAN_FLOWC(x) + 1)
+#define  DMA_CFG_NCHANS_SHIFT  24
+#define  DMA_CFG_NCHANS_MASK   (0xf << DMA_CFG_NCHANS_SHIFT)
+
+/* DMA Global Flow Control registers */
+#define DMA_FLOWC_THR_LO_REG(x)(0x04 + DMA_CHAN_FLOWC(x) * 
0x0c)
+#define DMA_FLOWC_THR_HI_REG(x)(0x08 + DMA_CHAN_FLOWC(x) * 
0x0c)
+#define DMA_FLOWC_ALLOC_REG(x) (0x0c + DMA_CHAN_FLOWC(x) * 0x0c)
+#define  DMA_FLOWC_ALLOC_FORCE_SHIFT   31
+#define  DMA_FLOWC_ALLOC_FORCE_MASK(1 << DMA_FLOWC_ALLOC_FORCE_SHIFT)
+
+/* DMA Global Reset register */
+#define DMA_RST_REG0x34
+#define  DMA_RST_CHAN_SHIFT0
+#define  DMA_RST_CHAN_MASK(x)  (1 << x)
+
+/* DMA Channel Configuration register */
+#define DMAC_CFG_REG(x)(DMA_CHAN_SIZE * (x) + 0x00)
+#define  DMAC_CFG_ENABLE_SHIFT 0
+#define  DMAC_CFG_ENABLE_MASK  (1 << DMAC_CFG_ENABLE_SHIFT)
+#define  DMAC_CFG_PKT_HALT_SHIFT   1
+#define  DMAC_CFG_PKT_HALT_MASK(1 << DMAC_CFG_PKT_HALT_SHIFT)
+#define  DMAC_CFG_BRST_HALT_SHIFT  2
+#define  DMAC_CFG_BRST_HALT_MASK   (1 << DMAC_CFG_BRST_HALT_SHIFT)
+
+/* DMA Channel Max Burst Length register */
+#define DMAC_BURST_REG(x)  (DMA_CHAN_SIZE * (x) + 0x0c)
+
+/* DMA SRAM Descriptor Ring Start register */
+#define DMAS_RSTART_REG(x) (DMA_CHAN_SIZE 

[U-Boot] [PATCH v5 07/15] phy: add support for internal phys

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 include/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/phy.h b/include/phy.h
index 0543ec10c2..8f3e53db01 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -50,6 +50,7 @@
 
 
 typedef enum {
+   PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
@@ -72,6 +73,7 @@ typedef enum {
 } phy_interface_t;
 
 static const char *phy_interface_strings[] = {
+   [PHY_INTERFACE_MODE_INTERNAL]   = "internal",
[PHY_INTERFACE_MODE_MII]= "mii",
[PHY_INTERFACE_MODE_GMII]   = "gmii",
[PHY_INTERFACE_MODE_SGMII]  = "sgmii",
-- 
2.11.0

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


[U-Boot] [PATCH v5 06/15] bmips: bcm6358: add bcm6348-iudma support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6358.dtsi   | 18 ++
 include/dt-bindings/dma/bcm6358-dma.h | 17 +
 2 files changed, 35 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6358-dma.h

diff --git a/arch/mips/dts/brcm,bcm6358.dtsi b/arch/mips/dts/brcm,bcm6358.dtsi
index b63b53baee..1468e4f63a 100644
--- a/arch/mips/dts/brcm,bcm6358.dtsi
+++ b/arch/mips/dts/brcm,bcm6358.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -191,5 +192,22 @@
 
status = "disabled";
};
+
+   iudma: dma-controller@fffe5000 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe5000 0x24>,
+ <0xfffe5100 0x80>,
+ <0xfffe5200 0x80>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <8>;
+   clocks = <_clk BCM6358_CLK_EMUSB>,
+<_clk BCM6358_CLK_USBSU>,
+<_clk BCM6358_CLK_EPHY>;
+   resets = <_rst BCM6358_RST_ENET>,
+<_rst BCM6358_RST_EPHY>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6358-dma.h 
b/include/dt-bindings/dma/bcm6358-dma.h
new file mode 100644
index 00..3b1fcf8540
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6358-dma.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6358_H
+#define __DT_BINDINGS_DMA_BCM6358_H
+
+#define BCM6358_DMA_ENET0_RX   0
+#define BCM6358_DMA_ENET0_TX   1
+#define BCM6358_DMA_ENET1_RX   2
+#define BCM6358_DMA_ENET1_TX   3
+
+#endif /* __DT_BINDINGS_DMA_BCM6358_H */
-- 
2.11.0

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


[U-Boot] [PATCH v5 04/15] bmips: bcm6338: add bcm6348-iudma support

2018-03-05 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes
 v4: no changes
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6338.dtsi   | 14 ++
 include/dt-bindings/dma/bcm6338-dma.h | 15 +++
 2 files changed, 29 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6338-dma.h

diff --git a/arch/mips/dts/brcm,bcm6338.dtsi b/arch/mips/dts/brcm,bcm6338.dtsi
index 0cab44cb8d..4125f71d9f 100644
--- a/arch/mips/dts/brcm,bcm6338.dtsi
+++ b/arch/mips/dts/brcm,bcm6338.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -131,5 +132,18 @@
reg = <0xfffe3100 0x38>;
u-boot,dm-pre-reloc;
};
+
+   iudma: dma-controller@fffe2400 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe2400 0x1c>,
+ <0xfffe2500 0x60>,
+ <0xfffe2600 0x60>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <6>;
+   resets = <_rst BCM6338_RST_DMAMEM>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6338-dma.h 
b/include/dt-bindings/dma/bcm6338-dma.h
new file mode 100644
index 00..5dd66239b4
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6338-dma.h
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6338_H
+#define __DT_BINDINGS_DMA_BCM6338_H
+
+#define BCM6338_DMA_ENET_RX0
+#define BCM6338_DMA_ENET_TX1
+
+#endif /* __DT_BINDINGS_DMA_BCM6338_H */
-- 
2.11.0

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


[U-Boot] [PATCH v5 02/15] dma: add channels support

2018-03-05 Thread Álvaro Fernández Rojas
This adds channels support for dma controllers that have multiple channels
which can transfer data to/from different devices (enet, usb...).

Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Simon Glass 
---
 v5: remove unneeded dma.h include
 v4: no changes
 v3: Introduce changes reported by Simon Glass:
  - Improve dma-uclass.h documentation.
  - Switch to live tree API.

 drivers/dma/Kconfig  |   7 ++
 drivers/dma/dma-uclass.c | 188 +--
 include/dma-uclass.h |  78 
 include/dma.h| 174 ++-
 4 files changed, 439 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1b92c7789d..21b2c0dcaa 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -12,6 +12,13 @@ config DMA
  buses that is used to transfer data to and from memory.
  The uclass interface is defined in include/dma.h.
 
+config DMA_CHANNELS
+   bool "Enable DMA channels support"
+   depends on DMA
+   help
+ Enable channels support for DMA. Some DMA controllers have multiple
+ channels which can either transfer data to/from different devices.
+
 config TI_EDMA3
bool "TI EDMA3 driver"
help
diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index faa27a3a56..b5109aafc9 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -1,23 +1,199 @@
 /*
  * Direct Memory Access U-Class driver
  *
- * (C) Copyright 2015
- * Texas Instruments Incorporated, 
- *
- * Author: Mugunthan V N 
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ * Copyright (C) 2015 Texas Instruments Incorporated 
+ * Written by Mugunthan V N 
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
 
 #include 
 #include 
-#include 
-#include 
+#include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_DMA_CHANNELS
+static inline struct dma_ops *dma_dev_ops(struct udevice *dev)
+{
+   return (struct dma_ops *)dev->driver->ops;
+}
+
+# if CONFIG_IS_ENABLED(OF_CONTROL)
+#  if CONFIG_IS_ENABLED(OF_PLATDATA)
+int dma_get_by_index_platdata(struct udevice *dev, int index,
+ struct phandle_1_arg *cells, struct dma *dma)
+{
+   int ret;
+
+   if (index != 0)
+   return -ENOSYS;
+   ret = uclass_get_device(UCLASS_DMA, 0, >dev);
+   if (ret)
+   return ret;
+   dma->id = cells[0].id;
+
+   return 0;
+}
+#  else
+static int dma_of_xlate_default(struct dma *dma,
+   struct ofnode_phandle_args *args)
+{
+   debug("%s(dma=%p)\n", __func__, dma);
+
+   if (args->args_count > 1) {
+   pr_err("Invaild args_count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   if (args->args_count)
+   dma->id = args->args[0];
+   else
+   dma->id = 0;
+
+   return 0;
+}
+
+int dma_get_by_index(struct udevice *dev, int index, struct dma *dma)
+{
+   int ret;
+   struct ofnode_phandle_args args;
+   struct udevice *dev_dma;
+   const struct dma_ops *ops;
+
+   debug("%s(dev=%p, index=%d, dma=%p)\n", __func__, dev, index, dma);
+
+   assert(dma);
+   dma->dev = NULL;
+
+   ret = dev_read_phandle_with_args(dev, "dmas", "#dma-cells", 0, index,
+);
+   if (ret) {
+   pr_err("%s: dev_read_phandle_with_args failed: err=%d\n",
+  __func__, ret);
+   return ret;
+   }
+
+   ret = uclass_get_device_by_ofnode(UCLASS_DMA, args.node, _dma);
+   if (ret) {
+   pr_err("%s: uclass_get_device_by_ofnode failed: err=%d\n",
+  __func__, ret);
+   return ret;
+   }
+
+   dma->dev = dev_dma;
+
+   ops = dma_dev_ops(dev_dma);
+
+   if (ops->of_xlate)
+   ret = ops->of_xlate(dma, );
+   else
+   ret = dma_of_xlate_default(dma, );
+   if (ret) {
+   pr_err("of_xlate() failed: %d\n", ret);
+   return ret;
+   }
+
+   return dma_request(dev_dma, dma);
+}
+#  endif /* OF_PLATDATA */
+
+int dma_get_by_name(struct udevice *dev, const char *name, struct dma *dma)
+{
+   int index;
+
+   debug("%s(dev=%p, name=%s, dma=%p)\n", __func__, dev, name, dma);
+   dma->dev = NULL;
+
+   index = dev_read_stringlist_search(dev, "dma-names", name);
+   if (index < 0) {
+   pr_err("dev_read_stringlist_search() failed: %d\n", index);
+   return index;
+   }
+
+   return dma_get_by_index(dev, index, dma);
+}
+# endif /* OF_CONTROL */
+
+int dma_request(struct udevice *dev, struct dma *dma)
+{
+   struct dma_ops *ops = dma_dev_ops(dev);
+
+   debug("%s(dev=%p, dma=%p)\n", __func__, dev, 

[U-Boot] [PATCH v5 01/15] dma: move dma_ops to dma-uclass.h

2018-03-05 Thread Álvaro Fernández Rojas
Move dma_ops to a separate header file, following other uclass implementations.
While doing so, this patch also improves dma_ops documentation.

Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Simon Glass 
---
 v5: fix build of ti-edma3 (reported by Grygorii Strashko) and remove unneeded
 dma.h include
 v4: no changes
 v3: Introduce changes reported by Simon Glass:
  - Improve dma-uclass.h documentation.
  - Switch to live tree API.

 drivers/dma/dma-uclass.c |  2 +-
 drivers/dma/ti-edma3.c   |  2 +-
 include/dma-uclass.h | 39 +++
 include/dma.h| 22 --
 4 files changed, 41 insertions(+), 24 deletions(-)
 create mode 100644 include/dma-uclass.h

diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 3d0ce22fbc..faa27a3a56 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -10,10 +10,10 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/drivers/dma/ti-edma3.c b/drivers/dma/ti-edma3.c
index 852c9e1fd7..64f9a61b49 100644
--- a/drivers/dma/ti-edma3.c
+++ b/drivers/dma/ti-edma3.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/include/dma-uclass.h b/include/dma-uclass.h
new file mode 100644
index 00..3429f65ec4
--- /dev/null
+++ b/include/dma-uclass.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ * Copyright (C) 2015 Texas Instruments Incorporated 
+ * Written by Mugunthan V N 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _DMA_UCLASS_H
+#define _DMA_UCLASS_H
+
+/* See dma.h for background documentation. */
+
+#include 
+
+/*
+ * struct dma_ops - Driver model DMA operations
+ *
+ * The uclass interface is implemented by all DMA devices which use
+ * driver model.
+ */
+struct dma_ops {
+   /**
+* transfer() - Issue a DMA transfer. The implementation must
+*   wait until the transfer is done.
+*
+* @dev: The DMA device
+* @direction: direction of data transfer (should be one from
+*   enum dma_direction)
+* @dst: The destination pointer.
+* @src: The source pointer.
+* @len: Length of the data to be copied (number of bytes).
+* @return zero on success, or -ve error code.
+*/
+   int (*transfer)(struct udevice *dev, int direction, void *dst,
+   void *src, size_t len);
+};
+
+#endif /* _DMA_UCLASS_H */
diff --git a/include/dma.h b/include/dma.h
index 71fa77f2ea..89320f10d9 100644
--- a/include/dma.h
+++ b/include/dma.h
@@ -28,28 +28,6 @@ enum dma_direction {
 #define DMA_SUPPORTS_DEV_TO_DEVBIT(3)
 
 /*
- * struct dma_ops - Driver model DMA operations
- *
- * The uclass interface is implemented by all DMA devices which use
- * driver model.
- */
-struct dma_ops {
-   /*
-* Get the current timer count
-*
-* @dev: The DMA device
-* @direction: direction of data transfer should be one from
-  enum dma_direction
-* @dst: Destination pointer
-* @src: Source pointer
-* @len: Length of the data to be copied.
-* @return: 0 if OK, -ve on error
-*/
-   int (*transfer)(struct udevice *dev, int direction, void *dst,
-   void *src, size_t len);
-};
-
-/*
  * struct dma_dev_priv - information about a device used by the uclass
  *
  * @supported: mode of transfers that DMA can support, should be
-- 
2.11.0

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


[U-Boot] [PATCH v5 00/15] bmips: add bcm6348-enet support

2018-03-05 Thread Álvaro Fernández Rojas
In order to add bcm6348-enet support, dma-uclass must be extended to support
dma channels and reworked to operate like the other dm uclass (clk, reset...).

v5: Fix issues reported by Grygorii Strashko and other fixes:
 - Fix build of ti-edma3.
 - Remove unused bcm6348-iudma defines.
 - Increment bcm6348-iudma rx descriptors.
 - Fix bcm6348-iudma flow control issues.
 - bcm6348-iudma error checking now depends on hw.
 - Remove unneeded bcm6348-iudma interrupts.
 - Receive as much packets as possible from bcm6348-eth and cache them in
 net_rx_packets. This is needed in order to fix flow control issues.
v4: Fix issues reported by Grygorii Strashko and other fixes:
 - Remove usage of net_rx_packets as buffer from bcm6348-iudma.
 - Allocate dynamic rx buffer on bcm6348-iudma.
 - Copy received dma buffer to net_rx_packets in order to avoid possible
 dma overwrites.
 - Check dma errors and discard invalid packets.
 - Reset dma rx channel when sending a new packet to prevent flow control
 issues.
 - Fix packet casting on bcm6348_eth_recv/send.
v3: Introduce changes reported by Simon Glass:
 - Improve dma-uclass.h documentation.
 - Switch to live tree API.
v2: Introduce changes reported by Vignesh:
 - Respect current dma implementation.
 - Let dma_memcpy find a compatible dma device.
Other changes:
 - Fix bcm6348-iudma rx burst config.

Álvaro Fernández Rojas (15):
  dma: move dma_ops to dma-uclass.h
  dma: add channels support
  dma: add bcm6348-iudma support
  bmips: bcm6338: add bcm6348-iudma support
  bmips: bcm6348: add bcm6348-iudma support
  bmips: bcm6358: add bcm6348-iudma support
  phy: add support for internal phys
  net: add support for bcm6348-enet
  bmips: bcm6338: add support for bcm6348-enet
  bmips: enable f@st1704 enet support
  bmips: bcm6348: add support for bcm6348-enet
  bmips: enable ct-5361 enet support
  bmips: bcm6358: add support for bcm6348-enet
  bmips: enable hg556a enet support
  bmips: enable nb4-ser enet support

 arch/mips/dts/brcm,bcm6338.dtsi   |  29 ++
 arch/mips/dts/brcm,bcm6348.dtsi   |  42 +++
 arch/mips/dts/brcm,bcm6358.dtsi   |  46 +++
 arch/mips/dts/comtrend,ct-5361.dts|  12 +
 arch/mips/dts/huawei,hg556a.dts   |  12 +
 arch/mips/dts/sagem,f...@st1704.dts  |  12 +
 arch/mips/dts/sfr,nb4-ser.dts |  24 ++
 configs/comtrend_ct5361_ram_defconfig |   8 +-
 configs/huawei_hg556a_ram_defconfig   |   8 +-
 configs/sagem_f@st1704_ram_defconfig  |   9 +-
 configs/sfr_nb4-ser_ram_defconfig |   8 +-
 drivers/dma/Kconfig   |  16 +
 drivers/dma/Makefile  |   1 +
 drivers/dma/bcm6348-iudma.c   | 532 +++
 drivers/dma/dma-uclass.c  | 190 ++-
 drivers/dma/ti-edma3.c|   2 +-
 drivers/net/Kconfig   |  10 +
 drivers/net/Makefile  |   1 +
 drivers/net/bcm6348-eth.c | 575 ++
 include/configs/bmips_common.h|   5 +-
 include/dma-uclass.h  | 117 +++
 include/dma.h | 196 ++--
 include/dt-bindings/dma/bcm6338-dma.h |  15 +
 include/dt-bindings/dma/bcm6348-dma.h |  17 +
 include/dt-bindings/dma/bcm6358-dma.h |  17 +
 include/phy.h |   2 +
 26 files changed, 1869 insertions(+), 37 deletions(-)
 create mode 100644 drivers/dma/bcm6348-iudma.c
 create mode 100644 drivers/net/bcm6348-eth.c
 create mode 100644 include/dma-uclass.h
 create mode 100644 include/dt-bindings/dma/bcm6338-dma.h
 create mode 100644 include/dt-bindings/dma/bcm6348-dma.h
 create mode 100644 include/dt-bindings/dma/bcm6358-dma.h

-- 
2.11.0

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


Re: [U-Boot] [RFC v4 01/15] dma: move dma_ops to dma-uclass.h

2018-03-05 Thread Grygorii Strashko
Hi

On 03/03/2018 02:59 AM, Álvaro Fernández Rojas wrote:
> Move dma_ops to a separate header file, following other uclass 
> implementations.
> While doing so, this patch also improves dma_ops documentation.
> 
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Simon Glass 
> ---
>   v4: no changes
>   v3: Introduce changes reported by Simon Glass:
>- Improve dma-uclass.h documentation.
>- Switch to live tree API.
> 
>   drivers/dma/dma-uclass.c |  3 ++-
>   include/dma-uclass.h | 39 +++
>   include/dma.h| 22 --
>   3 files changed, 41 insertions(+), 23 deletions(-)
>   create mode 100644 include/dma-uclass.h
> 

I've sent the same comment for prev patch version also.


this patch will break build of existing DMA drivers, as
the do not have #include .

drivers/dma/ti-edma3.c:563:21: error: variable 'ti_edma3_ops' has initializer 
but incomplete type
 static const struct dma_ops ti_edma3_ops = {
 ^~~
drivers/dma/ti-edma3.c:564:2: error: unknown field 'transfer' specified in 
initializer
  .transfer = ti_edma3_transfer,
  ^
drivers/dma/ti-edma3.c:564:14: warning: excess elements in struct initializer
  .transfer = ti_edma3_transfer,
  ^
drivers/dma/ti-edma3.c:564:14: note: (near initialization for 'ti_edma3_ops')
drivers/dma/ti-edma3.c:563:29: error: storage size of 'ti_edma3_ops' isn't known
 static const struct dma_ops ti_edma3_ops = {
 ^~~~
make[1]: *** [drivers/dma/ti-edma3.o] Error 1

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


Re: [U-Boot] [RFC v3 01/15] dma: move dma_ops to dma-uclass.h

2018-03-05 Thread Grygorii Strashko


On 02/22/2018 10:18 AM, Simon Glass wrote:
> On 21 February 2018 at 09:10, Álvaro Fernández Rojas  
> wrote:
>> Move dma_ops to a separate header file, following other uclass 
>> implementations.
>> While doing so, this patch also improves dma_ops documentation.
>>
>> Signed-off-by: Álvaro Fernández Rojas 
>> ---
>>   v3: Introduce changes reported by Simon Glass:
>>- Improve dma-uclass.h documentation.
>>- Switch to live tree API.
>>
>>   drivers/dma/dma-uclass.c |  3 ++-
>>   include/dma-uclass.h | 39 +++
>>   include/dma.h| 22 --
>>   3 files changed, 41 insertions(+), 23 deletions(-)
>>   create mode 100644 include/dma-uclass.h
> 
> Reviewed-by: Simon Glass 

this patch will break build of existing DMA drivers, as
the do not have #include .

drivers/dma/ti-edma3.c:563:21: error: variable 'ti_edma3_ops' has initializer 
but incomplete type
 static const struct dma_ops ti_edma3_ops = {
 ^~~
drivers/dma/ti-edma3.c:564:2: error: unknown field 'transfer' specified in 
initializer
  .transfer = ti_edma3_transfer,
  ^
drivers/dma/ti-edma3.c:564:14: warning: excess elements in struct initializer
  .transfer = ti_edma3_transfer,
  ^
drivers/dma/ti-edma3.c:564:14: note: (near initialization for 'ti_edma3_ops')
drivers/dma/ti-edma3.c:563:29: error: storage size of 'ti_edma3_ops' isn't known
 static const struct dma_ops ti_edma3_ops = {
 ^~~~
make[1]: *** [drivers/dma/ti-edma3.o] Error 1


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


Re: [U-Boot] MPC8315ERDB: Enable DHCP support

2018-03-05 Thread Marek Vasut
On 03/05/2018 07:54 PM, Tom Rini wrote:
> On Sun, Mar 04, 2018 at 07:17:52PM +0100, Marek Vasut wrote:
> 
>> From: Ed Bartosh 
>>
>> Enable DHCP support for this board.
>>
>> Signed-off-by: Ed Bartosh 
>> Signed-off-by: Marek Vasut 
>> Signed-off-by: Tom Rini 
> 
> Applied to u-boot/master, thanks!

Much appreciated, thanks.

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


Re: [U-Boot] net: phy: marvell: Fix style violations

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860805/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] [U-Boot, 1/1] MAINTAINERS: bring sections into alphabetic order

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 08:15:51AM +0100, Heinrich Schuchardt wrote:

> POWER should be after ONENAND
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] net: e1000: Fix e1000_igb semaphore handling

2018-03-05 Thread Joe Hershberger
Hi Bernhard,

https://patchwork.ozlabs.org/patch/873696/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] net: phy: smsc: Add SMSC LAN8741 support

2018-03-05 Thread Joe Hershberger
Hi Arno,

https://patchwork.ozlabs.org/patch/865881/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] NET: designware: fix clock enable

2018-03-05 Thread Joe Hershberger
Hi Eugeniy,

https://patchwork.ozlabs.org/patch/869785/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] ARM: DTS: Re-sync logicpd-som-lv with Linux 4.16-rc3

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 04:16:33AM -0600, Adam Ford wrote:

> This should clean up a warning about a missing phy-cells
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/dts/logicpd-som-lv.dtsi 
> b/arch/arm/dts/logicpd-som-lv.dtsi
> index 46dae55..c1aa7a4 100644

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] omap3_logic: Remove unnecessary undefs

2018-03-05 Thread Tom Rini
On Sun, Mar 04, 2018 at 03:05:38PM -0600, Adam Ford wrote:

> Due to evolution of the MMC driver and better support, let's
> remove unnecessary undefs.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
> index 6414383..7ffc4f7 100644

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot,3/3] Atmel TPM: Fix potential buffer overruns

2018-03-05 Thread Tom Rini
On Mon, Feb 12, 2018 at 05:56:37PM -0500, Jeremy Boone wrote:

> From: Jeremy Boone 
> 
> Ensure that the Atmel TPM driver performs sufficient
> validation of the length returned in the TPM response header.
> This patch prevents memory corruption if the header contains a
> length value that is larger than the destination buffer.
> 
> Signed-off-by: Jeremy Boone 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] Devboards.de DBM-SoC1 BOARD: Add S line

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 10:21:19AM -0500, Tom Rini wrote:

> This was missing the 'S' line causing a warning from genboardscfg.py
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] scripts/spelling.txt: Sync script with kernel 4.16-rc4

2018-03-05 Thread Tom Rini
On Sun, Mar 04, 2018 at 10:55:19PM -0300, Fabio Estevam wrote:

> From: Fabio Estevam 
> 
> Keep spelling.txt in sync with the version from kernel 4.16-rc4.
> 
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

And funny enough, checkpatch.pl complains about this a bit due to the
spellings :)

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] gpio: pca953x_gpio: Support label setting from DT

2018-03-05 Thread Tom Rini
On Thu, Mar 01, 2018 at 02:45:04PM +0100, Mario Six wrote:

> The PCA953x driver uses "gpio@%x_" as the GPIO bank name, where "%x" is
> instantiated with the I2C address of the chip. While this works, it
> becomes very confusing if a board has multiple PCAs with the same
> address on different I2C busses, and it also becomes an issue when a
> GPIO's value is to be set via the 'gpio' command, because this command
> only ever sets the value of the first device it encounters, leaving the
> other devices inaccessible to the command.
> 
> As to not break boards that rely on this naming scheme, we introduce a
> new device tree string property "label" for the driver. If it exists, it
> is used to build a bank name of the form "%s@%x_" (where %x is still
> instantiated with the I2C address). If it does not exist, the legacy
> labeling scheme is used.
> 
> Signed-off-by: Mario Six 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] spl: Kconfig: Rename SPL_USBETH_SUPPORT to SPL_USB_ETHER to match with the U-boot CONFIG

2018-03-05 Thread Tom Rini
On Fri, Feb 16, 2018 at 09:17:44PM +0530, Faiz Abbas wrote:

> Rename CONFIG_SPL_USBETH_SUPPORT to CONFIG_SPL_USB_ETHER.
> 
> This enables users to block text using CONFIG_IS_ENABLED() instead
> of resorting to #if ladders with SPL and non-SPL cases.
> 
> Signed-off-by: Faiz Abbas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] ti_armv7_omap: Remove comment remnant

2018-03-05 Thread Tom Rini
On Sun, Mar 04, 2018 at 02:54:15PM -0600, Adam Ford wrote:

> With the migration to Kconfig, the I2C block no longer exists in here.
> Let's clean up the comment.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/include/configs/ti_armv7_omap.h b/include/configs/ti_armv7_omap.h
> index 80d4476..9da6ea8 100644

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/1] input: indicate that code page 437 is used

2018-03-05 Thread Tom Rini
On Fri, Mar 02, 2018 at 09:11:35PM +0100, Heinrich Schuchardt wrote:

> Add a comment indicating that the German key map assumes code page 437.
> 
> Add support for character ² (square sign) in the German key map.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/3] STMicro TPM: Fix potential buffer overruns

2018-03-05 Thread Tom Rini
On Mon, Feb 12, 2018 at 05:56:35PM -0500, Jeremy Boone wrote:

> From: Jeremy Boone 
> 
> This patch prevents integer underflow when the length was too small,
> which could lead to memory corruption.
> 
> Signed-off-by: Jeremy Boone 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] pinctrl: Kconfig: Fix typo

2018-03-05 Thread Tom Rini
On Fri, Mar 02, 2018 at 09:56:00AM +0100, Marek Behún wrote:

> Signed-off-by: Marek Behun 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] MPC8315ERDB: Enable DHCP support

2018-03-05 Thread Tom Rini
On Sun, Mar 04, 2018 at 07:17:52PM +0100, Marek Vasut wrote:

> From: Ed Bartosh 
> 
> Enable DHCP support for this board.
> 
> Signed-off-by: Ed Bartosh 
> Signed-off-by: Marek Vasut 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] tools/env: allow equal sign as key value separation

2018-03-05 Thread Tom Rini
On Thu, Mar 01, 2018 at 02:06:32PM +0100, Stefan Agner wrote:

> From: Stefan Agner 
> 
> Treat the first equal sign as a key/value separation too. This makes
> the script files compatible with mkenvimage input file format. It
> won't support variables with equal signs anymore, but this seems not
> really like a loss.
> 
> Signed-off-by: Stefan Agner 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] libfdt: move headers to and

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 01:20:11AM +0900, Masahiro Yamada wrote:

> Thomas reported U-Boot failed to build host tools if libfdt-devel
> package is installed because tools include libfdt headers from
> /usr/include/ instead of using internal ones.
> 
> This commit moves the header code:
>   include/libfdt.h -> include/linux/libfdt.h
>   include/libfdt_env.h -> include/linux/libfdt_env.h
> 
> and replaces include directives:
>   #include   -> #include 
>   #include   -> #include 
> 
> Reported-by: Thomas Petazzoni 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/3] Infineon TPM: Fix potential buffer overruns

2018-03-05 Thread Tom Rini
On Mon, Feb 12, 2018 at 05:56:36PM -0500, Jeremy Boone wrote:

> From: Jeremy Boone 
> 
> Ensure that the Infineon I2C and SPI TPM driver performs adequate
> validation of the length extracted from the TPM response header.
> This patch prevents integer underflow when the length was too small,
> which could lead to memory corruption.
> 
> Signed-off-by: Jeremy Boone 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] tools: Include U-Boot libfdt headers from their actual path

2018-03-05 Thread Tom Rini
On Fri, Mar 02, 2018 at 11:13:42PM +0100, Paul Kocialkowski wrote:

> There are no headers for libfdt in lib/libfdt, as they are instead
> located in scripts/dtc/libfdt. Specifying lib/libfdt for headers
> inclusion in host tools results in using the system libfdt headers,
> which is not what we want. Change this to the proper path.
> 
> Signed-off-by: Paul Kocialkowski 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] phy: Fix style violations

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860804/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] cmd: mdio: Fix style violations

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860794/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] net: phy: marvell 88e151x: Fix handling of bare RGMII interface type

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860763/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] RPi3 Not autobooting from SD-card. {Scanned}

2018-03-05 Thread Peter Robinson
>>> Hi!
>>> I'm trying to boot from u-boot on a Raspberry Pi 3. But for some reason
>>> it
>>> isn't autobooting on the SD-card.
>>>
>>> Is it possible to get more debug output on the screen console? I don't
>>> have
>>> a serial console at the moment.
>>> The output on the screen is:
>>>
>>> Net:   No ehternet found.
>>> starting USB...
>>> USB:Core Release 2.80a
>>> scanning bus 0 for devices... 4 USB Devices found
>>> scanning usb for storage devices... 0 Storage Device(s) found
>>> Hit any key to stop autoboot:   0
>>> U-Boot>
>>>
>>> Shouldn't it mention mmc somewhere in the boot message?
>>>
>>> The first command I type on the prompt is always failing, it's not
>>> outputting anything. Just a new prompt on the next line. The next
>>> commands i
>>> type in are working. Which seems strange.
>>> I got boot.scr set up right, except graphic settings which are wrong. It
>>> is
>>> booting the kernel when I type 'run bootcmd'. But only after I type in
>>> another command before it.
>>> It seems like it's not detecting the SD-card (mmc0) until I have typed
>>> anything into the prompt.
>>>
>>> Do I have to set any other env variable for it to autoboot? I would have
>>> printed the output of printenv here, but since I don't have a serial
>>> console, retyping everything is very time consuming.
>>> printenv seems to have the right settings. It's basically a full console
>>> screen of variables. It just doesn't seem to load them until I type in
>>> another command before it.
>>>
>>> boot_targets=mmc0 usb0 pxe dhcp
>>> Which seems right to me.
>>>
>>> I compiled the latest u-boot from github.
>>>
>>> If you need more info please let me know and I'll post it.
>>>
>>> Hope that anyone can point me in the right direction here. Would really
>>> appreciate it.
>>
>> I'm seeing the same issues with 2018.03 rc3.
>>
>> I'm not sure what the issue is and I've not had time to investigate it
>> further yet, but if you type "boot" and hit enter it should boot,
>> sometimes you actually have to type it twice. It will boot but I'm not
>> sure which bits here have causes this regression.
>
>
> I do not see this at all on my RPi3. Maybe it's firmware version dependent?
> Do you happen to have an image that always fails for you?

2018.03 rc3 with "2018-02-09" firmware (so fairly recent) fails for me.

> Alex
>
>
> U-Boot 2018.03-rc3-00109-g77bba970e2-dirty (Mar 05 2018 - 11:06:36 +0100)
>
> DRAM:  992 MiB
> RPI 3 Model B (0xa02082)
> MMC:   mmc@7e202000: 0, sdhci@7e30: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
> Failed (-5)
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:   Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk m...@7e202000.blk...
> Card did not respond to voltage select!
> Scanning disk sd...@7e30.blk...
> Disk sd...@7e30.blk not ready
> Found 4 disks
> 840192 bytes read in 38 ms (21.1 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> ## Starting EFI application at 0100 ...
> Welcome to GRUB!
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] net: tsec: Make live-tree compatible

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860790/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] net: tsec: Fix memory leak in error path

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860801/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] net: tsec: Fix style violations

2018-03-05 Thread Joe Hershberger
Hi Mario,

https://patchwork.ozlabs.org/patch/860795/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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


Re: [U-Boot] [PATCH] Add xxhash hashing support

2018-03-05 Thread Wolfgang Denk
Dear Dmitry,

In message <1520258115-29823-1-git-send-email-dun...@tecon.ru> you wrote:
> From: Dmitry Dunaev 
> 
> ---

It would be appropriate to provide an explantion of what you are
doing here and why, which advantages it brings, what it costs (in
terms of code size), etc.

In short: please provide a proper commit message.

> +/*
> + * xxHash - Extremely Fast Hash algorithm
> + * Copyright (C) 2012-2016, Yann Collet.
> + *
> + * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> + * met:

> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation. This program is dual-licensed; you may select
> + * either version 2 of the GNU General Public License ("GPL") or BSD license
> + * ("BSD").

Please use SPDX License Tags and remove the license text.

> + * Notice extracted from xxHash homepage:
> + *
> + * xxHash is an extremely fast Hash algorithm, running at RAM speed limits.
> + * It also successfully passes all tests from the SMHasher suite.
> + *
> + * Comparison (single thread, Windows Seven 32 bits, using SMHasher on a 
> Core 2
> + * Duo @3GHz)
> + *
> + * NameSpeed   Q.Score   Author
> + * xxHash  5.4 GB/s 10
> + * CrapWow 3.2 GB/s  2   Andrew
> + * MumurHash 3a2.7 GB/s 10   Austin Appleby
> + * SpookyHash  2.0 GB/s 10   Bob Jenkins
> + * SBox1.4 GB/s  9   Bret Mulvey
> + * Lookup3 1.2 GB/s  9   Bob Jenkins
> + * SuperFastHash   1.2 GB/s  1   Paul Hsieh
> + * CityHash64  1.05 GB/s10   Pike & Alakuijala
> + * FNV 0.55 GB/s 5   Fowler, Noll, Vo
> + * CRC32   0.43 GB/s 9
> + * MD5-32  0.33 GB/s10   Ronald L. Rivest
> + * SHA1-32 0.28 GB/s10
> + *
> + * Q.Score is a measure of quality of the hash function.
> + * It depends on successfully passing SMHasher test set.
> + * 10 is a perfect score.
> + *
> + * A 64-bits version, named xxh64 offers much better speed,
> + * but for 64-bits applications only.
> + * Name Speed on 64 bitsSpeed on 32 bits
> + * xxh64   13.8 GB/s1.9 GB/s
> + * xxh326.8 GB/s6.0 GB/s

This should probably go to the commit message.

...
> + * xxh32_wd() - calculate the 32-bit hash of the input with a given seed.
> + *  Triggering the watchdog every 'chunk_sz' bytes of input
> + *  processed.
> + *
> + * @input:The data to hash.
> + * @length:   The length of the data to hash.
> + * @seed: The seed can be used to alter the result predictably.
> + * @chunk_sz: The chunk size for watchdog triggering.
> + *
> + * Speed on Core 2 Duo @ 3 GHz (single thread, SMHasher benchmark) : 5.4 GB/s

Hm... what is this information good for?  How fast is it on a MPC860
at 50 MHz? How fast on a iMX28 at 400 MHz? 


> + * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> + * met:

See above.  Clean up all over the place and replace with SPDX tags.

Thanks.


Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Intel's new motto: United we stand. Divided we fall!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] sunxi: video: mark framebuffer as EFI reserved memory

2018-03-05 Thread Heinrich Schuchardt

On 03/05/2018 08:19 AM, Anatolij Gustschin wrote:

Hi Heinrich,

On Sat,  3 Mar 2018 10:30:17 +0100
Heinrich Schuchardt xypron.g...@gmx.de wrote:


Inform the EFI subsystem that the framebuffer memory is reserved.

Without the patch the AllocatePool boot service allocates memory from the
framebuffer which will will be overwritten by screen output.

Signed-off-by: Heinrich Schuchardt 


Should this patch be merged into v2018.03 release or can it wait?


Hello Anatolij,

v2018.05 is fine. The problem will become visible in more cases with

[PATCH 1/1] efi_loader: efi_allocate_pages is too restrictive
https://patchwork.ozlabs.org/patch/881055/
https://lists.denx.de/pipermail/u-boot/2018-March/321840.html

which is also pending.

Regards

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


Re: [U-Boot] [PATCH 1/2] mmc: add HS400 support

2018-03-05 Thread Jean-Jacques Hiblot

Hi Peng,

I'm glad you are adding HS400 support. Thanks.


On 05/03/2018 10:11, Peng Fan wrote:

Add HS400 support.
Selecting HS400 needs first select HS199 according to spec, so use
a dedicated function for HS400.
Add HS400 related macros.
Remove the restriction of only using the low 6 bits of
EXT_CSD_CARD_TYPE, using all the 8 bits.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Jean-Jacques Hiblot 
Cc: Stefano Babic 
Cc: Simon Glass 
Cc: Kishon Vijay Abraham I 
Cc: Bin Meng 
---
  drivers/mmc/Kconfig |   7 +++
  drivers/mmc/mmc.c   | 133 ++--
  include/mmc.h   |  12 +
  3 files changed, 127 insertions(+), 25 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 5f67e336db..e9be18b333 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
  cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
  frequency can go up to 208MHz (SDR104)
  
+config MMC_HS400_SUPPORT

+   bool "enable HS400 support"
+   select MMC_HS200_SUPPORT
I'd use "depends on" instead of select or maybe use the same option for 
both HS200 and HS400

+   help
+ The HS400 mode is support by some eMMC. The bus frequency is up to
+ 200MHz. This mode requires tuning the IO.
+
  config MMC_HS200_SUPPORT
bool "enable HS200 support"
help
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 92ea78b8af..eef229c8b4 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -169,6 +169,7 @@ const char *mmc_mode_name(enum bus_mode mode)
  [MMC_HS_52]   = "MMC High Speed (52MHz)",
  [MMC_DDR_52]  = "MMC DDR52 (52MHz)",
  [MMC_HS_200]  = "HS200 (200MHz)",
+ [MMC_HS_400]  = "HS400 (200MHz)",
};
  
  	if (mode >= MMC_MODES_END)

@@ -193,6 +194,7 @@ static uint mmc_mode2freq(struct mmc *mmc, enum bus_mode 
mode)
  [UHS_DDR50]   = 5000,
  [UHS_SDR104]  = 20800,
  [MMC_HS_200]  = 2,
+ [MMC_HS_400]  = 2,
};
  
  	if (mode == MMC_LEGACY)

@@ -790,6 +792,11 @@ static int mmc_set_card_speed(struct mmc *mmc, enum 
bus_mode mode)
case MMC_HS_200:
speed_bits = EXT_CSD_TIMING_HS200;
break;
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   case MMC_HS_400:
+   speed_bits = EXT_CSD_TIMING_HS400;
+   break;
  #endif
case MMC_LEGACY:
speed_bits = EXT_CSD_TIMING_LEGACY;
@@ -837,7 +844,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
  
  	mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
  
-	cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0x3f;

+   cardtype = ext_csd[EXT_CSD_CARD_TYPE];
mmc->cardtype = cardtype;
  
  #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)

@@ -845,6 +852,12 @@ static int mmc_get_capabilities(struct mmc *mmc)
EXT_CSD_CARD_TYPE_HS200_1_8V)) {
mmc->card_caps |= MMC_MODE_HS200;
}
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   if (cardtype & (EXT_CSD_CARD_TYPE_HS400_1_2V |
+   EXT_CSD_CARD_TYPE_HS400_1_8V)) {
+   mmc->card_caps |= MMC_MODE_HS400;
+   }
  #endif
if (cardtype & EXT_CSD_CARD_TYPE_52) {
if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
@@ -1748,6 +1761,12 @@ static int mmc_set_lowest_voltage(struct mmc *mmc, enum 
bus_mode mode,
u32 card_mask = 0;
  
  	switch (mode) {

+   case MMC_HS_400:
+   if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS400_1_8V)
+   card_mask |= MMC_SIGNAL_VOLTAGE_180;
+   if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS400_1_2V)
+   card_mask |= MMC_SIGNAL_VOLTAGE_120;
+   break;
case MMC_HS_200:
if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS200_1_8V)
card_mask |= MMC_SIGNAL_VOLTAGE_180;
@@ -1787,6 +1806,13 @@ static inline int mmc_set_lowest_voltage(struct mmc 
*mmc, enum bus_mode mode,
  #endif
  
  static const struct mode_width_tuning mmc_modes_by_pref[] = {

+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   {
+   .mode = MMC_HS_400,
+   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
+   .tuning = MMC_CMD_SEND_TUNING_BLOCK_HS200
+   },
+#endif
  #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
{
.mode = MMC_HS_200,
@@ -1830,6 +1856,54 @@ static const struct ext_csd_bus_width {
{MMC_MODE_1BIT, false, EXT_CSD_BUS_WIDTH_1},
  };
  
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)

+static int mmc_select_hs400(struct mmc *mmc)
+{
+   int err;
+
+   /* Set timing to HS200 for tuning */
+   err = mmc_set_card_speed(mmc, MMC_HS_200);
+  

[U-Boot] LS1043A-RDB GPIO

2018-03-05 Thread Joshua Wallace
Hi experts.
I am new to u-boot and would like to share some concern.
I will use GPIO on a custom board based on LS1043A so for now I’m using the
NXP LS1043ARDB.
When I enable GPIO in configs/ls1043ardb_defconfig cmd/gpio.c does not
compile because of a strange inclusion.

1) My code is based on the u-boot-fsl-qoriq custodian tree but the issue
seems to have global scope since the involved piece of code
exists in the mainline repository.

2) Enabling GPIO in configs/ls1043ardb_defconfig

CONFIG_DM_GPIO=y
CONFIG_LS1043A_GPIO=y
CONFIG_CMD_GPIO=y

3) Compilation output

In file included from cmd/gpio.c:13:0:
./arch/arm/include/asm/gpio.h:4:27: fatal error: asm/arch/gpio.h: No such
file or directory
 #include 
   ^
compilation terminated.
make[1]: *** [cmd/gpio.o] Erreur 1
make: *** [cmd] Erreur 2

Using find command on the u-boot root it looks like the file really does
not exist.

4) If I disable this file inclusion (#if(0)…#endif) everything seems to
work fine and I may access the only GPIO + led of my board
I would like to ask if I’m missing something or if this code may be a
legacy code.

Thanks in advance.
J.W.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

2018-03-05 Thread Jonathan Cormer
On Sat, 2018-03-03 at 12:00 +, u-boot-requ...@lists.denx.de wrote:
> 
> On 1 March 2018 at 16:33, Tom Rini  wrote:
> > 
> > On Thu, Mar 01, 2018 at 04:10:44PM +0200, Ruslan Bilovol wrote:
> > > 
> > > Hi Lukasz,
> > > 
> > > On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski 
> > > wrote:
> > > > 
> > > > Hi Ruslan,
> > > > 
> > > > > 
> > > > > Remove busy looping during watchdog reset.
> > > > > Each polling of W_PEND_WTGR bit ("finish posted
> > > > > write") after watchdog reset takes 120-140us
> > > > > on BeagleBone Black board. Current U-Boot code
> > > > > has watchdog resets in random places and often
> > > > > there is situation when watchdog is reset
> > > > > few times in a row in nested functions.
> > > > > This adds extra delays and slows the whole system.
> > > > > 
> > > > > Instead of polling W_PEND_WTGR bit, we skip
> > > > > watchdog reset if the bit is set. Anyway, watchdog
> > > > > is in the middle of reset *right now*, so we can
> > > > > just return.
> > > > It seems like similar problem may be in the Linux kernel
> > > > driver:
> > > > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74
> > > > 
> > > > Linux driver also waits for the write.
> > > Right, Linux driver has similar code but it doesn't affect
> > > performance.
> > > This is because of watchdog usage in Linux, it is enabled and
> > > reset by userspace. This is quite rare event.
> > > Moreover, since Linux has interrupts enabled and has scheduling,
> > > such busy loops in the omap driver are not very different to
> > > just mdelay() usage. The system can handle interrupts, and can
> > > even do preemption if PREEMPT is enabled.
> > > So use of such busy loops in that particular case shouldn't cause
> > > any noticeable performance issues.
> > True.  But, can you also submit a patch to the kernel side (and CC
> > me) ?
> > That's far more likely to get the attention of the engineers that
> > might
> > know of corner cases with the various SoC families where we might
> > need
> > to keep doing what we're doing or other possible problems.  Thanks!
> > 
> Some additional input from my side.
> 
> My previous measurements were wrong, due to usage of slow USB hub
> port
> on my laptop. Using another USB port I have next transfer speed for
> "fastboot flash" operation:
>  - without patch: 2.84 MiB/sec
>  - with patch: 7.81  MiB/sec
> 
> So it gives us about 2.75 times improvement, as stated by Ruslan in
> his commit message. Also, I tested that WDT continues to work
> correctly, and it does (tried several use-cases, and also debug patch
> with infinite loop). So again:
> 
> Tested-by: Sam Protsenko 
> 
> Also:
> 
> Reviewed-by: Sam Protsenko 
> 
> I checked the code and I can say that there shouldn't be any concerns
> about WDT functionality with this patch. By the way, in my opinion,
> for kernel this patch doesn't make much sense, and there might be
> even
> confusion in case we send it... If there any concerns about it, we
> can
> invite related engineers in this discussion, asking them to review
> this.
> 
> Overall, I think this patch is "must have" in U-Boot, as it gives us
> dramatic improvement without any drawbacks, especially for AM335x
> boards. It's probably the best approach for WDT reset procedure until
> interrupts are enabled for ARM architecture (if we even consider it).
Tested patch with AM335x on custom u-boot-2013.10 based branch. Patch
cleanly applied, obviously not much in this wdt driver has changed
since then.

Fastboot flash
Before patch: 2.89MiB/s
After patch: 8.68MiB/s

Tested-by: Jonathan Cormier 
Reviewed-by: Jonathan Cormier 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] Devboards.de DBM-SoC1 BOARD: Add S line

2018-03-05 Thread Tom Rini
This was missing the 'S' line causing a warning from genboardscfg.py

Signed-off-by: Tom Rini 
---
 board/devboards/dbm-soc1/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/devboards/dbm-soc1/MAINTAINERS 
b/board/devboards/dbm-soc1/MAINTAINERS
index 8a556e1948bb..625f2c889964 100644
--- a/board/devboards/dbm-soc1/MAINTAINERS
+++ b/board/devboards/dbm-soc1/MAINTAINERS
@@ -1,4 +1,5 @@
 Devboards.de DBM-SoC1 BOARD
 M: Marek Vasut 
+S: Maintained
 F: include/configs/socfpga_dbm_soc1.h
 F: configs/socfpga_dbm_soc1_defconfig
-- 
2.7.4

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


Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

2018-03-05 Thread Tom Rini
On Sun, Mar 04, 2018 at 04:00:15PM +0200, Ruslan Bilovol wrote:
> On Thu, Mar 1, 2018 at 4:33 PM, Tom Rini  wrote:
> > On Thu, Mar 01, 2018 at 04:10:44PM +0200, Ruslan Bilovol wrote:
> >> Hi Lukasz,
> >>
> >> On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski  wrote:
> >> > Hi Ruslan,
> >> >
> >> >> Remove busy looping during watchdog reset.
> >> >> Each polling of W_PEND_WTGR bit ("finish posted
> >> >> write") after watchdog reset takes 120-140us
> >> >> on BeagleBone Black board. Current U-Boot code
> >> >> has watchdog resets in random places and often
> >> >> there is situation when watchdog is reset
> >> >> few times in a row in nested functions.
> >> >> This adds extra delays and slows the whole system.
> >> >>
> >> >> Instead of polling W_PEND_WTGR bit, we skip
> >> >> watchdog reset if the bit is set. Anyway, watchdog
> >> >> is in the middle of reset *right now*, so we can
> >> >> just return.
> >> >
> >> > It seems like similar problem may be in the Linux kernel driver:
> >> > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74
> >> >
> >> > Linux driver also waits for the write.
> >>
> >> Right, Linux driver has similar code but it doesn't affect performance.
> >> This is because of watchdog usage in Linux, it is enabled and
> >> reset by userspace. This is quite rare event.
> >> Moreover, since Linux has interrupts enabled and has scheduling,
> >> such busy loops in the omap driver are not very different to
> >> just mdelay() usage. The system can handle interrupts, and can
> >> even do preemption if PREEMPT is enabled.
> >> So use of such busy loops in that particular case shouldn't cause
> >> any noticeable performance issues.
> >
> > True.  But, can you also submit a patch to the kernel side (and CC me) ?
> > That's far more likely to get the attention of the engineers that might
> > know of corner cases with the various SoC families where we might need
> > to keep doing what we're doing or other possible problems.  Thanks!
> 
> Do you mean just resend this patch, but include kernel watchdog
> mailing list?

Well, I'm going to set aside what I said here since we've gotten some TI
folks to review the patch here.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v10 2/4] cmd: ubifs: Move ubifs_initialized checking into cmd_ubifs_umount()

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 05:43:36PM +0800, tien.fong.c...@intel.com wrote:

> From: Tien Fong Chee 
> 
> cmd_ubifs_umount() function would be called directly instead of involving
> whole command machinery in generic firmware loader, so checking on
> ubifs_initialized status need to be done in cmd_ubifs_umount() without
> breaking original functionality design.
> 
> Signed-off-by: Tien Fong Chee 
> Reviewed-by: Marek Vasut 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] Add xxhash hashing support

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 04:55:15PM +0300, dun...@tecon.ru wrote:

> From: Dmitry Dunaev 

Please add some comments about why we're adding this support and where
it's used.

[snip]
>  common/image-fit.c  |   7 ++
>  include/image.h |  12 +++
>  include/u-boot/xxhash.h | 143 ++
>  lib/Kconfig |   8 ++
>  lib/Makefile|   1 +
>  lib/xxhash.c| 265 
> 
>  tools/Makefile  |   2 +
>  7 files changed, 438 insertions(+)

Please enable this for sandbox, where it should build cleanly and
without warnings.  If you can add a test for it under test/py/tests/
that would be even better.

> diff --git a/include/u-boot/xxhash.h b/include/u-boot/xxhash.h
> new file mode 100644
> index 000..ecbeb98
> --- /dev/null
> +++ b/include/u-boot/xxhash.h
> @@ -0,0 +1,143 @@
> +/*
> + * xxHash - Extremely Fast Hash algorithm
> + * Copyright (C) 2012-2016, Yann Collet.
> + *
> + * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
[snip]
> diff --git a/lib/xxhash.c b/lib/xxhash.c
> new file mode 100644
> index 000..c9fe476
> --- /dev/null
> +++ b/lib/xxhash.c
> @@ -0,0 +1,265 @@
> +/*
> + * xxHash - Extremely Fast Hash algorithm
> + * Copyright (C) 2012-2016, Yann Collet.
> + *
> + * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

SPDX tag only please.

Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 10/16] pmic: add stpmu1 support

2018-03-05 Thread Patrick Delaunay
This driver implements register read/write operations for STPMU1.

The STPMU1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF
and 2 power switches. It is accessed via an I2C interface.
This device is used with STM32MP1 SoCs.

Signed-off-by: Patrick Delaunay 
---

 drivers/power/pmic/Kconfig  |  8 +
 drivers/power/pmic/Makefile |  1 +
 drivers/power/pmic/stpmu1.c | 62 +
 include/power/stpmu1.h  | 85 +
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/power/pmic/stpmu1.c
 create mode 100644 include/power/stpmu1.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 5d49c93..40ab9f7 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -209,3 +209,11 @@ config DM_PMIC_TPS65910
The TPS65910 is a PMIC containing 3 buck DC-DC converters, one boost
DC-DC converter, 8 LDOs and a RTC. This driver binds the SMPS and LDO
pmic children.
+
+config PMIC_STPMU1
+   bool "Enable support for STMicroelectronics STPMU1 PMIC"
+   depends on DM_PMIC && DM_I2C
+   ---help---
+   The STPMU1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF and 2 power switches.
+   It is accessed via an I2C interface. The device is used with STM32MP1
+   SoCs. This driver implements register read/write operations.
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index fc19fdc..ad32068 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o
 obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
 obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
 obj-$(CONFIG_$(SPL_)PMIC_LP87565) += lp87565.o
+obj-$(CONFIG_PMIC_STPMU1) += stpmu1.o
 
 obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
 obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
diff --git a/drivers/power/pmic/stpmu1.c b/drivers/power/pmic/stpmu1.c
new file mode 100644
index 000..4615365
--- /dev/null
+++ b/drivers/power/pmic/stpmu1.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STMPU1_NUM_OF_REGS 0x100
+
+static int stpmu1_reg_count(struct udevice *dev)
+{
+   return STMPU1_NUM_OF_REGS;
+}
+
+static int stpmu1_write(struct udevice *dev, uint reg, const uint8_t *buff,
+   int len)
+{
+   int ret;
+
+   ret = dm_i2c_write(dev, reg, buff, len);
+   if (ret)
+   dev_err(dev, "%s: failed to write register %#x :%d",
+   __func__, reg, ret);
+
+   return ret;
+}
+
+static int stpmu1_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   int ret;
+
+   ret = dm_i2c_read(dev, reg, buff, len);
+   if (ret)
+   dev_err(dev, "%s: failed to read register %#x : %d",
+   __func__, reg, ret);
+
+   return ret;
+}
+
+static struct dm_pmic_ops stpmu1_ops = {
+   .reg_count = stpmu1_reg_count,
+   .read = stpmu1_read,
+   .write = stpmu1_write,
+};
+
+static const struct udevice_id stpmu1_ids[] = {
+   { .compatible = "st,stpmu1" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_stpmu1) = {
+   .name = "stpmu1_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = stpmu1_ids,
+   .ops = _ops,
+};
diff --git a/include/power/stpmu1.h b/include/power/stpmu1.h
new file mode 100644
index 000..697e245
--- /dev/null
+++ b/include/power/stpmu1.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#ifndef __PMIC_STPMU1_H_
+#define __PMIC_STPMU1_H_
+
+#define STPMU1_MASK_RESET_BUCK 0x18
+#define STPMU1_BUCKX_CTRL_REG(buck)(0x20 + (buck))
+#define STPMU1_VREF_CTRL_REG   0x24
+#define STPMU1_LDOX_CTRL_REG(ldo)  (0x25 + (ldo))
+#define STPMU1_USB_CTRL_REG0x40
+#define STPMU1_NVM_USER_STATUS_REG 0xb8
+#define STPMU1_NVM_USER_CONTROL_REG0xb9
+
+#define STPMU1_MASK_RESET_BUCK3BIT(2)
+
+#define STPMU1_BUCK_EN BIT(0)
+#define STPMU1_BUCK_MODE   BIT(1)
+#define STPMU1_BUCK_OUTPUT_MASKGENMASK(7, 2)
+#define STPMU1_BUCK_OUTPUT_SHIFT   2
+#define STPMU1_BUCK2_120V  (24 << STPMU1_BUCK_OUTPUT_SHIFT)
+#define STPMU1_BUCK2_135V  (30 << STPMU1_BUCK_OUTPUT_SHIFT)
+#define STPMU1_BUCK3_180V  (39 << STPMU1_BUCK_OUTPUT_SHIFT)
+
+#define STPMU1_VREF_EN BIT(0)
+
+#define STPMU1_LDO_EN  BIT(0)
+#define STPMU1_LDO12356_OUTPUT_MASKGENMASK(6, 2)
+#define STPMU1_LDO12356_OUTPUT_SHIFT   2
+#define STPMU1_LDO3_MODE   BIT(7)
+#define STPMU1_LDO3_DDR_SEL31
+#define STPMU1_LDO3_180(9 << 

Re: [U-Boot] [PATCH v10 3/4] cmd: ubifs: Factor out some checking codes into cmd_ubifs_mount()

2018-03-05 Thread Tom Rini
On Mon, Mar 05, 2018 at 05:43:37PM +0800, tien.fong.c...@intel.com wrote:

> From: Tien Fong Chee 
> 
> cmd_ubifs_mount() function would be called directly instead of
> involving whole command machinery for mounting ubifs in
> generic firmware loader, so some checking codes need to be factored out
> into cmd_ubifs_mount() without breaking original functionality design.
> 
> Signed-off-by: Tien Fong Chee 
> Reviewed-by: Marek Vasut 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 13/16] clk: add driver for stm32mp1

2018-03-05 Thread Patrick Delaunay
add RCC clock driver for STMP32MP157
- base on driver model = UCLASS_CLK
- support ops to enable, disable and get rate
  of all SOC clock needed by U-Boot

Signed-off-by: Patrick Delaunay 
---

 MAINTAINERS|1 +
 drivers/clk/Kconfig|8 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk_stm32mp1.c | 1157 
 4 files changed, 1167 insertions(+)
 create mode 100644 drivers/clk/clk_stm32mp1.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ff7b837..052b9f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -195,6 +195,7 @@ ARM STM STM32MP
 M: Patrick Delaunay 
 S: Maintained
 F: arch/arm/mach-stm32mp
+F: clk/clk_stm32mp1.c
 F: ram/stm32mp1
 
 ARM STM STV0991
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index cdfa052..c382e88 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -75,6 +75,14 @@ config CLK_ZYNQMP
  This clock driver adds support for clock realted settings for
  ZynqMP platform.
 
+config CLK_STM32MP1
+   bool "Enable RCC clock driver for STM32MP1"
+   depends on ARCH_STM32MP && CLK
+   default y
+   help
+ Enable the STM32 clock (RCC) driver. Enable support for
+ manipulating STM32MP1's on-SoC clocks.
+
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/exynos/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index dab106a..e05c607 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CLK_EXYNOS) += exynos/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_RENESAS) += renesas/
 obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
+obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_CLK_ZYNQ) += clk_zynq.o
 obj-$(CONFIG_CLK_ZYNQMP) += clk_zynqmp.o
diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
new file mode 100644
index 000..0ea2035
--- /dev/null
+++ b/drivers/clk/clk_stm32mp1.c
@@ -0,0 +1,1157 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_HSI_HZ 6400
+
+/* RCC registers */
+#define RCC_OCENSETR   0x0C
+#define RCC_OCENCLRR   0x10
+#define RCC_HSICFGR0x18
+#define RCC_MPCKSELR   0x20
+#define RCC_ASSCKSELR  0x24
+#define RCC_RCK12SELR  0x28
+#define RCC_MPCKDIVR   0x2C
+#define RCC_AXIDIVR0x30
+#define RCC_APB4DIVR   0x3C
+#define RCC_APB5DIVR   0x40
+#define RCC_RTCDIVR0x44
+#define RCC_MSSCKSELR  0x48
+#define RCC_PLL1CR 0x80
+#define RCC_PLL1CFGR1  0x84
+#define RCC_PLL1CFGR2  0x88
+#define RCC_PLL1FRACR  0x8C
+#define RCC_PLL1CSGR   0x90
+#define RCC_PLL2CR 0x94
+#define RCC_PLL2CFGR1  0x98
+#define RCC_PLL2CFGR2  0x9C
+#define RCC_PLL2FRACR  0xA0
+#define RCC_PLL2CSGR   0xA4
+#define RCC_I2C46CKSELR0xC0
+#define RCC_CPERCKSELR 0xD0
+#define RCC_STGENCKSELR0xD4
+#define RCC_DDRITFCR   0xD8
+#define RCC_BDCR   0x140
+#define RCC_RDLSICR0x144
+#define RCC_MP_APB4ENSETR  0x200
+#define RCC_MP_APB5ENSETR  0x208
+#define RCC_MP_AHB5ENSETR  0x210
+#define RCC_MP_AHB6ENSETR  0x218
+#define RCC_OCRDYR 0x808
+#define RCC_DBGCFGR0x80C
+#define RCC_RCK3SELR   0x820
+#define RCC_RCK4SELR   0x824
+#define RCC_MCUDIVR0x830
+#define RCC_APB1DIVR   0x834
+#define RCC_APB2DIVR   0x838
+#define RCC_APB3DIVR   0x83C
+#define RCC_PLL3CR 0x880
+#define RCC_PLL3CFGR1  0x884
+#define RCC_PLL3CFGR2  0x888
+#define RCC_PLL3FRACR  0x88C
+#define RCC_PLL3CSGR   0x890
+#define RCC_PLL4CR 0x894
+#define RCC_PLL4CFGR1  0x898
+#define RCC_PLL4CFGR2  0x89C
+#define RCC_PLL4FRACR  0x8A0
+#define RCC_PLL4CSGR   0x8A4
+#define RCC_I2C12CKSELR0x8C0
+#define RCC_I2C35CKSELR0x8C4
+#define RCC_UART6CKSELR0x8E4
+#define RCC_UART24CKSELR   0x8E8
+#define RCC_UART35CKSELR   0x8EC
+#define RCC_UART78CKSELR   0x8F0
+#define RCC_SDMMC12CKSELR  0x8F4
+#define RCC_SDMMC3CKSELR   0x8F8
+#define RCC_ETHCKSELR  0x8FC
+#define RCC_QSPICKSELR 0x900
+#define RCC_FMCCKSELR  0x904
+#define RCC_USBCKSELR  0x91C
+#define RCC_MP_APB1ENSETR  0xA00
+#define RCC_MP_APB2ENSETR  0XA08
+#define RCC_MP_AHB2ENSETR  0xA18
+#define RCC_MP_AHB4ENSETR  0xA28
+
+/* used for most of SELR register */
+#define 

[U-Boot] [PATCH 01/16] tools/mkimage: add support for STM32 image format

2018-03-05 Thread Patrick Delaunay
STM32MP157 bootrom needs a specific header for first boot stage.
This patch adds support of this header in mkimage.

Signed-off-by: Patrick Delaunay 
---

 common/image.c |   1 +
 include/image.h|   1 +
 tools/Makefile |   1 +
 tools/stm32image.c | 148 +
 4 files changed, 151 insertions(+)
 create mode 100644 tools/stm32image.c

diff --git a/common/image.c b/common/image.c
index e9609cd..a58b9c1 100644
--- a/common/image.c
+++ b/common/image.c
@@ -161,6 +161,7 @@ static const table_entry_t uimage_type[] = {
{   IH_TYPE_TEE,"tee","Trusted Execution 
Environment Image",},
{   IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 IVT" 
},
{   IH_TYPE_PMMC,"pmmc","TI Power Management 
Micro-Controller Firmware",},
+   {   IH_TYPE_STM32IMAGE, "stm32image", "STMicroelectronics STM32 
Image" },
{   -1, "",   "",   },
 };
 
diff --git a/include/image.h b/include/image.h
index 325b014..34aac9f 100644
--- a/include/image.h
+++ b/include/image.h
@@ -272,6 +272,7 @@ enum {
IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
IH_TYPE_FIRMWARE_IVT,   /* Firmware Image with HABv4 IVT */
IH_TYPE_PMMC,/* TI Power Management Micro-Controller 
Firmware */
+   IH_TYPE_STM32IMAGE, /* STMicroelectronics STM32 Image */
 
IH_TYPE_COUNT,  /* Number of image types */
 };
diff --git a/tools/Makefile b/tools/Makefile
index d3387fa..8a0c0bf 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -103,6 +103,7 @@ dumpimage-mkimage-objs := aisimage.o \
pblimage.o \
pbl_crc32.o \
vybridimage.o \
+   stm32image.o \
$(ROCKCHIP_OBS) \
socfpgaimage.o \
lib/sha1.o \
diff --git a/tools/stm32image.c b/tools/stm32image.c
new file mode 100644
index 000..437e384
--- /dev/null
+++ b/tools/stm32image.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include "imagetool.h"
+
+/* magic ='S' 'T' 'M' 0x32 */
+#define HEADER_MAGIC be32_to_cpu(0x53544D32)
+#define VER_MAJOR_IDX  2
+#define VER_MINOR_IDX  1
+#define VER_VARIANT_IDX0
+#define HEADER_VERSION_V1  0x1
+/* default option : bit0 => no signature */
+#define HEADER_DEFAULT_OPTION  (cpu_to_le32(0x0001))
+
+struct stm32_header {
+   uint32_t magic_number;
+   uint32_t image_signature[64 / 4];
+   uint32_t image_checksum;
+   uint8_t  header_version[4];
+   uint32_t image_length;
+   uint32_t image_entry_point;
+   uint32_t reserved1;
+   uint32_t load_address;
+   uint32_t reserved2;
+   uint32_t version_number;
+   uint32_t option_flags;
+   uint32_t ecdsa_algorithm;
+   uint32_t ecdsa_public_key[64 / 4];
+   uint32_t padding[84 / 4];
+};
+
+static struct stm32_header stm32image_header;
+
+static void stm32image_default_header(struct stm32_header *ptr)
+{
+   if (!ptr)
+   return;
+
+   ptr->magic_number = HEADER_MAGIC;
+   ptr->header_version[VER_MAJOR_IDX] = HEADER_VERSION_V1;
+   ptr->option_flags = HEADER_DEFAULT_OPTION;
+   ptr->ecdsa_algorithm = 1;
+}
+
+static uint32_t stm32image_checksum(void *start, uint32_t len)
+{
+   uint32_t csum = 0;
+   uint32_t hdr_len = sizeof(struct stm32_header);
+   uint8_t *p;
+
+   if (len < hdr_len)
+   return 0;
+
+   p = start + hdr_len;
+   len -= hdr_len;
+
+   while (len > 0) {
+   csum += *p;
+   p++;
+   len--;
+   }
+
+   return csum;
+}
+
+static int stm32image_check_image_types(uint8_t type)
+{
+   if (type == IH_TYPE_STM32IMAGE)
+   return EXIT_SUCCESS;
+   return EXIT_FAILURE;
+}
+
+static int stm32image_verify_header(unsigned char *ptr, int image_size,
+   struct image_tool_params *params)
+{
+   struct stm32_header *stm32hdr = (struct stm32_header *)ptr;
+   int i;
+
+   if (image_size < sizeof(struct stm32_header))
+   return -1;
+   if (stm32hdr->magic_number != HEADER_MAGIC)
+   return -1;
+   if (stm32hdr->header_version[VER_MAJOR_IDX] != HEADER_VERSION_V1)
+   return -1;
+   if (stm32hdr->reserved1 || stm32hdr->reserved2)
+   return -1;
+   for (i = 0; i < (sizeof(stm32hdr->padding) / 4); i++) {
+   if (stm32hdr->padding[i] != 0)
+   return -1;
+   }
+
+   return 0;
+}
+
+static void stm32image_print_header(const void *ptr)
+{
+   struct stm32_header *stm32hdr = (struct stm32_header *)ptr;

[U-Boot] [PATCH 00/16] arm: stm32mp1: add initial support for STM32MP157

2018-03-05 Thread Patrick Delaunay

This patch-set adds initial support of STMicroelectronics STM32MP157
microprocessor (MPU)
- add new arm arch stm32mp1 (based on armv7)
- support for stm32mp157 SOC (based on Cortex-A7)
- add minimal support for board evaluation board STM32MP157C-ED1


Patrick Delaunay (16):
  tools/mkimage: add support for STM32 image format
  spl: add SPL_RESET_SUPPORT
  common: add a prototype for mach_cpu_init()
  arm: armv7: solve issue for timer_rate_hz in arch timer
  dm: gpio: Convert stm32f7 driver to livetree
  gpio: stm32f7_gpio: handle node ngpios
  stm32mp: stm32f7_i2c: use calloc instead of kmalloc
  arm: stm32: add new architecture for STM32MP family
  ram: stm32mp1: add driver
  pmic: add stpmu1 support
  pinctrl: stm32: update pincontrol for stmp32mp157
  reset: stm32: adapt driver for stm32mp1
  clk: add driver for stm32mp1
  clk: stm32mp1: add clock tree initialization
  dts: add device tree for STM32MP157C-ED1 board
  board: st: add generic board for STM32MP1 family

 MAINTAINERS|7 +
 arch/arm/Kconfig   |   25 +-
 arch/arm/Makefile  |1 +
 arch/arm/cpu/armv7/arch_timer.c|   22 +-
 arch/arm/dts/Makefile  |3 +
 arch/arm/dts/stm32mp15-ddr.dtsi|  155 ++
 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi   |  122 ++
 arch/arm/dts/stm32mp157-u-boot.dtsi|  134 ++
 arch/arm/dts/stm32mp157.dtsi   |  303 
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   |  133 ++
 arch/arm/dts/stm32mp157c-ed1.dts   |  167 ++
 arch/arm/mach-stm32mp/Kconfig  |   43 +
 arch/arm/mach-stm32mp/Makefile |   10 +
 arch/arm/mach-stm32mp/config.mk|   14 +
 arch/arm/mach-stm32mp/cpu.c|  139 ++
 arch/arm/mach-stm32mp/dram_init.c  |   34 +
 arch/arm/mach-stm32mp/include/mach/ddr.h   |   12 +
 arch/arm/mach-stm32mp/include/mach/gpio.h  |  115 ++
 arch/arm/mach-stm32mp/include/mach/stm32.h |   27 +
 arch/arm/mach-stm32mp/spl.c|   60 +
 board/st/stm32mp1/Kconfig  |   12 +
 board/st/stm32mp1/MAINTAINERS  |7 +
 board/st/stm32mp1/Makefile |   13 +
 board/st/stm32mp1/README   |  191 +++
 board/st/stm32mp1/board.c  |   75 +
 board/st/stm32mp1/spl.c|   33 +
 board/st/stm32mp1/stm32mp1.c   |   27 +
 common/image.c |1 +
 common/spl/Kconfig |9 +
 configs/stm32mp15_basic_defconfig  |   36 +
 doc/device-tree-bindings/clock/st,stm32mp1.txt |  226 +++
 doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt   |  299 
 drivers/Makefile   |1 +
 drivers/clk/Kconfig|8 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk_stm32mp1.c | 1733 
 drivers/gpio/Kconfig   |2 +-
 drivers/gpio/stm32f7_gpio.c|   15 +-
 drivers/i2c/Kconfig|2 +-
 drivers/i2c/stm32f7_i2c.c  |4 +-
 drivers/pinctrl/pinctrl_stm32.c|9 +-
 drivers/power/pmic/Kconfig |8 +
 drivers/power/pmic/Makefile|1 +
 drivers/power/pmic/stpmu1.c|   62 +
 drivers/ram/Kconfig|2 +
 drivers/ram/Makefile   |1 +
 drivers/ram/stm32mp1/Kconfig   |   12 +
 drivers/ram/stm32mp1/Makefile  |8 +
 drivers/ram/stm32mp1/stm32mp1_ddr.c|  496 ++
 drivers/ram/stm32mp1/stm32mp1_ddr.h|  210 +++
 drivers/ram/stm32mp1/stm32mp1_ddr_regs.h   |  365 +
 drivers/ram/stm32mp1/stm32mp1_ram.c|  197 +++
 drivers/reset/Kconfig  |2 +-
 drivers/reset/stm32-reset.c|   36 +-
 drivers/serial/Kconfig |6 +-
 include/common.h   |   10 +
 include/configs/stm32mp1.h |   97 ++
 include/dt-bindings/clock/stm32mp1-clks.h  |  243 +++
 include/dt-bindings/clock/stm32mp1-clksrc.h|  284 
 .../dt-bindings/reset-controller/stm32mp1-resets.h |   97 ++
 include/image.h|1 +
 include/power/stpmu1.h |   85 +
 tools/Makefile |1 +
 tools/stm32image.c |  148 ++
 64 files changed, 6555 insertions(+), 47 

[U-Boot] [PATCH 08/16] arm: stm32: add new architecture for STM32MP family

2018-03-05 Thread Patrick Delaunay
- add new arch stm32mp for STM32 MPU/Soc based on Cortex A
- support for stm32mp157 SOC
- SPL is used as first boot stage loader
- using driver model for all the drivers, even in SPL
- all security feature are deactivated (ETZC and TZC)
- reused STM32 MCU drivers when it is possible

Signed-off-by: Patrick Delaunay 
---

 MAINTAINERS|   5 ++
 arch/arm/Kconfig   |  25 +-
 arch/arm/Makefile  |   1 +
 arch/arm/mach-stm32mp/Kconfig  |  41 +
 arch/arm/mach-stm32mp/Makefile |  10 +++
 arch/arm/mach-stm32mp/config.mk|  14 +++
 arch/arm/mach-stm32mp/cpu.c| 139 +
 arch/arm/mach-stm32mp/dram_init.c  |  34 +++
 arch/arm/mach-stm32mp/include/mach/gpio.h  | 115 
 arch/arm/mach-stm32mp/include/mach/stm32.h |  27 ++
 arch/arm/mach-stm32mp/spl.c|  60 +
 drivers/gpio/Kconfig   |   2 +-
 drivers/i2c/Kconfig|   2 +-
 drivers/serial/Kconfig |   6 +-
 14 files changed, 475 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/mach-stm32mp/Kconfig
 create mode 100644 arch/arm/mach-stm32mp/Makefile
 create mode 100644 arch/arm/mach-stm32mp/config.mk
 create mode 100644 arch/arm/mach-stm32mp/cpu.c
 create mode 100644 arch/arm/mach-stm32mp/dram_init.c
 create mode 100644 arch/arm/mach-stm32mp/include/mach/gpio.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/stm32.h
 create mode 100644 arch/arm/mach-stm32mp/spl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d2f8c51..9b19019 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -191,6 +191,11 @@ T: git git://git.denx.de/u-boot-stm.git
 F: arch/arm/cpu/arm926ejs/spear/
 F: arch/arm/include/asm/arch-spear/
 
+ARM STM STM32MP
+M: Patrick Delaunay 
+S: Maintained
+F: arch/arm/mach-stm32mp
+
 ARM STM STV0991
 M: Vikas Manocha 
 S: Maintained
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 77cb200..20c3132 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1130,7 +1130,7 @@ config ARCH_UNIPHIER
  (formerly, System LSI Business Division of Panasonic Corporation)
 
 config STM32
-   bool "Support STM32"
+   bool "Support STMicroelectronics STM32 MCU with cortex M"
select CPU_V7M
select DM
select DM_SERIAL
@@ -1148,6 +1148,27 @@ config ARCH_STI
  Support for STMicroelectronics STiH407/10 SoC family.
  This SoC is used on Linaro 96Board STiH410-B2260
 
+config ARCH_STM32MP
+   bool "Support STMicroelectronics STM32MP Socs with cortex A"
+   select BOARD_LATE_INIT
+   select CLK
+   select DM
+   select DM_GPIO
+   select DM_RESET
+   select DM_SERIAL
+   select OF_CONTROL
+   select OF_LIBFDT
+   select PINCTRL
+   select REGMAP
+   select SUPPORT_SPL
+   select SYSCON
+   select SYS_THUMB_BUILD
+   help
+ Support for STM32MP SoC family developed by STMicroelectronics,
+ MPUs based on ARM cortex A core
+ U-BOOT is running in DDR and SPL support is the unsecure First Stage
+ BootLoader (FSBL)
+
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select OF_CONTROL
@@ -1250,6 +1271,8 @@ source "arch/arm/mach-sti/Kconfig"
 
 source "arch/arm/mach-stm32/Kconfig"
 
+source "arch/arm/mach-stm32mp/Kconfig"
+
 source "arch/arm/mach-sunxi/Kconfig"
 
 source "arch/arm/mach-tegra/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5881fdc..4fa8b38 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -72,6 +72,7 @@ machine-$(CONFIG_ARCH_SOCFPGA)+= socfpga
 machine-$(CONFIG_ARCH_RMOBILE) += rmobile
 machine-$(CONFIG_ARCH_ROCKCHIP)+= rockchip
 machine-$(CONFIG_STM32)+= stm32
+machine-$(CONFIG_ARCH_STM32MP) += stm32mp
 machine-$(CONFIG_TEGRA)+= tegra
 machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
 machine-$(CONFIG_ARCH_ZYNQ)+= zynq
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
new file mode 100644
index 000..ab94879
--- /dev/null
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -0,0 +1,41 @@
+if ARCH_STM32MP
+
+config SPL
+   select SPL_BOARD_INIT
+   select SPL_CLK
+   select SPL_DM
+   select SPL_DM_SEQ_ALIAS
+   select SPL_FRAMEWORK
+   select SPL_GPIO_SUPPORT
+   select SPL_LIBCOMMON_SUPPORT
+   select SPL_LIBGENERIC_SUPPORT
+   select SPL_OF_CONTROL
+   select SPL_OF_TRANSLATE
+   select SPL_PINCTRL
+   select SPL_REGMAP
+   select SPL_RESET_SUPPORT
+   select SPL_SERIAL_SUPPORT
+   select SPL_SYSCON
+   imply SPL_LIBDISK_SUPPORT
+
+config SYS_SOC
+   default "stm32mp"
+
+config TARGET_STM32MP1
+ 

[U-Boot] [PATCH 14/16] clk: stm32mp1: add clock tree initialization

2018-03-05 Thread Patrick Delaunay
add binding and code for clock tree initialization from device tree

Signed-off-by: Patrick Delaunay 
---

 doc/device-tree-bindings/clock/st,stm32mp1.txt | 226 ++
 drivers/clk/clk_stm32mp1.c | 576 +
 include/dt-bindings/clock/stm32mp1-clksrc.h| 284 
 3 files changed, 1086 insertions(+)
 create mode 100644 doc/device-tree-bindings/clock/st,stm32mp1.txt
 create mode 100644 include/dt-bindings/clock/stm32mp1-clksrc.h

diff --git a/doc/device-tree-bindings/clock/st,stm32mp1.txt 
b/doc/device-tree-bindings/clock/st,stm32mp1.txt
new file mode 100644
index 000..c29d90f
--- /dev/null
+++ b/doc/device-tree-bindings/clock/st,stm32mp1.txt
@@ -0,0 +1,226 @@
+STMicroelectronics STM32MP1 clock tree initialization
+=
+
+The STM32MP clock tree initialization is based on device tree information
+for RCC IP and on fixed clocks.
+
+---
+RCC CLOCK = st,stm32mp1-rcc-clk
+---
+
+The RCC IP is both a reset and a clock controller but this documentation only
+describes the fields added for clock tree initialization which are not present
+in Linux binding.
+
+Please refer to ../mfd/st,stm32-rcc.txt for all the other properties common
+with Linux.
+
+Required properties:
+
+- compatible: Should be "st,stm32mp1-rcc-clk"
+
+- st,clksrc : The clock source in this order
+
+   for STM32MP15x: 9 clock sources are requested
+   MPU AXI MCU PLL12 PLL3 PLL4 RTC MCO1 MCO2
+
+   with value equals to RCC clock specifier as defined in
+   dt-bindings/clock/stm32mp1-clksrc.h: CLK__
+
+- st,clkdiv : The div parameters in this order
+   for STM32MP15x: 11 dividers value are requested
+   MPU AXI MCU APB1 APB2 APB3 APB4 APB5 RTC MCO1 MCO2
+
+   with DIV coding defined in RCC associated register RCC_xxxDIVR
+
+   most the case, it is:
+   0x0: not divided
+   0x1: division by 2
+   0x2: division by 4
+   0x3: division by 8
+   ...
+
+   but for RTC MCO1 MCO2, the coding is different:
+   0x0: not divided
+   0x1: division by 2
+   0x2: division by 3
+   0x3: division by 4
+   ...
+
+Optional Properties:
+- st,pll
+PLL children node for PLL1 to PLL4 : (see ref manual for details)
+with associated index 0 to 3 (st,pll@0 to st,pll@4)
+PLLx is off when the associated node is absent
+
+- Sub-nodes:
+
+   - cfg:  The parameters for PLL configuration in this order:
+   DIVM DIVN DIVP DIVQ DIVR Output
+
+   with DIV value as defined in RCC spec:
+   0x0: bypass (division by 1)
+   0x1: division by 2
+   0x2: division by 3
+   0x3: division by 4
+   ...
+
+   and Output = bitfield for each output value = 1:ON/0:OFF
+   BIT(0) => output P : DIVPEN
+   BIT(1) => output Q : DIVQEN
+   BIT(2) => output R : DIVREN
+ NB : macro PQR(p,q,r) can be used to build this value
+  with p,p,r = 0 or 1
+
+   - frac : Fractional part of the multiplication factor
+   (optional, PLL is in integer mode when absent)
+
+   - csg : Clock Spreading Generator (optional)
+   with parameters in this order:
+   MOD_PER INC_STEP SSCG_MODE
+
+   * MOD_PER: Modulation Period Adjustment
+   * INC_STEP: Modulation Depth Adjustment
+   * SSCG_MODE: Spread spectrum clock generator mode
+ you can use associated defines from stm32mp1-clksrc.h
+ * SSCG_MODE_CENTER_SPREAD = 0
+ * SSCG_MODE_DOWN_SPREAD = 1
+
+
+- st,pkcs : used to configure the peripherals kernel clock selection
+  containing a list of peripheral kernel clock source identifier as defined
+  in the file dt-bindings/clock/stm32mp1-clksrc.h
+
+  Example:
+
+   rcc: rcc@5000 {
+   compatible = "syscon", "simple-mfd";
+
+   reg = <0x5000 0x1000>;
+
+   rcc_clk: rcc-clk@5000 {
+   #clock-cells = <1>;
+   compatible = "st,stm32mp1-rcc-clk";
+
+   st,clksrc = <   CLK_MPU_PLL1P
+   CLK_AXI_PLL2P
+   CLK_MCU_HSI
+   CLK_PLL12_HSE
+   CLK_PLL3_HSE
+   CLK_PLL4_HSE
+   CLK_RTC_HSE
+   CLK_MCO1_DISABLED
+   CLK_MCO2_DISABLED
+   >;
+
+   st,clkdiv = <
+ 

[U-Boot] [PATCH 16/16] board: st: add generic board for STM32MP1 family

2018-03-05 Thread Patrick Delaunay
Add first support for STM32MP157C-ED1 board with "Basic" boot chain
1/ Boot Rom: load SPL with STM32 image header in SYSRAM
2/ SPL: power up and initialize the DDR and load U-Boot image
from SDCARD in DDR
3/ U-Boot: search and load extlinux.conf in SDCARD (DISTRO activated)

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/Kconfig |   2 +
 board/st/stm32mp1/Kconfig |  12 +++
 board/st/stm32mp1/MAINTAINERS |   7 ++
 board/st/stm32mp1/Makefile|  13 +++
 board/st/stm32mp1/README  | 191 ++
 board/st/stm32mp1/board.c |  75 +++
 board/st/stm32mp1/spl.c   |  33 +++
 board/st/stm32mp1/stm32mp1.c  |  27 ++
 configs/stm32mp15_basic_defconfig |  36 +++
 include/configs/stm32mp1.h|  97 +++
 10 files changed, 493 insertions(+)
 create mode 100644 board/st/stm32mp1/Kconfig
 create mode 100644 board/st/stm32mp1/MAINTAINERS
 create mode 100644 board/st/stm32mp1/Makefile
 create mode 100644 board/st/stm32mp1/README
 create mode 100644 board/st/stm32mp1/board.c
 create mode 100644 board/st/stm32mp1/spl.c
 create mode 100644 board/st/stm32mp1/stm32mp1.c
 create mode 100644 configs/stm32mp15_basic_defconfig
 create mode 100644 include/configs/stm32mp1.h

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index ab94879..8c755f8 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -38,4 +38,6 @@ config SYS_TEXT_BASE
when DDR driver is used:
  DDR + 1MB (0xC010)
 
+source "board/st/stm32mp1/Kconfig"
+
 endif
diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
new file mode 100644
index 000..5ab9415
--- /dev/null
+++ b/board/st/stm32mp1/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_STM32MP1
+
+config SYS_BOARD
+   default "stm32mp1"
+
+config SYS_VENDOR
+   default "st"
+
+config SYS_CONFIG_NAME
+   default "stm32mp1"
+
+endif
diff --git a/board/st/stm32mp1/MAINTAINERS b/board/st/stm32mp1/MAINTAINERS
new file mode 100644
index 000..65266bc
--- /dev/null
+++ b/board/st/stm32mp1/MAINTAINERS
@@ -0,0 +1,7 @@
+STM32MP1 BOARD
+M: Patrick Delaunay 
+S: Maintained
+F: board/st/stm32mp1
+F: include/configs/stm32mp1.h
+F: configs/stm32mp15_basic_defconfig
+F: arch/arm/dts/stm32mp157*
diff --git a/board/st/stm32mp1/Makefile b/board/st/stm32mp1/Makefile
new file mode 100644
index 000..eaf45b7
--- /dev/null
+++ b/board/st/stm32mp1/Makefile
@@ -0,0 +1,13 @@
+#
+# Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+#
+# SPDX-License-Identifier: GPL-2.0+BSD-3-Clause
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+else
+obj-y += stm32mp1.o
+endif
+
+obj-y += board.o
diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
new file mode 100644
index 000..4adc978
--- /dev/null
+++ b/board/st/stm32mp1/README
@@ -0,0 +1,191 @@
+#
+# Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+#
+# SPDX-License-Identifier: GPL-2.0+BSD-3-Clause
+#
+
+U-Boot on STMicroelectronics STM32MP1
+==
+
+1. Summary
+==
+This is a quick instruction for setup stm32mp1 boards.
+
+2. Supported devices
+
+U-Boot supports one STMP32MP1 SoCs: STM32MP157
+
+The STM32MP157 is a Cortex-A MPU aimed at various applications.
+It features:
+- Dual core Cortex-A7 application core
+- 2D/3D image composition with GPU
+- Standard memories interface support
+- Standard connectivity, widely inherited from the STM32 MCU family
+- Comprehensive security support
+
+Everything is supported in Linux but U-Boot is limited to:
+1. UART
+2. SDCard/MMC controller (SDMMC)
+
+And the necessary drivers
+1. I2C
+2. STPMU1
+3. Clock, Reset
+
+Currently the following boards are supported:
++ stm32mp157c-ed1
+
+3. Boot Sequences
+=
+
+BootRom => FSBL in SYSRAM => SSBL in DDR => OS (Linux Kernel)
+
+with FSBL = First Stage Bootloader
+ SSBL = Second Stage Bootloader
+
+One boot configuration is supported:
+
+   The "Basic" boot chain (defconfig_file : stm32mp15_basic_defconfig)
+   BootRom => FSBL = U-Boot SPL => SSBL = U-Boot
+   SPL has limited security initialisation
+   U-Boot is running in secure mode and provide a secure monitor to the kernel
+   with only PSCI support (Power State Coordination Interface defined by ARM)
+
+All the STM32MP1 board supported by U-Boot use the same generic board
+stm32mp1 which support all the bootable devices.
+
+Each board is configurated only with the associated device tree.
+
+4. Device Tree Selection
+
+
+You need to select the appropriate device tree for your board,
+the supported device trees for stm32mp157 are:
+
++ ed1: daughter board with pmic stpmu1
+  dts: stm32mp157c-ed1
+
+5. Build Procedure
+==
+
+1. Install required tools for U-Boot
+
+   + 

[U-Boot] [PATCH 12/16] reset: stm32: adapt driver for stm32mp1

2018-03-05 Thread Patrick Delaunay
- move to livetree and allow to get address to parent
- add stm32mp1 compatible for probe

Signed-off-by: Patrick Delaunay 
---

 drivers/reset/Kconfig   |  2 +-
 drivers/reset/stm32-reset.c | 36 ++--
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 3964b9e..71a786b 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -30,7 +30,7 @@ config STI_RESET
 
 config STM32_RESET
bool "Enable the STM32 reset"
-   depends on STM32
+   depends on STM32 || ARCH_STM32MP
help
  Support for reset controllers on STMicroelectronics STM32 family SoCs.
  This resset driver is compatible with STM32 F4/F7 and H7 SoCs.
diff --git a/drivers/reset/stm32-reset.c b/drivers/reset/stm32-reset.c
index b266f46..e98f34b 100644
--- a/drivers/reset/stm32-reset.c
+++ b/drivers/reset/stm32-reset.c
@@ -11,7 +11,13 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
+/* reset clear offset for STM32MP RCC */
+#define RCC_CL 0x4
+
+enum rcc_type {
+   RCC_STM32 = 0,
+   RCC_STM32MP,
+};
 
 struct stm32_reset_priv {
fdt_addr_t base;
@@ -35,7 +41,11 @@ static int stm32_reset_assert(struct reset_ctl *reset_ctl)
debug("%s: reset id = %ld bank = %d offset = %d)\n", __func__,
  reset_ctl->id, bank, offset);
 
-   setbits_le32(priv->base + bank, BIT(offset));
+   if (dev_get_driver_data(reset_ctl->dev) == RCC_STM32MP)
+   /* reset assert is done in rcc set register */
+   writel(BIT(offset), priv->base + bank);
+   else
+   setbits_le32(priv->base + bank, BIT(offset));
 
return 0;
 }
@@ -48,7 +58,11 @@ static int stm32_reset_deassert(struct reset_ctl *reset_ctl)
debug("%s: reset id = %ld bank = %d offset = %d)\n", __func__,
  reset_ctl->id, bank, offset);
 
-   clrbits_le32(priv->base + bank, BIT(offset));
+   if (dev_get_driver_data(reset_ctl->dev) == RCC_STM32MP)
+   /* reset deassert is done in rcc clr register */
+   writel(BIT(offset), priv->base + bank + RCC_CL);
+   else
+   clrbits_le32(priv->base + bank, BIT(offset));
 
return 0;
 }
@@ -64,16 +78,26 @@ static int stm32_reset_probe(struct udevice *dev)
 {
struct stm32_reset_priv *priv = dev_get_priv(dev);
 
-   priv->base = devfdt_get_addr(dev);
-   if (priv->base == FDT_ADDR_T_NONE)
-   return -EINVAL;
+   priv->base = dev_read_addr(dev);
+   if (priv->base == FDT_ADDR_T_NONE) {
+   /* for MFD, get address of parent */
+   priv->base = dev_read_addr(dev->parent);
+   if (priv->base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+   }
 
return 0;
 }
 
+static const struct udevice_id stm32_reset_ids[] = {
+   { .compatible = "st,stm32mp1-rcc-rst", .data = RCC_STM32MP },
+   { }
+};
+
 U_BOOT_DRIVER(stm32_rcc_reset) = {
.name   = "stm32_rcc_reset",
.id = UCLASS_RESET,
+   .of_match   = stm32_reset_ids,
.probe  = stm32_reset_probe,
.priv_auto_alloc_size   = sizeof(struct stm32_reset_priv),
.ops= _reset_ops,
-- 
2.7.4

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


[U-Boot] [PATCH 07/16] stm32mp: stm32f7_i2c: use calloc instead of kmalloc

2018-03-05 Thread Patrick Delaunay
Kmalloc is using memalign allocation function. It is not necessary to
align this structure so to save bytes, we move to calloc.

And kmalloc function can't be used in SPL early stage (in board_init_f())

Signed-off-by: Patrick Delaunay 
---

 drivers/i2c/stm32f7_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 8662487..81f061a 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -533,7 +533,7 @@ static int stm32_i2c_compute_solutions(struct 
stm32_i2c_setup *setup,
if (((sdadel >= sdadel_min) &&
 (sdadel <= sdadel_max)) &&
(p != p_prev)) {
-   v = kmalloc(sizeof(*v), GFP_KERNEL);
+   v = calloc(1, sizeof(*v));
if (!v)
return -ENOMEM;
 
@@ -689,7 +689,7 @@ exit:
/* Release list and memory */
list_for_each_entry_safe(v, _v, , node) {
list_del(>node);
-   kfree(v);
+   free(v);
}
 
return ret;
-- 
2.7.4

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


[U-Boot] [PATCH 09/16] ram: stm32mp1: add driver

2018-03-05 Thread Patrick Delaunay
Add driver and binding for stm32mp1 ddr controller and phy

Signed-off-by: Patrick Delaunay 
---

 MAINTAINERS  |   1 +
 arch/arm/mach-stm32mp/include/mach/ddr.h |  12 +
 doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt | 299 ++
 drivers/ram/Kconfig  |   2 +
 drivers/ram/Makefile |   1 +
 drivers/ram/stm32mp1/Kconfig |  12 +
 drivers/ram/stm32mp1/Makefile|   8 +
 drivers/ram/stm32mp1/stm32mp1_ddr.c  | 496 +++
 drivers/ram/stm32mp1/stm32mp1_ddr.h  | 210 ++
 drivers/ram/stm32mp1/stm32mp1_ddr_regs.h | 365 +
 drivers/ram/stm32mp1/stm32mp1_ram.c  | 197 +
 11 files changed, 1603 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/ddr.h
 create mode 100644 doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
 create mode 100644 drivers/ram/stm32mp1/Kconfig
 create mode 100644 drivers/ram/stm32mp1/Makefile
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ddr.c
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ddr.h
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ddr_regs.h
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ram.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9b19019..ff7b837 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -195,6 +195,7 @@ ARM STM STM32MP
 M: Patrick Delaunay 
 S: Maintained
 F: arch/arm/mach-stm32mp
+F: ram/stm32mp1
 
 ARM STM STV0991
 M: Vikas Manocha 
diff --git a/arch/arm/mach-stm32mp/include/mach/ddr.h 
b/arch/arm/mach-stm32mp/include/mach/ddr.h
new file mode 100644
index 000..b635001
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/ddr.h
@@ -0,0 +1,12 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#ifndef __MACH_STM32MP_DDR_H_
+#define __MACH_STM32MP_DDR_H_
+
+int board_ddr_power_init(void);
+
+#endif
diff --git a/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt 
b/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
new file mode 100644
index 000..3028636
--- /dev/null
+++ b/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
@@ -0,0 +1,299 @@
+ST,stm32mp1 DDR3/LPDDR2/LPDDR3 Controller (DDRCTRL and DDRPHYC)
+
+
+Required properties:
+
+- compatible   : Should be "st,stm32mp1-ddr"
+- reg  : controleur (DDRCTRL) and phy (DDRPHYC) base address
+- clocks   : controller clocks handle
+- clock-names  : associated controller clock names
+ the "ddrphyc" clock is used to check the DDR frequency
+ at phy level according the expected value in "mem-speed" field
+
+the next attributes are DDR parameters, they are generated by DDR tools
+included in STM32 Cube tool
+
+info attributes:
+
+- st,mem-name  : name for DDR configuration, simple string for information
+- st,mem-speed : DDR expected speed for the setting in MHz
+- st,mem-size  : DDR mem size in byte
+
+
+controlleur attributes:
+---
+- st,ctl-reg   : controleur values depending of the DDR type
+ (DDR3/LPDDR2/LPDDR3)
+   for STM32MP15x: 25 values are requested in this order
+   MSTR
+   MRCTRL0
+   MRCTRL1
+   DERATEEN
+   DERATEINT
+   PWRCTL
+   PWRTMG
+   HWLPCTL
+   RFSHCTL0
+   RFSHCTL3
+   CRCPARCTL0
+   ZQCTL0
+   DFITMG0
+   DFITMG1
+   DFILPCFG0
+   DFIUPD0
+   DFIUPD1
+   DFIUPD2
+   DFIPHYMSTR
+   ODTMAP
+   DBG0
+   DBG1
+   DBGCMD
+   POISONCFG
+   PCCFG
+
+- st,ctl-timing: controleur values depending of frequency and timing 
parameter
+ of DDR
+   for STM32MP15x: 12 values are requested in this order
+   RFSHTMG
+   DRAMTMG0
+   DRAMTMG1
+   DRAMTMG2
+   DRAMTMG3
+   DRAMTMG4
+   DRAMTMG5
+   DRAMTMG6
+   DRAMTMG7
+   DRAMTMG8
+   DRAMTMG14
+   ODTCFG
+
+- st,ctl-map   : controleur values depending of address mapping
+   for STM32MP15x: 9 values are requested in this order
+   ADDRMAP1
+   ADDRMAP2
+   ADDRMAP3
+   ADDRMAP4
+   ADDRMAP5
+   ADDRMAP6
+   ADDRMAP9
+   ADDRMAP10
+   ADDRMAP11
+
+- st,ctl-perf  : controleur values depending of performance and scheduling
+   for STM32MP15x: 17 values are requested in this order
+   SCHED
+ 

[U-Boot] [PATCH 11/16] pinctrl: stm32: update pincontrol for stmp32mp157

2018-03-05 Thread Patrick Delaunay
- add the 2 new compatible used by STM32MP157
"st,stm32mp157-pinctrl"
"st,stm32mp157-z-pinctrl"
- update the mask for the port

Signed-off-by: Patrick Delaunay 
---

 drivers/pinctrl/pinctrl_stm32.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
index 2066e11..31285cd 100644
--- a/drivers/pinctrl/pinctrl_stm32.c
+++ b/drivers/pinctrl/pinctrl_stm32.c
@@ -41,9 +41,10 @@ static int stm32_gpio_config(struct gpio_desc *desc,
 
return 0;
 }
+
 static int prep_gpio_dsc(struct stm32_gpio_dsc *gpio_dsc, u32 port_pin)
 {
-   gpio_dsc->port = (port_pin & 0xF000) >> 12;
+   gpio_dsc->port = (port_pin & 0x1F000) >> 12;
gpio_dsc->pin = (port_pin & 0x0F00) >> 8;
debug("%s: GPIO:port= %d, pin= %d\n", __func__, gpio_dsc->port,
  gpio_dsc->pin);
@@ -115,11 +116,13 @@ static int stm32_pinctrl_config(int offset)
return -EINVAL;
for (i = 0; i < len; i++) {
struct gpio_desc desc;
+
debug("%s: pinmux = %x\n", __func__, *(pin_mux + i));
prep_gpio_dsc(_dsc, *(pin_mux + i));
prep_gpio_ctl(_ctl, *(pin_mux + i), offset);
rv = uclass_get_device_by_seq(UCLASS_GPIO,
- gpio_dsc.port, );
+ gpio_dsc.port,
+ );
if (rv)
return rv;
desc.offset = gpio_dsc.pin;
@@ -186,6 +189,8 @@ static const struct udevice_id stm32_pinctrl_ids[] = {
{ .compatible = "st,stm32f469-pinctrl" },
{ .compatible = "st,stm32f746-pinctrl" },
{ .compatible = "st,stm32h743-pinctrl" },
+   { .compatible = "st,stm32mp157-pinctrl" },
+   { .compatible = "st,stm32mp157-z-pinctrl" },
{ }
 };
 
-- 
2.7.4

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


[U-Boot] [PATCH 15/16] dts: add device tree for STM32MP157C-ED1 board

2018-03-05 Thread Patrick Delaunay
Add minimal devicetree for STM32MP157C-ED1 board,
with only the devices to allow boot from SDCARD:
- RCC for clock and reset
- UART4 for console
- I2C and PMIC
- DDR
- SDMMC0 for SDCard

Waiting Kernel upstream for alignment.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/stm32mp15-ddr.dtsi| 155 +++
 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi   | 122 +
 arch/arm/dts/stm32mp157-u-boot.dtsi| 134 +
 arch/arm/dts/stm32mp157.dtsi   | 303 +
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   | 133 +
 arch/arm/dts/stm32mp157c-ed1.dts   | 167 
 include/dt-bindings/clock/stm32mp1-clks.h  | 243 +
 .../dt-bindings/reset-controller/stm32mp1-resets.h |  97 +++
 9 files changed, 1357 insertions(+)
 create mode 100644 arch/arm/dts/stm32mp15-ddr.dtsi
 create mode 100644 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi
 create mode 100644 arch/arm/dts/stm32mp157-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157.dtsi
 create mode 100644 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157c-ed1.dts
 create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h
 create mode 100644 include/dt-bindings/reset-controller/stm32mp1-resets.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c7695aa..95e7c06 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -496,6 +496,9 @@ dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
 
 dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
 
+dtb-$(CONFIG_TARGET_STM32MP1) += \
+   stm32mp157c-ed1.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/stm32mp15-ddr.dtsi b/arch/arm/dts/stm32mp15-ddr.dtsi
new file mode 100644
index 000..ddfa079
--- /dev/null
+++ b/arch/arm/dts/stm32mp15-ddr.dtsi
@@ -0,0 +1,155 @@
+/*
+ * Copyright : STMicroelectronics 2018
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+/ {
+   soc {
+   ddr: ddr@0x5A003000{
+   u-boot,dm-pre-reloc;
+
+   compatible = "st,stm32mp1-ddr";
+
+   reg = <0x5A003000 0x550
+  0x5A004000 0x234>;
+
+   clocks = <_clk AXIDCG>,
+<_clk DDRC1>,
+<_clk DDRC2>,
+<_clk DDRPHYC>,
+<_clk DDRCAPB>,
+<_clk DDRPHYCAPB>;
+
+   clock-names = "axidcg",
+ "ddrc1",
+ "ddrc2",
+ "ddrphyc",
+ "ddrcapb",
+ "ddrphycapb";
+
+   st,mem-name = DDR_MEM_NAME;
+   st,mem-speed = ;
+   st,mem-size = ;
+
+   st,ctl-reg = <
+   DDR_MSTR
+   DDR_MRCTRL0
+   DDR_MRCTRL1
+   DDR_DERATEEN
+   DDR_DERATEINT
+   DDR_PWRCTL
+   DDR_PWRTMG
+   DDR_HWLPCTL
+   DDR_RFSHCTL0
+   DDR_RFSHCTL3
+   DDR_CRCPARCTL0
+   DDR_ZQCTL0
+   DDR_DFITMG0
+   DDR_DFITMG1
+   DDR_DFILPCFG0
+   DDR_DFIUPD0
+   DDR_DFIUPD1
+   DDR_DFIUPD2
+   DDR_DFIPHYMSTR
+   DDR_ODTMAP
+   DDR_DBG0
+   DDR_DBG1
+   DDR_DBGCMD
+   DDR_POISONCFG
+   DDR_PCCFG
+   >;
+
+   st,ctl-timing = <
+   DDR_RFSHTMG
+   DDR_DRAMTMG0
+   DDR_DRAMTMG1
+   DDR_DRAMTMG2
+   DDR_DRAMTMG3
+   DDR_DRAMTMG4
+   DDR_DRAMTMG5
+   DDR_DRAMTMG6
+   DDR_DRAMTMG7
+   DDR_DRAMTMG8
+   DDR_DRAMTMG14
+   DDR_ODTCFG
+   >;
+
+   st,ctl-map = <
+   DDR_ADDRMAP1
+ 

  1   2   >