[U-Boot] [PATCH V2] lib: div64: sync with Linux

2017-04-09 Thread Peng Fan
Sync with Linux commit ad0376eb1483b ("Merge tag 'edac_for_4.11_2'").

Signed-off-by: Peng Fan 
Cc: Tom Rini 
---

V2:
Use `./tools/buildman/buildman  -v` to do the build,
the following 3 build fails, but not related to this patch.
x86:  +   qemu-x86_64
x86:  +   qemu-x86_efi_payload64
x86:  +   chromebook_link64

Update div64.h to sync with kernel include/asm-generic/div64.h.
There are some checkpatch warnings, I did not fix them, because files
directly copied from Linux.

 include/div64.h| 205 +++--
 include/linux/math64.h | 172 +
 lib/div64.c| 141 --
 3 files changed, 508 insertions(+), 10 deletions(-)

diff --git a/include/div64.h b/include/div64.h
index d833144..cecb232 100644
--- a/include/div64.h
+++ b/include/div64.h
@@ -4,13 +4,16 @@
  * Copyright (C) 2003 Bernardo Innocenti 
  * Based on former asm-ppc/div64.h and asm-m68knommu/div64.h
  *
+ * Optimization for constant divisors on 32-bit machines:
+ * Copyright (C) 2006-2015 Nicolas Pitre
+ *
  * The semantics of do_div() are:
  *
  * uint32_t do_div(uint64_t *n, uint32_t base)
  * {
- * uint32_t remainder = *n % base;
- * *n = *n / base;
- * return remainder;
+ * uint32_t remainder = *n % base;
+ * *n = *n / base;
+ * return remainder;
  * }
  *
  * NOTE: macro parameter n is evaluated multiple times,
@@ -18,8 +21,182 @@
  */
 
 #include 
+#include 
+
+#if BITS_PER_LONG == 64
+
+# define do_div(n,base) ({ \
+   uint32_t __base = (base);   \
+   uint32_t __rem; \
+   __rem = ((uint64_t)(n)) % __base;   \
+   (n) = ((uint64_t)(n)) / __base; \
+   __rem;  \
+ })
+
+#elif BITS_PER_LONG == 32
+
+#include 
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications which ought to be much faster. And yet only if compiling
+ * with a sufficiently recent gcc version to perform proper 64-bit constant
+ * propagation.
+ *
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+
+#ifndef __div64_const32_is_OK
+#define __div64_const32_is_OK (__GNUC__ >= 4)
+#endif
+
+#define __div64_const32(n, ___b)   \
+({ \
+   /*  \
+* Multiplication by reciprocal of b: n / b = n * (p / b) / p   \
+*  \
+* We rely on the fact that most of this code gets optimized\
+* away at compile time due to constant propagation and only\
+* a few multiplication instructions should remain. \
+* Hence this monstrous macro (static inline doesn't always \
+* do the trick here).  \
+*/ \
+   uint64_t ___res, ___x, ___t, ___m, ___n = (n);  \
+   uint32_t ___p, ___bias; \
+   \
+   /* determine MSB of b */\
+   ___p = 1 << ilog2(___b);\
+   \
+   /* compute m = ((p << 64) + b - 1) / b */   \
+   ___m = (~0ULL / ___b) * ___p;   \
+   ___m += (((~0ULL % ___b + 1) * ___p) + ___b - 1) / ___b;\
+   \
+   /* one less than the dividend with highest result */\
+   ___x = ~0ULL / ___b * ___b - 1; \
+   \
+   /* test our ___m with res = m * x / (p << 64) */\
+   ___res = ((___m & 0x) * (___x & 0x)) >> 32; \
+   ___t = ___res += (___m & 0x) * (___x >> 32);\
+   ___res += (___x & 0x) * (___m >> 32);   \
+   ___t = (___res < ___t) ? (1ULL << 32) : 0;  \
+   ___res = (___res >> 32) + ___t; \
+   ___res += (___m >> 32) * (___x >> 32);  \
+   ___res /= ___p; \
+   \
+   /* Now sanitize and optimize what we've 

Re: [U-Boot] [PATCH 1/5] rockchip: i2c: enable i2c for rk3399

2017-04-09 Thread Heiko Schocher

Hello Eric,

Am 08.04.2017 um 14:22 schrieb Eric Gao:

From: "eric.gao" 

To enable mipi display, we need to enable pmic
rk808 first for lcd3v3 power,which use i2c0 to
communicate with soc. So enable i2c0.

Signed-off-by: eric.gao 

Signed-off-by: Eric Gao 


Why you have 2 "Signed-off-by" lines?


---

  arch/arm/dts/rk3399.dtsi | 16 
  configs/evb-rk3399_defconfig |  1 +
  drivers/i2c/rk_i2c.c |  1 +
  3 files changed, 18 insertions(+)


Reviewed-by: Heiko Schocher 

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


Re: [U-Boot] [PATCH 2/3] fsl-ppa: Kconfig: Support to load PPA hdr from eMMC/SD and NAND Flash

2017-04-09 Thread Sumit Garg
> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Friday, April 07, 2017 9:41 PM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> ; Vini Pillai ; Udit
> Agarwal 
> Subject: Re: [PATCH 2/3] fsl-ppa: Kconfig: Support to load PPA hdr from
> eMMC/SD and NAND Flash
> 
> On 04/07/2017 04:42 AM, Sumit Garg wrote:
> > Add support to load PPA hdr from eMMC/SD and NAND Flash in Kconfig
> >
> > Signed-off-by: Sumit Garg 
> > Signed-off-by: Udit Agarwal 
> > Tested-by: Vinitha Pillai 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > index 9fb76f0..4c9b6ce 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > @@ -179,12 +179,22 @@ config SYS_LS_PPA_ESBC_ADDR
> > default 0x4074 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A
> > default 0x4048 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
> > default 0x580c4 if SYS_LS_PPA_FW_IN_XIP && FSL_LSCH3
> > +   default 0x70 if SYS_LS_PPA_FW_IN_MMC
> > +   default 0x70 if SYS_LS_PPA_FW_IN_NAND
> > help
> >   If the PPA header firmware locate at XIP flash, such as NOR or
> >   QSPI flash, this address is a directly memory-mapped.
> >   If it is in a serial accessed flash, such as NAND and SD
> >   card, it is a byte offset.
> >
> > +config LS_PPA_ESBC_HDR_SIZE
> > +   hex "Length of PPA ESBC header"
> > +   depends on FSL_LS_PPA && CHAIN_OF_TRUST &&
> !SYS_LS_PPA_FW_IN_XIP
> > +   default 0x2000
> > +   help
> > + Length (in bytes) of PPA ESBC header to be copied from MMC/SD or
> > + NAND to memory to validate PPA image.
> > +
> >  endmenu
> >
> 
> The order of patches seems wrong. You add two Kconfig options here but you
> use them in your patch #1.
> 
> York

I will correct the order in next version. Please let me know if you have any 
further comments.

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


[U-Boot] [bug report] Incorrect result from clk_get_by_name

2017-04-09 Thread Ziyuan

hi all,

I hit an issue about clk_get_by_name w/ fdt.
I wanna get a specified clock cell from dts via clk_get_by_name. eg:
clk_get_by_name(, "ciu-sample",..) from 'emmc: dwmmc@ff0f' on rk3288 
platform which it has four clock cell: "biu", "ciu", "ciu_drv", 
"ciu_sample".
I found that the clock list has only one element, it's "biu". I expected 
that there are four elements.


Actually, I can use clk_get_by_index instead, but I prefer clock name, 
it's more readable.


Ziyuan Xu
BR

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


[U-Boot] [PATCH 5/5] rockchip: configs: Enable mipi dsi for rk3399

2017-04-09 Thread Eric Gao
Enable mipi dsi by default for rk3399-evb board

Signed-off-by: Eric Gao 
---

 configs/evb-rk3399_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index aac6d2d..f41cbf9 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -64,3 +64,9 @@ CONFIG_PMIC_CHILDREN=y
 CONFIG_SPL_PMIC_CHILDREN=y
 CONFIG_PMIC_RK808=y
 CONFIG_REGULATOR_RK808=y
+CONFIG_DM_VIDEO=y
+CONFIG_DM_PWM=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_MIPI=y
-- 
1.9.1


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


[U-Boot] [PATCH 4/5] rockchip: dts: Add mipi dsi support for rk3399

2017-04-09 Thread Eric Gao
Add dts config for mipi display, include vop,
mipi controller, panel, backlight.And Enable rk808
for lcd_3v3 in another patch.

Signed-off-by: Eric Gao 
---

 arch/arm/dts/rk3399-evb.dts | 84 +
 arch/arm/dts/rk3399.dtsi| 72 ++
 2 files changed, 156 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index 7bf805a..709d66d 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -59,6 +59,15 @@
gpio = < 25 GPIO_ACTIVE_HIGH>;
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   status = "disabled";
+   };
+
+   panel:panel {
+   compatible = "simple-panel";
+   status = "disabled";
+   };
 };
 
 _phy {
@@ -139,6 +148,7 @@
status = "okay";
 
vcc12-supply = <_sys>;
+
regulators {
vcc33_lcd: SWITCH_REG2 {
regulator-always-on;
@@ -149,6 +159,80 @@
};
 };
 
+ {
+   power-supply = <>;
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+   104 105 106 107 108 109 110 111
+   112 113 114 115 116 117 118 119
+   120 121 122 123 124 125 126 127
+   128 129 130 131 132 133 134 135
+   136 137 138 139 140 141 142 143
+   144 145 146 147 148 149 150 151
+   152 153 154 155 156 157 158 159
+   160 161 162 163 164 165 166 167
+   168 169 170 171 172 173 174 175
+   176 177 178 179 180 181 182 183
+   184 185 186 187 188 189 190 191
+   192 193 194 195 196 197 198 199
+   200 201 202 203 204 205 206 207
+   208 209 210 211 212 213 214 215
+   216 217 218 219 220 221 222 223
+   224 225 226 227 228 229 230 231
+   232 233 234 235 236 237 238 239
+   240 241 242 243 244 245 246 247
+   248 249 250 251 252 253 254 255>;
+   default-brightness-level = <200>;
+   pwms = < 0 25000 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin>;
+   pwm-delay-us = <1>;
+   status = "okay";
+   };
+
+ {
+   power-supply = <_lcd>;
+   backlight = <>;
+   /*enable-gpios = < 18 GPIO_ACTIVE_HIGH>;*/
+   status = "okay";
+};
+
+_dsi {
+   status = "okay";
+   rockchip,panel = <>;
+   display-timings {
+   timing0 {
+   bits-per-pixel = <24>;
+   clock-frequency = <16000>;
+   hfront-porch = <120>;
+   hsync-len = <20>;
+   hback-porch = <21>;
+   hactive = <1200>;
+   vfront-porch = <21>;
+   vsync-len = <3>;
+   vback-porch = <18>;
+   vactive = <1920>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <1>;
+   pixelclk-active = <0>;
+   };
+   };
+};
+
  {
pmic {
pmic_int_l: pmic-int-l {
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 93e3bf4..c82e674 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -667,6 +667,78 @@
status = "disabled";
};
 
+   vopl: vop@ff8f {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3399-vop-lit";
+   reg = <0x0 0xff8f 0x0 0x3efc>;
+   interrupts = ;
+   clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_A_VOP1>, < SRST_H_VOP1>, < 
SRST_D_VOP1>;
+   reset-names = "axi", "ahb", "dclk";
+   status = "okay";
+   vopl_out: port {
+   #address-cells = <1>;
+

[U-Boot] [PATCH 3/5] rockchip: video: Add mipi dsi driver for rk3399

2017-04-09 Thread Eric Gao
Add mipi dsi driver for rk chip, To enable this
you need to enable DM, DM_VIDEO, DM_ROCKCHIP_VIDEO,
DISPLAY_MIPI in menuconfig. And enable rk808,and it's
corresponding i2c.

Signed-off-by: Eric Gao 
---

 arch/arm/include/asm/arch-rockchip/cru_rk3399.h  |   1 +
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h  |  25 ++
 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 189 +
 arch/arm/include/asm/arch-rockchip/vop_rk3288.h  |   1 +
 drivers/video/Kconfig|   2 +
 drivers/video/rockchip/Kconfig   |  47 +++
 drivers/video/rockchip/Makefile  |   6 +-
 drivers/video/rockchip/rk_mipi.c | 465 +++
 drivers/video/rockchip/rk_vop.c  |  39 +-
 9 files changed, 768 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
 create mode 100644 drivers/video/rockchip/Kconfig
 create mode 100644 drivers/video/rockchip/rk_mipi.c

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
index cf830d0..e9e5810 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
@@ -70,6 +70,7 @@ struct rk3399_cru {
 };
 check_member(rk3399_cru, sdio1_con[1], 0x594);
 #define MHz100
+#define MHZ100
 #define KHz1000
 #define OSC_HZ (24*MHz)
 #define APLL_HZ(600*MHz)
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index 62d8496..2bf58da 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -399,6 +399,31 @@ enum {
GRF_UART_DBG_SEL_MASK   = 3 << GRF_UART_DBG_SEL_SHIFT,
GRF_UART_DBG_SEL_C  = 2,
 
+   /* GRF_SOC_CON20 */
+   GRF_DSI0_VOP_SEL_SHIFT  = 0,
+   GRF_DSI0_VOP_SEL_MASK   = 1 << GRF_DSI0_VOP_SEL_SHIFT,
+   GRF_DSI0_VOP_SEL_B  = 0,
+   GRF_DSI0_VOP_SEL_L,
+
+   /* GRF_SOC_CON22 */
+   GRF_DPHY_TX0_RXMODE_SHIFT = 0,
+   GRF_DPHY_TX0_RXMODE_MASK =
+   0xf << GRF_DPHY_TX0_RXMODE_SHIFT,
+   GRF_DPHY_TX0_RXMODE_EN = 0xb,
+   GRF_DPHY_TX0_RXMODE_DIS = 0,
+
+   GRF_DPHY_TX0_TXSTOPMODE_SHIFT = 4,
+   GRF_DPHY_TX0_TXSTOPMODE_MASK =
+   0xf0 << GRF_DPHY_TX0_TXSTOPMODE_SHIFT,
+   GRF_DPHY_TX0_TXSTOPMODE_EN = 0xc,
+   GRF_DPHY_TX0_TXSTOPMODE_DIS = 0,
+
+   GRF_DPHY_TX0_TURNREQUEST_SHIFT = 12,
+   GRF_DPHY_TX0_TURNREQUEST_MASK =
+   0xf000 << GRF_DPHY_TX0_TURNREQUEST_SHIFT,
+   GRF_DPHY_TX0_TURNREQUEST_EN = 0x1,
+   GRF_DPHY_TX0_TURNREQUEST_DIS = 0,
+
/*  PMUGRF_GPIO0A_IOMUX */
PMUGRF_GPIO0A6_SEL_SHIFT= 12,
PMUGRF_GPIO0A6_SEL_MASK = 3 << PMUGRF_GPIO0A6_SEL_SHIFT,
diff --git a/arch/arm/include/asm/arch-rockchip/mipi_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
new file mode 100644
index 000..9a1fffb
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2017-2025 Fuzhou Rockchip Electronics Co., Ltd
+ * author: eric@rock-chips.com
+ * create date: 2017-03-31
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef RK33_MIPI_DSI_H
+#define RK33_MIPI_DSI_H
+
+/*
+ * All these mipi controller register declaration provide
+ * reg address offset, bits width, bit offset for a
+ * specified register bits. With these message, we can
+ * set or clear every bits individually for a 32bit width
+ * register. We use DSI_HOST_BITS macro definition to
+ * combinat these message using the following format:
+ * val(32bit) = addr(16bit) | width(8bit) | offest(8bit)
+ * for example:
+ * #define SHUTDOWNZ   DSI_HOST_BITS(0X004, 1, 0)
+ * means SHUTDOWNZ is a signal reg bit with bit offset
+ * qual 0,and it's reg addr offset is 0x004.The conbinat
+ * result  = (0x004 << 16) | (1 << 8) | 0
+ */
+#define DSI_HOST_BITS(addr, bits, bit_offset) \
+   ((addr<<16) | (bits<<8) | (bit_offset))
+
+/* DWC_DSI_VERSION_0X3133302A */
+#define VERSIONDSI_HOST_BITS(0X000, 32, 0)
+#define SHUTDOWNZ  DSI_HOST_BITS(0X004, 1, 0)
+#define TO_CLK_DIVISIONDSI_HOST_BITS(0X008, 8, 8)
+#define TX_ESC_CLK_DIVISIONDSI_HOST_BITS(0X008, 8, 0)
+#define DPI_VCID   DSI_HOST_BITS(0X00C, 2, 0)
+#define EN18_LOOSELY   DSI_HOST_BITS(0X010, 1, 8)
+#define DPI_COLOR_CODING   DSI_HOST_BITS(0X010, 4, 0)
+#define COLORM_ACTIVE_LOW  DSI_HOST_BITS(0X014, 1, 4)
+#define SHUTD_ACTIVE_LOW   DSI_HOST_BITS(0X014, 1, 3)
+#define HSYNC_ACTIVE_LOW   DSI_HOST_BITS(0X014, 1, 2)
+#define VSYNC_ACTIVE_LOW   DSI_HOST_BITS(0X014, 1, 1)
+#define DATAEN_ACTIVE_LOW  DSI_HOST_BITS(0X014, 1, 0)
+#define OUTVACT_LPCMD_TIME DSI_HOST_BITS(0X018, 8, 16)
+#define 

[U-Boot] [PATCH 2/5] rockchip: pmic: Enable RK808 for rk3399 evb

2017-04-09 Thread Eric Gao
For using mipi display, we need to enable lcd3v3
which supplied by rk808,so enable rk808 first.

Signed-off-by: Eric Gao 
---

 arch/arm/dts/rk3399-evb.dts  | 39 +++
 configs/evb-rk3399_defconfig |  5 +
 2 files changed, 44 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index a959989..7bf805a 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -30,6 +30,13 @@
status = "okay";
};
 
+   vccsys: vccsys {
+   compatible = "regulator-fixed";
+   regulator-name = "vccsys";
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
vcc3v3_sys: vcc3v3-sys {
compatible = "regulator-fixed";
regulator-name = "vcc3v3_sys";
@@ -51,6 +58,7 @@
regulator-name = "vcc5v0_host";
gpio = < 25 GPIO_ACTIVE_HIGH>;
};
+
 };
 
 _phy {
@@ -110,6 +118,37 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   clock-frequency = <40>;
+   i2c-scl-falling-time-ns = <50>;
+   i2c-scl-rising-time-ns = <100>;
+   u-boot,dm-pre-reloc;
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   clock-output-names = "xin32k", "wifibt_32kin";
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>;
+   reg = <0x1b>;
+   rockchip,system-power-controller;
+   #clock-cells = <1>;
+   u-boot,dm-pre-reloc;
+   status = "okay";
+
+   vcc12-supply = <_sys>;
+   regulators {
+   vcc33_lcd: SWITCH_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-name = "vcc33_lcd";
+   };
+   };
+   };
+};
+
  {
pmic {
pmic_int_l: pmic-int-l {
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 2e2f9a8..aac6d2d 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -59,3 +59,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
 CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_CHILDREN=y
+CONFIG_SPL_PMIC_CHILDREN=y
+CONFIG_PMIC_RK808=y
+CONFIG_REGULATOR_RK808=y
-- 
1.9.1


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


[U-Boot] [PATCH 1/5] rockchip: i2c: Enable i2c for rk3399

2017-04-09 Thread Eric Gao
To enable mipi display, we need to enable pmic
rk808 first for lcd3v3 power,which use i2c0 to
communicate with soc. So enable i2c0.

Signed-off-by: Eric Gao 

---

 arch/arm/dts/rk3399.dtsi | 16 
 configs/evb-rk3399_defconfig |  1 +
 drivers/i2c/rk_i2c.c |  1 +
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 456fdb6..93e3bf4 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -26,6 +26,7 @@
serial4 = 
mmc0 = 
mmc1 = 
+   i2c0 = 
};
 
cpus {
@@ -651,6 +652,21 @@
status = "disabled";
};
 
+   i2c0: i2c@ff3c {
+   compatible = "rockchip,rk3399-i2c";
+   reg = <0x0 0xff3c 0x0 0x1000>;
+   assigned-clocks = < SCLK_I2C0_PMU>;
+   assigned-clock-rates = <2>;
+   clocks = < SCLK_I2C0_PMU>, < PCLK_I2C0_PMU>;
+   clock-names = "i2c", "pclk";
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_xfer>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pinctrl";
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index bedc1fd..2e2f9a8 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -58,3 +58,4 @@ CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
+CONFIG_SYS_I2C_ROCKCHIP=y
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 7c701cb..a4c8c2ba 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -381,6 +381,7 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
 
 static const struct udevice_id rockchip_i2c_ids[] = {
{ .compatible = "rockchip,rk3288-i2c" },
+   { .compatible = "rockchip,rk3399-i2c" },
{ }
 };
 
-- 
1.9.1


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


[U-Boot] [PATCH 0/5]

2017-04-09 Thread Eric Gao
This serials patches add mipi dsi support for rk3399. Except the
basic mipi driver, we need also enable pmic rk808 for lcd power and
enable i2c for rk808 communication. what's more, the needed clk and
pwm for backlight is init in spl stage, make sure spl work first.



Eric Gao (5):
  rockchip: i2c: Enable i2c for rk3399
  rockchip: pmic: Enable RK808 for rk3399 evb
  rockchip: video: Add mipi dsi driver for rk3399
  rockchip: dts: Add mipi dsi support for rk3399
  rockchip: configs: Enable mipi dsi for rk3399

 arch/arm/dts/rk3399-evb.dts  | 123 ++
 arch/arm/dts/rk3399.dtsi |  88 +
 arch/arm/include/asm/arch-rockchip/cru_rk3399.h  |   1 +
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h  |  25 ++
 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 189 +
 arch/arm/include/asm/arch-rockchip/vop_rk3288.h  |   1 +
 configs/evb-rk3399_defconfig |  12 +
 drivers/i2c/rk_i2c.c |   1 +
 drivers/video/Kconfig|   2 +
 drivers/video/rockchip/Kconfig   |  47 +++
 drivers/video/rockchip/Makefile  |   6 +-
 drivers/video/rockchip/rk_mipi.c | 465 +++
 drivers/video/rockchip/rk_vop.c  |  39 +-
 13 files changed, 992 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
 create mode 100644 drivers/video/rockchip/Kconfig
 create mode 100644 drivers/video/rockchip/rk_mipi.c

-- 
1.9.1


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


Re: [U-Boot] [PATCH] rockchip: rk3399: defconfig: add CONFIG_OF_EMBED support

2017-04-09 Thread Kever Yang

Hi Simon,


On 04/10/2017 03:28 AM, Simon Glass wrote:

Hi Kever,

On 7 April 2017 at 04:35, Kever Yang  wrote:

Need to enablt CONFIG_OF_EMBED if we use separate uboot and dtb
in FIT image for SPL loading.


Can you please explain that a bit more? We shouldn't OF_EMBED in
production code, only for debug/test.


When I test with latest code for SPL loading FIT which u-boot and dtb
are separate, the U-Boot code can not find its dtb file.
This issue is not happen when I test with code older than v2017.03,
and with CONFIG_OF_EMBED, U-Boot can find dtb with latest code.

Maybe I need to do some debugging for root cause, please ignore this
patch if this is not correct.

Thanks,
- Kever



Run make savedefconfig to make the options order correct.

Signed-off-by: Kever Yang 
---

  configs/evb-rk3399_defconfig | 43 ---
  1 file changed, 20 insertions(+), 23 deletions(-)

Regards,
Simon




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


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

2017-04-09 Thread Bin Meng
Hi Tom,

The following changes since commit 04735a8fc45ba7c9f5b17d4837a0c649087b29e1:

  Merge branch 'master' of git://git.denx.de/u-boot-samsung
(2017-04-08 10:20:26 -0400)

are available in the git repository at:

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

for you to fetch changes up to ca0d29e4f06095fd39f3125aef8f427aa1728ee5:

  x86: Introduce minimal PMU driver for Intel MID platforms
(2017-04-10 10:02:03 +0800)


Andy Shevchenko (3):
  x86: Remove unused option
  serial: Add serial driver for Intel MID
  x86: Introduce minimal PMU driver for Intel MID platforms

Bin Meng (2):
  dm: rtc: Add 16-bit read/write support
  tools: binman: Add missing filenames for various x86 rom tests

Felipe Balbi (1):
  x86: Add SCU IPC driver for Intel MID platforms

Stefan Roese (4):
  x86: Kconfig: Add options to configure the descriptor.bin /
me.bin filenames
  x86: Add file names from Kconfig in descriptor/intel-me nodes in
u-boot.dtsi
  binman: Remove hard-coded file name for x86 flash-descriptor & intel-me
  x86: bootm: Fix FIT image booting on x86

 arch/x86/Kconfig|  18 +
 arch/x86/dts/u-boot.dtsi|   2 ++
 arch/x86/include/asm/cpu.h  |   2 ++
 arch/x86/include/asm/pmu.h  |  11 
 arch/x86/include/asm/scu.h  |  28 
 arch/x86/lib/Makefile   |   2 ++
 arch/x86/lib/bootm.c|   2 +-
 arch/x86/lib/pmu.c  | 117
+++
 arch/x86/lib/scu.c  | 168
+++
 drivers/rtc/rtc-uclass.c|  30 ++
 drivers/serial/Kconfig  |   9 +++
 drivers/serial/Makefile |   1 +
 drivers/serial/serial_intel_mid.c   |  69
+
 include/configs/x86-common.h|   1 -
 include/rtc.h   |  20 +++
 scripts/config_whitelist.txt|   1 -
 tools/binman/etype/intel_descriptor.py  |   3 ---
 tools/binman/etype/intel_me.py  |   3 ---
 tools/binman/test/30_x86-rom-me-no-desc.dts |   1 +
 tools/binman/test/31_x86-rom-me.dts |   2 ++
 tools/binman/test/32_intel-vga.dts  |   1 +
 tools/binman/test/42_intel-fsp.dts  |   1 +
 tools/binman/test/43_intel-cmc.dts  |   1 +
 23 files changed, 484 insertions(+), 9 deletions(-)
 create mode 100644 arch/x86/include/asm/pmu.h
 create mode 100644 arch/x86/include/asm/scu.h
 create mode 100644 arch/x86/lib/pmu.c
 create mode 100644 arch/x86/lib/scu.c
 create mode 100644 drivers/serial/serial_intel_mid.c

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


[U-Boot] [PATCH 1/5] rockchip: i2c: Enable i2c for rk3399

2017-04-09 Thread Eric Gao
To enable mipi display, we need to enable pmic
rk808 first for lcd3v3 power,which use i2c0 to
communicate with soc. So enable i2c0.

Signed-off-by: Eric Gao 

---

 arch/arm/dts/rk3399.dtsi | 16 
 configs/evb-rk3399_defconfig |  1 +
 drivers/i2c/rk_i2c.c |  1 +
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 456fdb6..93e3bf4 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -26,6 +26,7 @@
serial4 = 
mmc0 = 
mmc1 = 
+   i2c0 = 
};
 
cpus {
@@ -651,6 +652,21 @@
status = "disabled";
};
 
+   i2c0: i2c@ff3c {
+   compatible = "rockchip,rk3399-i2c";
+   reg = <0x0 0xff3c 0x0 0x1000>;
+   assigned-clocks = < SCLK_I2C0_PMU>;
+   assigned-clock-rates = <2>;
+   clocks = < SCLK_I2C0_PMU>, < PCLK_I2C0_PMU>;
+   clock-names = "i2c", "pclk";
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_xfer>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pinctrl";
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index bedc1fd..2e2f9a8 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -58,3 +58,4 @@ CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
+CONFIG_SYS_I2C_ROCKCHIP=y
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 7c701cb..a4c8c2ba 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -381,6 +381,7 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
 
 static const struct udevice_id rockchip_i2c_ids[] = {
{ .compatible = "rockchip,rk3288-i2c" },
+   { .compatible = "rockchip,rk3399-i2c" },
{ }
 };
 
-- 
1.9.1


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


[U-Boot] [PATCH 0/5]

2017-04-09 Thread Eric Gao
This serials patches add mipi dsi support for rk3399. Except the
basic mipi driver, we need also enable pmic rk808 for lcd power and
enable i2c for rk808 communication. what's more, the needed clk and
pwm for backlight is init in spl stage, make sure spl work first.



Eric Gao (5):
  rockchip: i2c: Enable i2c for rk3399
  rockchip: pmic: Enable RK808 for rk3399 evb
  rockchip: video: Add mipi dsi driver for rk3399
  rockchip: dts: Add mipi dsi support for rk3399
  rockchip: configs: Enable mipi dsi for rk3399

 arch/arm/dts/rk3399-evb.dts  | 123 ++
 arch/arm/dts/rk3399.dtsi |  88 +
 arch/arm/include/asm/arch-rockchip/cru_rk3399.h  |   1 +
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h  |  25 ++
 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 189 +
 arch/arm/include/asm/arch-rockchip/vop_rk3288.h  |   1 +
 configs/evb-rk3399_defconfig |  12 +
 drivers/i2c/rk_i2c.c |   1 +
 drivers/video/Kconfig|   2 +
 drivers/video/rockchip/Kconfig   |  47 +++
 drivers/video/rockchip/Makefile  |   6 +-
 drivers/video/rockchip/rk_mipi.c | 465 +++
 drivers/video/rockchip/rk_vop.c  |  39 +-
 13 files changed, 992 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
 create mode 100644 drivers/video/rockchip/Kconfig
 create mode 100644 drivers/video/rockchip/rk_mipi.c

-- 
1.9.1


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


Re: [U-Boot] [PATCH v3 2/2] x86: Introduce minimal PMU driver for Intel MID platforms

2017-04-09 Thread Bin Meng
On Thu, Apr 6, 2017 at 11:44 AM, Simon Glass  wrote:
> Hi Andy,
>
> On 1 April 2017 at 07:21, Andy Shevchenko
>  wrote:
>> This simple PMU driver allows to tyrn power on and off for selected
>> devices. In particularly Intel Tangier needs to power on SDHCI
>> controllers in order to access to them during board initialization.
>>
>> In the future it might be expanded to cover other Intel MID platforms,
>> that's why it's located under arch/x86/lib and called pmu.c.
>>
>> Signed-off-by: Felipe Balbi 
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  arch/x86/include/asm/cpu.h |   1 +
>>  arch/x86/include/asm/pmu.h |  11 +
>>  arch/x86/lib/Makefile  |   1 +
>>  arch/x86/lib/pmu.c | 117 
>> +
>>  4 files changed, 130 insertions(+)
>>  create mode 100644 arch/x86/include/asm/pmu.h
>>  create mode 100644 arch/x86/lib/pmu.c
>
> Reviewed-by: Simon Glass 
>
> Have you considered making this a PMIC driver? Then you could avoid
> exporting the function. Also I see that we need to do that sometimes
> with Intel platforms.

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3] serial: Add serial driver for Intel MID

2017-04-09 Thread Bin Meng
On Sat, Apr 1, 2017 at 12:22 PM, Simon Glass  wrote:
> +Bin
>
> Hi,
>
> On 26 March 2017 at 05:48, Andy Shevchenko
>  wrote:
>> On Mon, 2017-03-13 at 16:09 +0200, Andy Shevchenko wrote:
>>> On Fri, Mar 3, 2017 at 12:31 PM, Kever Yang >> > wrote:
>>> > On 02/28/2017 08:04 PM, Andy Shevchenko wrote:
>>> > >
>>> > > Add a specific serial driver for Intel MID platforms.
>>> > >
>>> > > It has special fractional divider which can be programmed via
>>> > > UART_PS,
>>> > > UART_MUL, and UART_DIV registers.
>>> > >
>>> > > The UART clock is calculated as
>>> > >
>>> > > UART clock = XTAL * UART_MUL / UART_DIV
>>> > >
>>> > > The baudrate is calculated as
>>> > >
>>> > > baud rate = UART clock / UART_PS / DLAB
>>> > >
>>> > > Initialize fractional divider correctly for Intel Edison platform.
>>> > >
>>> > > For backward compatibility we have to set initial DLAB value to 16
>>> > > and speed to 115200 baud, where initial frequency is 29491200Hz,
>>> > > and
>>> > > XTAL frequency is 38.4MHz.
>>> > Reviewed-by: Kever Yang 
>>>
>>> Thanks!
>>>
>>> Tom et all, is it forgotten?
>>
>> Any update on this? Should I do something about?
>
> Probably Bin can apply it - it's a good idea to cc him on x86 stuff.
> If not let me know and I can pull it in via DM.
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] video: Fix crash when scroll screen

2017-04-09 Thread Eric Gao
After enable log printing to lcd,when
the screen start scroll,system crash,
log is shown as bellow.

"Synchronous Abort" handler, esr 0x9645
"Synchronous Abort" handler, esr 0x9645

Checking the source code, we found that the
variate "pixels" get a wrong value.

int pixels = VIDEO_FONT_HEIGHT * vid_priv->line_length;

"pixels" here means the value of pixels for
a character,rather than the byte for a
character. so the variate "pixels" is 4 times
bigger than it's exact value. which will cause
the memory overflow when the cpu run the
following code.

for (i = 0; i < pixels; i++)
*dst++ = clr; <<

Signed-off-by: Eric Gao 

---

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

diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c
index 89a55dd..b627d48 100644
--- a/drivers/video/console_normal.c
+++ b/drivers/video/console_normal.c
@@ -18,7 +18,7 @@ static int console_normal_set_row(struct udevice *dev, uint 
row, int clr)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
void *line;
-   int pixels = VIDEO_FONT_HEIGHT * vid_priv->line_length;
+   int pixels = VIDEO_FONT_HEIGHT * vid_priv->xsize;
int i;
 
line = vid_priv->fb + row * VIDEO_FONT_HEIGHT * vid_priv->line_length;
-- 
1.9.1


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


Re: [U-Boot] [PATCH v3 1/2] x86: Add SCU IPC driver for Intel MID platforms

2017-04-09 Thread Bin Meng
On Thu, Apr 6, 2017 at 11:44 AM, Simon Glass  wrote:
> Hi Andy,
>
> On 1 April 2017 at 07:21, Andy Shevchenko
>  wrote:
>> From: Felipe Balbi 
>>
>> Intel MID platforms have few microcontrollers inside SoC, one of them
>> is so called System Controller Unit (SCU).
>>
>> Here is the driver to communicate with microcontroller.
>>
>> Signed-off-by: Vincent Tinelli 
>> Signed-off-by: Felipe Balbi 
>> Signed-off-by: Andy Shevchenko 
>
> Acked-by: Simon Glass 
>
> If you can it is better to put the change log in each patch. Patman can help.
>
> BTW if you end up resending, please use lower-case hex.
>

Fixed the lower-case hex, and one checkpatch warning:

WARNING: line over 80 characters
#82: FILE: arch/x86/include/asm/scu.h:15:
+#define IPCMSG_WATCHDOG_TIMER  0xF8/* Set Kernel Watchdog
Threshold */

and, applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] tools: binman: Add missing filenames for various x86 rom tests

2017-04-09 Thread Bin Meng
On Mon, Apr 10, 2017 at 3:27 AM, Simon Glass  wrote:
> On 4 April 2017 at 22:17, Bin Meng  wrote:
>> With recent changes, some x86-specific rom tests of binman fail to
>> run. Fix it by adding missing filenames in corresponding entries.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  tools/binman/test/30_x86-rom-me-no-desc.dts | 1 +
>>  tools/binman/test/31_x86-rom-me.dts | 2 ++
>>  tools/binman/test/32_intel-vga.dts  | 1 +
>>  tools/binman/test/42_intel-fsp.dts  | 1 +
>>  tools/binman/test/43_intel-cmc.dts  | 1 +
>>  5 files changed, 6 insertions(+)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] rockchip: rk3399: Add missing sentinel in syscon

2017-04-09 Thread Eric Gao
when enable PMIC rk808,the system will halt at very
 early stage,log is shown as bellow.

INFO:plat_rockchip_pmu_init(1211): pd status 3e
INFO:BL31: Initializing runtime services
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x20
INFO:SPSR = 0x3c9
time 44561b, 0 (<compatible) { <<--
if (!strcmp(of_match->compatible, compat)) {
*of_idp = of_match;
return 0;
}
of_match++;
}

Signed-off-by: Eric Gao 
---

 arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c 
b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
index d32985b..74d4552 100644
--- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
@@ -14,6 +14,7 @@ static const struct udevice_id rk3399_syscon_ids[] = {
{ .compatible = "rockchip,rk3399-pmugrf", .data = 
ROCKCHIP_SYSCON_PMUGRF },
{ .compatible = "rockchip,rk3399-pmusgrf", .data = 
ROCKCHIP_SYSCON_PMUSGRF },
{ .compatible = "rockchip,rk3399-cic", .data = ROCKCHIP_SYSCON_CIC },
+   { }
 };
 
 U_BOOT_DRIVER(syscon_rk3399) = {
-- 
1.9.1


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


Re: [U-Boot] [U-Boot, v3] Makefile: Fix linking with modern binutils

2017-04-09 Thread Vagrant Cascadian
On 2017-04-09, Andreas Färber  wrote:
> From: Joel Stanley 
>
> Since Binutils 1a9ccd70f9a7[1] u-boot will not link targets that set
> CONFIG_SYS_TEXT_BASE=0 with the following error:
>
>   LD  u-boot
> arm-linux-gnueabi-ld.bfd: u-boot: Not enough room for program headers, try
>  linking with -N
> arm-linux-gnueabi-ld.bfd: final link failed: Bad value
>
> The issue can be reproduced with the bad binutils and the rock2_defconfig
> target.
>
> This issue was also encountered by the powerpc kernel[2], with the fix
> being to pass --no-dynamic-linker for linkers newer than 2.26 when this
> flag was introduced. The option tells ld that the PIE or shared lib does
> not need loaded program headers.
>
> Ubuntu Zesty's Binutils 2.27.51.20161202 hits this error.

Also been hitting this with Debian's cross-toolchains (currently
binutils 2.28-3), but only when cross-building the firefly-rk3288 with
binutils-arm-linux-gnueabihf target. Other targets build fine...

This patch does appear to fix or workaround the issue for me, though,
thanks!

live well,
  vagrant


> [1] 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=1a9ccd70f9a7
> [2] 
> https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=next=ff45000fcb56b5b0f1a14a865d3541746d838a0a
>
> Signed-off-by: Joel Stanley 
> [AF: Apply to LDFLAGS_$(SPL_BIN) as well, suggested by Tom Rini]
> Signed-off-by: Andreas Färber 
> ---
>  Makefile | 4 
>  scripts/Makefile.spl | 4 
>  2 files changed, 8 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index ca7d60d..09b597d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -805,6 +805,10 @@ ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
>  endif
>  
>  LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> +
> +# Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> +LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> +
>  ifneq ($(CONFIG_SYS_TEXT_BASE),)
>  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
>  endif
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 760acee..eb24292 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -291,6 +291,10 @@ $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE
>   $(call if_changed,objcopy)
>  
>  LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
> +
> +# Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> +LDFLAGS_$(SPL_BIN) += $(call ld-option, --no-dynamic-linker)
> +
>  ifneq ($(CONFIG_SPL_TEXT_BASE),)
>  LDFLAGS_$(SPL_BIN) += -Ttext $(CONFIG_SPL_TEXT_BASE)
>  endif


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


[U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86

2017-04-09 Thread Simon Glass
This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86
since SCSI is broken with this setup.

Signed-off-by: Simon Glass 
---

 include/configs/x86-common.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
index f7796cf63f..67f19d4121 100644
--- a/include/configs/x86-common.h
+++ b/include/configs/x86-common.h
@@ -30,7 +30,7 @@
 #define CONFIG_SYS_BOOTM_LEN   (16 << 20)
 
 /* SATA AHCI storage */
-
+#if 0
 #define CONFIG_SCSI_AHCI
 #ifdef CONFIG_SCSI_AHCI
 #define CONFIG_LIBATA
@@ -42,6 +42,7 @@
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
 CONFIG_SYS_SCSI_MAX_LUN)
 #endif
+#endif
 
 /* Generic TPM interfaced through LPC bus */
 #define CONFIG_TPM_TIS_BASE_ADDRESS0xfed4
@@ -82,8 +83,9 @@
 #define CONFIG_CMD_IRQ
 #define CONFIG_CMD_PCI
 #define CONFIG_CMD_GETTIME
+/*
 #define CONFIG_SCSI
-
+*/
 #define CONFIG_CMD_ZBOOT
 
 #define CONFIG_BOOTARGS\
-- 
2.12.2.715.g7642488e1d-goog

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


[U-Boot] [PATCH 2/2] x86: Convert MMC to driver model

2017-04-09 Thread Simon Glass
Convert the pci_mmc driver over to driver model and migrate all x86 boards
that use it.

Signed-off-by: Simon Glass 
---

 arch/Kconfig   |  1 +
 arch/x86/cpu/baytrail/valleyview.c | 12 --
 arch/x86/cpu/quark/quark.c | 10 -
 arch/x86/cpu/queensbay/Makefile|  2 +-
 arch/x86/cpu/queensbay/topcliff.c  | 20 -
 drivers/mmc/pci_mmc.c  | 86 ++
 include/mmc.h  | 12 --
 7 files changed, 62 insertions(+), 81 deletions(-)
 delete mode 100644 arch/x86/cpu/queensbay/topcliff.c

diff --git a/arch/Kconfig b/arch/Kconfig
index 160accdbcb..97aa7d9fc1 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -84,6 +84,7 @@ config X86
select DM_GPIO
select DM_SPI
select DM_SPI_FLASH
+   select DM_MMC if MMC
 
 config XTENSA
bool "Xtensa architecture"
diff --git a/arch/x86/cpu/baytrail/valleyview.c 
b/arch/x86/cpu/baytrail/valleyview.c
index 87ba849c1c..c58f6a86a8 100644
--- a/arch/x86/cpu/baytrail/valleyview.c
+++ b/arch/x86/cpu/baytrail/valleyview.c
@@ -11,18 +11,6 @@
 #include 
 #include 
 
-static struct pci_device_id mmc_supported[] = {
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SDIO },
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SD },
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_EMMC2 },
-   {},
-};
-
-int cpu_mmc_init(bd_t *bis)
-{
-   return pci_mmc_init("ValleyView SDHCI", mmc_supported);
-}
-
 #ifndef CONFIG_EFI_APP
 int arch_cpu_init(void)
 {
diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index 0c2cea4ee9..c36a5892d5 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -16,11 +16,6 @@
 #include 
 #include 
 
-static struct pci_device_id mmc_supported[] = {
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_QRK_SDIO },
-   {},
-};
-
 static void quark_setup_mtrr(void)
 {
u32 base, mask;
@@ -328,11 +323,6 @@ int arch_early_init_r(void)
return 0;
 }
 
-int cpu_mmc_init(bd_t *bis)
-{
-   return pci_mmc_init("Quark SDHCI", mmc_supported);
-}
-
 int arch_misc_init(void)
 {
 #ifdef CONFIG_ENABLE_MRC_CACHE
diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
index af3ffad385..c0681995bd 100644
--- a/arch/x86/cpu/queensbay/Makefile
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -5,4 +5,4 @@
 #
 
 obj-y += fsp_configs.o irq.o
-obj-y += tnc.o topcliff.o
+obj-y += tnc.o
diff --git a/arch/x86/cpu/queensbay/topcliff.c 
b/arch/x86/cpu/queensbay/topcliff.c
deleted file mode 100644
index b76dd7de69..00
--- a/arch/x86/cpu/queensbay/topcliff.c
+++ /dev/null
@@ -1,20 +0,0 @@
-/*
- * Copyright (C) 2014, Bin Meng 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-
-static struct pci_device_id mmc_supported[] = {
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_0 },
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_1 },
-   {},
-};
-
-int cpu_mmc_init(bd_t *bis)
-{
-   return pci_mmc_init("Topcliff SDHCI", mmc_supported);
-}
diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c
index e39b476834..6db89779ba 100644
--- a/drivers/mmc/pci_mmc.c
+++ b/drivers/mmc/pci_mmc.c
@@ -6,37 +6,71 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-int pci_mmc_init(const char *name, struct pci_device_id *mmc_supported)
+struct pci_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+struct pci_mmc_priv {
+   struct sdhci_host host;
+   void *base;
+};
+
+static int pci_mmc_probe(struct udevice *dev)
 {
-   struct sdhci_host *mmc_host;
-   u32 iobase;
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct pci_mmc_plat *plat = dev_get_platdata(dev);
+   struct pci_mmc_priv *priv = dev_get_priv(dev);
+   struct sdhci_host *host = >host;
+   u32 ioaddr;
int ret;
-   int i;
-
-   for (i = 0; ; i++) {
-   struct udevice *dev;
-
-   ret = pci_find_device_id(mmc_supported, i, );
-   if (ret)
-   return ret;
-   mmc_host = malloc(sizeof(struct sdhci_host));
-   if (!mmc_host)
-   return -ENOMEM;
-
-   mmc_host->name = name;
-   dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
-   mmc_host->ioaddr = (void *)(ulong)iobase;
-   mmc_host->quirks = 0;
-   mmc_host->max_clk = 0;
-   ret = add_sdhci(mmc_host, 0, 0);
-   if (ret)
-   return ret;
-   }
-
-   return 0;
+
+   dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
+   host->ioaddr = map_sysmem(ioaddr, 0);
+   host->name = dev->name;
+   ret = sdhci_setup_cfg(>cfg, host, 0, 0);
+   if (ret)
+   return ret;
+   host->mmc = >mmc;
+   host->mmc->priv = 

[U-Boot] [PATCH 0/2] x86: Convert all boards to use MMC to driver model

2017-04-09 Thread Simon Glass
This serial converts x86 boards to use MMC for driver model. It has to
disable SCSI to make this work, for now. Once SCSI is sorted out, we can
apply the patch.


Simon Glass (2):
  WIP: Disable SCSI on x86
  x86: Convert MMC to driver model

 arch/Kconfig   |  1 +
 arch/x86/cpu/baytrail/valleyview.c | 12 --
 arch/x86/cpu/quark/quark.c | 10 -
 arch/x86/cpu/queensbay/Makefile|  2 +-
 arch/x86/cpu/queensbay/topcliff.c  | 20 -
 drivers/mmc/pci_mmc.c  | 86 ++
 include/configs/x86-common.h   |  6 ++-
 include/mmc.h  | 12 --
 8 files changed, 66 insertions(+), 83 deletions(-)
 delete mode 100644 arch/x86/cpu/queensbay/topcliff.c

-- 
2.12.2.715.g7642488e1d-goog

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


Re: [U-Boot] [PATCH v4 00/35] ARM: i.MX6: SabreSD: Add dts support

2017-04-09 Thread Fabio Estevam
On Sun, Apr 9, 2017 at 4:12 PM, Jagan Teki  wrote:

> Bcz we need to define dtb through CONFIG_DEFAULT_DEVICE_TREE

Having 3 defconfigs for SPL is not good. Looks like a step in the
opposite direction.

Can this limitation be changed?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 8/8] defconfigs: Add a config for AM335x High Security EVM with UART Boot support

2017-04-09 Thread Tom Rini
On Fri, Apr 07, 2017 at 10:11:26AM -0500, Andrew F. Davis wrote:

> Add a new defconfig file for the AM335x High Security EVM. This config
> is specific for the case of UART booting
> 
> Signed-off-by: Andrew F. Davis 

Please note that with gcc-4.9 and gcc-5.x this does not link, only with
gcc-6.x.  This particular config might need to stay in the TI SDKs only
for now as we're not ready to go with gcc-6.x as a minimum and I'm not
sure you can get another ~2144 bytes back.

-- 
Tom


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


Re: [U-Boot] [PATCH] video: Remove dependecy of I2C_EDID

2017-04-09 Thread Jernej Škrabec
Hi,

Dne nedelja, 09. april 2017 ob 21:28:47 CEST je Simon Glass napisal(a):
> Hi,
> 
> On 28 March 2017 at 16:39, Jernej Skrabec  wrote:
> > I2C_EDID currently selects DM_I2C. However, it is not needed. I2C_EDID
> > is used for building edid.c, which doesn't even use I2C bus, and by I2C
> > command, which knows how to use DM and old style I2C interface, so it is
> > not directly affected by this removal.
> > 
> > Furthermore, this selection can generate warning if DM display driver
> > is used on platform which doesn't implement DM I2C driver (for example,
> > sunxi platform with upcoming DM video & display driver).
> > 
> > Patch was tested with rockchip and sunxi boards and successfully
> > compiled exynos and tegra targets. They are the only consumers of
> > CONFIG_DISPLAY option, which is the only one which selects I2C_EDID.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  cmd/i2c.c | 10 ++
> >  drivers/video/Kconfig |  1 -
> >  2 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/cmd/i2c.c b/cmd/i2c.c
> > index 473153fbd4..7b6306e525 100644
> > --- a/cmd/i2c.c
> > +++ b/cmd/i2c.c
> > @@ -1630,7 +1630,8 @@ static int do_sdram (cmd_tbl_t * cmdtp, int flag,
> > int argc, char * const argv[])> 
> >   * Syntax:
> >   * i2c edid {i2c_chip}
> >   */
> > 
> > -#if defined(CONFIG_I2C_EDID)
> > +#if defined(CONFIG_I2C_EDID) && \
> > +   (defined(CONFIG_SYS_I2C) || defined(CONFIG_DM_I2C))
> 
> The correct solution here I think is to convert sunxi to DM_I2C. We
> should not be adding new features to the old code.

With the "old code" you referring to i2c command? Actually, I'm not sure if 
"i2c edid" command can be useful on most platforms. I know that rk3288 has 
multiplexed I2C controller pins with HDMI DDC pins, where this make sense. But 
for example on sunxi, in order to be useful, it would mean that dw_hdmi driver 
has to register DDC as I2C driver.

I'm also not sure why "i2c edid" code knows how to use old and DM I2C 
interface when it is surrounded by a symbol, which always selects DM_I2C. 
Well, in sunxi case, that actually prevents build failure, but still produces 
unwanted warning.

Otherwise I agree that converting sunxi to DM_I2C should be done and patch for 
that already exists, but it was not merged yet:
https://patchwork.ozlabs.org/patch/734375/

Regards,
Jernej
> 
> >  int do_edid(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> >  {
> >  
> > uint chip;
> > 
> > @@ -1665,7 +1666,7 @@ int do_edid(cmd_tbl_t *cmdtp, int flag, int argc,
> > char *const argv[])> 
> > return 0;
> >  
> >  }
> > 
> > -#endif /* CONFIG_I2C_EDID */
> > +#endif
> > 
> >  #ifdef CONFIG_DM_I2C
> >  static void show_bus(struct udevice *bus)
> > 
> > @@ -1936,9 +1937,10 @@ static cmd_tbl_t cmd_i2c_sub[] = {
> > 
> > defined(CONFIG_I2C_MULTI_BUS) || defined(CONFIG_DM_I2C)
> > U_BOOT_CMD_MKENT(dev, 1, 1, do_i2c_bus_num, "", ""),
> >  
> >  #endif  /* CONFIG_I2C_MULTI_BUS */
> > 
> > -#if defined(CONFIG_I2C_EDID)
> > +#if defined(CONFIG_I2C_EDID) && \
> > +   (defined(CONFIG_SYS_I2C) || defined(CONFIG_DM_I2C))
> > 
> > U_BOOT_CMD_MKENT(edid, 1, 1, do_edid, "", ""),
> > 
> > -#endif  /* CONFIG_I2C_EDID */
> > +#endif
> > 
> > U_BOOT_CMD_MKENT(loop, 3, 1, do_i2c_loop, "", ""),
> > U_BOOT_CMD_MKENT(md, 3, 1, do_i2c_md, "", ""),
> > U_BOOT_CMD_MKENT(mm, 2, 1, do_i2c_mm, "", ""),
> > 
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 2069576958..2f340235ee 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -355,7 +355,6 @@ config VIDEO_MVEBU
> > 
> >  config I2C_EDID
> >  
> > bool "Enable EDID library"
> > 
> > -   depends on DM_I2C
> > 
> > default n
> > help
> > 
> >This enables library for accessing EDID data from an LCD panel.
> > 
> > --
> > 2.12.1
> 
> Regards,
> Simon


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


[U-Boot] OMAP_HSMMC and MMC getcd discrepancy

2017-04-09 Thread Adam Ford
I am trying to port my OMAP3630 board to use DM_MMC and
OMAP_HSMMC_USE_GPIO without CONFIG_DM_MMC_OPS and with OF support by
porting the OMAP3 device tree and I think there might be an issue with
card detect. I am hoping someone might be able to clarify it for me.

For what it's worth, the card detection in the device tree I have
works fine under Linux, so I think the issue is more related to U-Boot
than the device tree itself.

My understanding of mmc_getwp and mmc_getcd from mmc.c is that both of
them are going to be pointing to a functions that reads the status of
the write protect and card detect pins.  The omap_hsmmc driver maps
these functions to omap_hsmmc_getcd and omap_hsmmc_getwp.

There are two versions, one when DM_MMC is defined and one without it defined.

Looking at the two getcd functions, it appears as if they boot look
for the returned value of the gpio pin.  Since  CD pins are asserted
low, I would expect that when the card is detected the CD pin would be
0 and 1 when absent.  I would also expect the same for the WP pin.

The non-DM_MMC version of the card detect function appears to address
this in a comment "/* NOTE: assumes card detect signal is active-low
*/ and returns the opposite of the gpio value with
!gpio_get_value(cd_gpio);

However, the DM_MMC version has a check to see if the flag is
inverted. Since these signals are passed to the higher level mmc
driver, it seems like when the gpio is low, the return value should be
high (card is detected when gpio = 0), yet it only inverts when the
extra flag is set in the device tree and it seems like the logic is
backwards.

I am wondering if the omap_hsmmc_getcd using DM_MMC should instead read use:

  if (priv->cd_inverted)
 return value;
  return !value;

If this makes sense, I can supply a patch, but I wanted to make sure I
have the correct understanding first.  Can someone please confirm if I
am understanding this correctly?

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


Re: [U-Boot] [PATCH v4 1/2] spl: Add spl_early_init()

2017-04-09 Thread Simon Glass
Hi Tom,

On 20 March 2017 at 08:27, Tom Rini  wrote:
> On Mon, Mar 20, 2017 at 10:58:57AM +0530, Lokesh Vutla wrote:
>> Hi Simon,
>>
>> On Wednesday 15 March 2017 08:13 PM, Simon Glass wrote:
>> > From: Eddie Cai 
>> >
>> > At present malloc_base/_limit/_ptr are not initialised in spl_init() when
>> > we call spl_init() in board_init_f(). This is due to a recent change aimed
>> > at avoiding overwriting the malloc area set up on some boards by
>> > spl_relocate_stack_gd().
>> >
>> > However if CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN is not defined, we now
>> > skip setting up the memory area in spl_init() which is obviously wrong.
>> >
>> > To fix this, add a new function spl_early_init() which can be called in
>> > board_init_f().
>> >
>> > Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit)
>> > Signed-off-by: Eddie Cai 
>> > Rewrote spl_{,early_}init() to avoid duplicate code:
>> > Rewrite/expand commit message:
>> > Signed-off-by: Simon Glass 
>> > ---
>> >
>> > Changes in v4: None
>> > Changes in v3: None
>> > Changes in v2:
>> > - Rewrote spl_{,early_}init() to avoid duplicate code
>> > - Rewrite commit message
>> >
>> >  common/spl/spl.c  | 46 
>> > +--
>> >  include/asm-generic/global_data.h |  1 +
>> >  include/spl.h | 24 +---
>> >  3 files changed, 57 insertions(+), 14 deletions(-)
>> >
>> > diff --git a/common/spl/spl.c b/common/spl/spl.c
>> > index 766fb3d6f4..2bc8b42027 100644
>> > --- a/common/spl/spl.c
>> > +++ b/common/spl/spl.c
>> > @@ -170,22 +170,20 @@ __weak void __noreturn jump_to_image_no_args(struct 
>> > spl_image_info *spl_image)
>> > image_entry();
>> >  }
>> >
>> > -int spl_init(void)
>> > +static int spl_common_init(bool setup_malloc)
>> >  {
>> > int ret;
>> >
>> > -   debug("spl_init()\n");
>> > -/*
>> > - * with CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN we set malloc_base and
>> > - * malloc_limit in spl_relocate_stack_gd
>> > - */
>> > -#if defined(CONFIG_SYS_MALLOC_F_LEN) && \
>> > -   !defined(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN)
>> > +   debug("spl_early_init()\n");
>> > +
>> > +#if defined(CONFIG_SYS_MALLOC_F_LEN)
>> > +   if (setup_malloc) {
>> >  #ifdef CONFIG_MALLOC_F_ADDR
>> > -   gd->malloc_base = CONFIG_MALLOC_F_ADDR;
>> > +   gd->malloc_base = CONFIG_MALLOC_F_ADDR;
>> >  #endif
>> > -   gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN;
>> > -   gd->malloc_ptr = 0;
>> > +   gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN;
>> > +   gd->malloc_ptr = 0;
>> > +   }
>> >  #endif
>> > if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) {
>> > ret = fdtdec_setup();
>> > @@ -202,6 +200,32 @@ int spl_init(void)
>> > return ret;
>> > }
>> > }
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +int spl_early_init(void)
>> > +{
>> > +   int ret;
>> > +
>> > +   ret = spl_common_init(true);
>> > +   if (ret)
>> > +   return ret;
>> > +   gd->flags |= GD_FLG_SPL_EARLY_INIT;
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +int spl_init(void)
>> > +{
>> > +   int ret;
>> > +
>> > +   if (!(gd->flags & GD_FLG_SPL_EARLY_INIT)) {
>> > +   ret = spl_common_init(
>> > +   !IS_ENABLED(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN));
>>
>> IS_ENABLED(CONFIG defined as hex) is always false. So this will always
>> return true and overriding the malloc_limit, which is causing boot
>> failures on DRA7xx based boards.:wq
>
> Maybe we should use a bool that we set based on (SPL_STACK_R &&
> SPL_SYS_MALLOC_SIMPLE) being true or not as that's the gating condition
> for CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN being set.

And it looks like you fixed this with:

cf334edfbbspl: Correct call to spl_common_init() with
SPL_STACK_R_MALLOC_SIMPLE_LEN

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


Re: [U-Boot] [PATCH 1/4] dm: device_remove: Don't return in device_chld_remove() upon error

2017-04-09 Thread Simon Glass
Hi Stefan,

On 6 April 2017 at 07:29, Stefan Roese  wrote:
> On my x86 platform I've noticed, that calling dm_uninit() or the new
> function dm_remove_devices_flags() does not remove the desired device at
> all. Debugging showed, that the serial uclass returns -EPERM in
> serial_pre_remove() and this leads to a complete stop of the device
> removal pretty early, as the serial device is one of the first ones in
> the DM. Here the dm tree output:
>
> => dm tree
>  Class   Probed   Name
> 
>  root[ + ]root_driver
>  rsa_mod_exp [   ]|-- mod_exp_sw
>  serial  [ + ]|-- serial
>  rtc [   ]|-- rtc
>  timer   [ + ]|-- tsc-timer
>  syscon  [ + ]|-- pch_pinctrl
>  ...
>
> In this example, device_remove(root) will stop directly after trying to
> remove the "serial" device.
>
> To solve this problem, this patch removes the return upon error check in
> the device_remove() call in device_chld_remove(). This leads to
> device_chld_remove() continuing with the device_remove() call to the
> following child devices.

I think the right solution is to find out why stdio_deregister_dev()
fails. It is probably because the device is in use within the stdio
variables. Perhaps you need to remove it first?

>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  drivers/core/device-remove.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index cc0043b990..8b46f3343e 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -52,15 +52,11 @@ static int device_chld_unbind(struct udevice *dev)
>  static int device_chld_remove(struct udevice *dev, uint flags)
>  {
> struct udevice *pos, *n;
> -   int ret;
>
> assert(dev);
>
> -   list_for_each_entry_safe(pos, n, >child_head, sibling_node) {
> -   ret = device_remove(pos, flags);
> -   if (ret)
> -   return ret;
> -   }
> +   list_for_each_entry_safe(pos, n, >child_head, sibling_node)
> +   device_remove(pos, flags);

I think we should keep the error checking here.

>
> return 0;
>  }
> --
> 2.12.2
>

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


Re: [U-Boot] [PATCH 3/4] x86: bootm: Add dm_remove_devices_flags() call to bootm_announce_and_cleanup()

2017-04-09 Thread Simon Glass
On 6 April 2017 at 07:29, Stefan Roese  wrote:
> This patch adds a call to dm_remove_devices_flags() to
> bootm_announce_and_cleanup() so that drivers that have one of the removal
> flags set (e.g. DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may
> do some last-stage cleanup before the OS is started.
>
> Signed-off-by: Stefan Roese 
> Cc: Bin Meng 
> Cc: Simon Glass 
> ---
>  arch/x86/lib/bootm.c | 9 +
>  1 file changed, 9 insertions(+)

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


Re: [U-Boot] [PATCH] rockchip: sysreset: rk3188: Make sure remap is off on warm-resets

2017-04-09 Thread Simon Glass
On 7 April 2017 at 04:38, Heiko Stuebner  wrote:
> The warm-reset of rk3188 socs keeps the remap setting as it was, so if
> it was enabled, the cpu would start from address 0x0 of the sram instead
> of address 0x0 of the bootrom, thus making the reset hang.
>
> Therefore make sure the remap is disabled before attempting a warm reset.
>
> Cold reset is not affected by this at all.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/sysreset/sysreset_rk3188.c | 15 +++
>  1 file changed, 15 insertions(+)

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


Re: [U-Boot] [PATCH 1/5] rockchip: i2c: enable i2c for rk3399

2017-04-09 Thread Simon Glass
Hi Eric,

On 8 April 2017 at 06:17, Eric Gao  wrote:
> From: "eric.gao" 
>
> To enable mipi display, we need to enable pmic
> rk808 first for lcd3v3 power,which use i2c0 to
> communicate with soc. So enable i2c0.
>
> Signed-off-by: eric.gao 
>
> eric@rock-chips.com

Can you fix up these duplicates? You see to have two slightly
different email addresses.

>
> Signed-off-by: Eric Gao 
> ---
>
>  arch/arm/dts/rk3399.dtsi | 16 
>  configs/evb-rk3399_defconfig |  1 +
>  drivers/i2c/rk_i2c.c |  1 +
>  3 files changed, 18 insertions(+)

Acked-by: Simon Glass 

This has come through as one thread with lots of resends in my email.
I'm not sure if you are using patman? It normally helps to make things
right. Also check your name and email in ~/.gitconfig

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


Re: [U-Boot] [PATCH] rockchip: rk3399: do not use lower address

2017-04-09 Thread Simon Glass
On 7 April 2017 at 04:12, Kever Yang  wrote:
> The lower address is reserved for ATF, do not use it.
>
> Signed-off-by: Kever Yang 
> ---
>
>  include/configs/rk3399_common.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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


Re: [U-Boot] [PATCH v2 07/10] scsi: make the LUN a parameter of scsi_detect_dev()

2017-04-09 Thread Simon Glass
On 7 April 2017 at 05:42, Jean-Jacques Hiblot  wrote:
> This is a cosmetic change. target and LUN have kind of the same role in
> this function. One of them was passed as a parameter and the other was
> embedded in a structure. For consistency, pass both of them as parameters.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  common/scsi.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>

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


Re: [U-Boot] [EXT] Re: [PATCH 3/7] scsi: call children devices' probe functions automatically

2017-04-09 Thread Simon Glass
Hi Ken,

On 5 April 2017 at 02:47, Ken Ma  wrote:
> Hi Simon
>
> Please see my inline reply, thanks a lot!
>
> Yours,
> Ken
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2017年4月1日 12:22
> To: Ken Ma
> Cc: U-Boot Mailing List; Stefan Roese; Michal Simek
> Subject: [EXT] Re: [PATCH 3/7] scsi: call children devices' probe functions 
> automatically
>
> External Email
>
> --
> Hi,
>
> On 23 March 2017 at 03:29,   wrote:
>> From: Ken Ma 
>>
>> - For the purpose of accessing peripheral devices through SCSI, the
>>   peripheral devices need to be probed to finish low level
>>   initialization, for example, ahci controller needs to do the ahci
>>   initialization;
>> - scsi_low_level_init() calling is removed since the detailed scsi low
>>   level initialization work is up to the peripheral scsi devices, for
>>   example, sata controller may do AHCI initialization while scanner
>>   controller may do ISIS initialization; the work should be done in
>>   children devices probe when scsi controller acts as bus or be done
>>   in the pure SAS controller's probe when SCSI controller is a SAS
>>   and works as an on-board component on the motherboard;
>> - Since u-boot initialization does not probe devices by default, SCSI
>>   children devices can be probed automatically in SCSI post probe
>>   function when SCSI controller acts as a bus.
>
> Do you have to probe everything? The idea in DM is to probe devices only when 
> they are first used.
> [Ken] If we do not probe SCSI' children nodes such as sata hdds scsi devices, 
> then "scsi scan" will fail since command "scsi scan" only probes SCSI host 
> controllers but not SCSI devices which are SCSI node's children nodes; 
> otherwise we should add SCSI node's children devices' probe to "scsi scan".
> How do you think about it? Thanks!

I think that probing the scsi driver should be done at the start, then
scanning should be an operation which can be performed afterwards. I'm
not saying you shouldn't do both, but conceptually they are different
and I think we should keep them separate.

Probing a SCSI controller just means that the hardware is prepared so
we can use it..

>
> (Also please use 'U-Boot' everywhere consistently)
> [Ken] got it, thanks!
>
>>
>> Signed-off-by: Ken Ma 
>> Cc: Simon Glass 
>> Cc: Stefan Roese 
>> Cc: Michal Simek 
>> Reviewed-on: http://vgitil04.il.marvell.com:8080/35426
>> Tested-by: iSoC Platform CI 
>> Reviewed-by: Omri Itach 
>> Reviewed-by: Kostya Porotchkin 
>> ---
>>  drivers/block/scsi-uclass.c | 22 --
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/scsi-uclass.c b/drivers/block/scsi-uclass.c
>> index 86eddfc..119ba53 100644
>> --- a/drivers/block/scsi-uclass.c
>> +++ b/drivers/block/scsi-uclass.c
>> @@ -18,8 +18,26 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>>  static int scsi_post_probe(struct udevice *dev)  {
>> +   struct udevice *child_dev;
>> +   int ret;
>> +
>> debug("%s: device %p\n", __func__, dev);
>> -   scsi_low_level_init(0, dev);
>> +
>> +   /*
>> +* For the purpose of accessing peripheral devices through SCSI, the
>> +* peripheral devices need to be probed to finish low level
>> +* initialization, for example, ahci controller needs to do the ahci
>> +* initialization;
>> +* Since u-boot initialization does not probe devices by
>> + default, SCSI
>
> U-Boot
>
>> +* children devices can be probed automatically in SCSI post probe
>> +* function when SCSI controller acts as a bus.
>> +*/
>> +   list_for_each_entry(child_dev, >child_head, sibling_node) {
>> +   ret = device_probe(child_dev);
>> +   if (ret)
>> +   return ret;
>> +   }
>> +
>> return 0;
>>  }
>>
>> @@ -54,6 +72,6 @@ UCLASS_DRIVER(scsi) = {
>> .id = UCLASS_SCSI,
>> .name   = "scsi",
>> .post_bind  = scsi_post_bind,
>> -   .post_probe  = scsi_post_probe,
>> +   .post_probe = scsi_post_probe,
>> .per_device_platdata_auto_alloc_size = sizeof(struct
>> scsi_platdata),  };
>> --
>> 1.9.1
>>
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] rockchip: cosmetic: Move rock board to its correct position

2017-04-09 Thread Simon Glass
On 5 April 2017 at 16:19, Heiko Stuebner  wrote:
> Somehow 43b5c78d8d91 ("rockchip: cosmetic: Sort RK3288 boards") moved
> the rock board in between some rk3288 board, probably as a result of
> rebasing.
>
> So move it back to its original position above all rk3288 boards.
>
> Fixes: 43b5c78d8d91 ("rockchip: cosmetic: Sort RK3288 boards")
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/dts/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH 5/6] cmd: led: add DM-based implementation

2017-04-09 Thread Simon Glass
Hi,

On 5 April 2017 at 07:24, Ziping Chen  wrote:
>
>
> 2017-04-01 12:22 GMT+08:00 Simon Glass :
>>
>> Hi,


>
>
> Hi, Simon
>
> I have seen your version, and I deem your code is more appropriate.
> I'll learn from your code.

That is very kind of you. I'm sorry for the duplication.

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


Re: [U-Boot] Loading kernel from SD card slow on MinnowBoard Turbot since v2016.09

2017-04-09 Thread Simon Glass
Hi,

On 8 November 2016 at 05:10, Raschen Josef  wrote:
> Hi,
>
>> From my tests it should be somewhere between these two commits:
>> 1c62d999528da1f052cb4b07cbb540b148c52537OK
>> ceec08f50b66df0c988033842ec057a32658cfe0NOK
>
> I did some more tests and it looks like commit 
> 14bed52d276afd36b9674ee7aa2c2ad9d2f4e59e introduced the issue. From the code 
> I would guess that the max clock of the mmc controller is not set up 
> correctly for the x86/BayTrail platform (minnowmax_defconfig in my case).
>
> Thanks,
> Josef
>

I made some time to dig into this recently.

From what I can this is a bug in the old code. Since pci_mmc.c does
not read the version number into host->version, add_sdhci() used to
just use a value of 0. Now it reads the correct version number.

old code:
MMC:   sdhci_setup_cfg: name=ValleyView SDHCI, host_caps=0,
cfg->host_caps=7, f_min=140625, f_max=3600
sdhci_setup_cfg: name=ValleyView SDHCI, host_caps=0, cfg->host_caps=7,
f_min=140625, f_max=3600
ValleyView SDHCI: 0, ValleyView SDHCI: 1


new code:
sdhci_setup_cfg: version = b502
sdhci_setup_cfg: name=ValleyView SDHCI, host_caps=0, cfg->host_caps=7,
f_min=48875, f_max=1
add_sdhci: version = 0
sdhci_setup_cfg: version = b502
sdhci_setup_cfg: name=ValleyView SDHCI, host_caps=0, cfg->host_caps=7,
f_min=48875, f_max=1
add_sdhci: version = 0
sdhci_setup_cfg: version = 1002
sdhci_setup_cfg: name=ValleyView SDHCI, host_caps=0, cfg->host_caps=7,
f_min=97751, f_max=2


So the clock speed is showing as faster with the new code (the MMC
card is the second one above. I suspect the old card was programming
the registers incorrectly and happening to get a higher speed.

That said, I do see twice the performance with the old code. I wonder
if there is a way to detect that the card or host can run faster?

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


Re: [U-Boot] [PATCH 4/4] spi: ich: Configure SPI BIOS parameters for Linux upon U-Boot exit

2017-04-09 Thread Simon Glass
On 6 April 2017 at 07:29, Stefan Roese  wrote:
> This patch adds a remove function to the Intel ICH SPI driver, that will
> be called upon U-Boot exit, directly before the OS (Linux) is started.
> This function takes care of configuring the BIOS registers in the SPI
> controller (similar to what a "standard" BIOS or coreboot does), so that
> the Linux MTD device driver is able to correctly read/write to the SPI
> NOR chip. Without this, the chip is not detected at all.
>
> Signed-off-by: Stefan Roese 
> Cc: Bin Meng 
> Cc: Simon Glass 
> Cc: Jagan Teki 
> ---
>  drivers/spi/ich.c | 18 ++
>  drivers/spi/ich.h | 54 +++---
>  2 files changed, 65 insertions(+), 7 deletions(-)

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


Re: [U-Boot] [PATCH] video: Remove dependecy of I2C_EDID

2017-04-09 Thread Simon Glass
Hi,

On 28 March 2017 at 16:39, Jernej Skrabec  wrote:
> I2C_EDID currently selects DM_I2C. However, it is not needed. I2C_EDID
> is used for building edid.c, which doesn't even use I2C bus, and by I2C
> command, which knows how to use DM and old style I2C interface, so it is
> not directly affected by this removal.
>
> Furthermore, this selection can generate warning if DM display driver
> is used on platform which doesn't implement DM I2C driver (for example,
> sunxi platform with upcoming DM video & display driver).
>
> Patch was tested with rockchip and sunxi boards and successfully
> compiled exynos and tegra targets. They are the only consumers of
> CONFIG_DISPLAY option, which is the only one which selects I2C_EDID.
>
> Signed-off-by: Jernej Skrabec 
> ---
>
>  cmd/i2c.c | 10 ++
>  drivers/video/Kconfig |  1 -
>  2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/i2c.c b/cmd/i2c.c
> index 473153fbd4..7b6306e525 100644
> --- a/cmd/i2c.c
> +++ b/cmd/i2c.c
> @@ -1630,7 +1630,8 @@ static int do_sdram (cmd_tbl_t * cmdtp, int flag, int 
> argc, char * const argv[])
>   * Syntax:
>   * i2c edid {i2c_chip}
>   */
> -#if defined(CONFIG_I2C_EDID)
> +#if defined(CONFIG_I2C_EDID) && \
> +   (defined(CONFIG_SYS_I2C) || defined(CONFIG_DM_I2C))

The correct solution here I think is to convert sunxi to DM_I2C. We
should not be adding new features to the old code.

>  int do_edid(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
>  {
> uint chip;
> @@ -1665,7 +1666,7 @@ int do_edid(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> return 0;
>
>  }
> -#endif /* CONFIG_I2C_EDID */
> +#endif
>
>  #ifdef CONFIG_DM_I2C
>  static void show_bus(struct udevice *bus)
> @@ -1936,9 +1937,10 @@ static cmd_tbl_t cmd_i2c_sub[] = {
> defined(CONFIG_I2C_MULTI_BUS) || defined(CONFIG_DM_I2C)
> U_BOOT_CMD_MKENT(dev, 1, 1, do_i2c_bus_num, "", ""),
>  #endif  /* CONFIG_I2C_MULTI_BUS */
> -#if defined(CONFIG_I2C_EDID)
> +#if defined(CONFIG_I2C_EDID) && \
> +   (defined(CONFIG_SYS_I2C) || defined(CONFIG_DM_I2C))
> U_BOOT_CMD_MKENT(edid, 1, 1, do_edid, "", ""),
> -#endif  /* CONFIG_I2C_EDID */
> +#endif
> U_BOOT_CMD_MKENT(loop, 3, 1, do_i2c_loop, "", ""),
> U_BOOT_CMD_MKENT(md, 3, 1, do_i2c_md, "", ""),
> U_BOOT_CMD_MKENT(mm, 2, 1, do_i2c_mm, "", ""),
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 2069576958..2f340235ee 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -355,7 +355,6 @@ config VIDEO_MVEBU
>
>  config I2C_EDID
> bool "Enable EDID library"
> -   depends on DM_I2C
> default n
> help
>This enables library for accessing EDID data from an LCD panel.
> --
> 2.12.1
>

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


Re: [U-Boot] [PATCH v2 08/10] scsi: move the partition initialization out of the scsi detection

2017-04-09 Thread Simon Glass
On 7 April 2017 at 05:42, Jean-Jacques Hiblot  wrote:
> We might want to get information about the scsi device without initializing 
> the partition.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  common/scsi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2] rockchip: rk3188: enable remap function

2017-04-09 Thread Simon Glass
On 5 April 2017 at 16:19, Heiko Stuebner  wrote:
> Most Rockchip socs have the ability to either map the bootrom or a sram
> area to the starting address of the cpu by flipping a bit in the GRF.
>
> Newer socs leave this untouched and mapped to the bootrom but the legacy
> loaders on rk3188 and before enabled the remap functionality and the
> current smp implementation in the Linux kernel also requires it to be
> enabled, to bring up secondary cpus.
>
> So to keep smp working in the kernel, mimic the behaviour of the legacy
> bootloaders and enable the remap functionality.
>
> Signed-off-by: Heiko Stuebner 
> ---
> changes in v2:
> - drop the rk_board_late_init weak function
>   If boards need even more specialized init we can worry
>   about that later.
>
>  arch/arm/mach-rockchip/Kconfig|  1 +
>  arch/arm/mach-rockchip/rk3188-board.c | 18 ++
>  2 files changed, 19 insertions(+)

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


Re: [U-Boot] [PATCH 06/21] usb: ehci: Add STi ehci support

2017-04-09 Thread Simon Glass
Hi Patrice,

On 3 April 2017 at 03:39, Patrice CHOTARD  wrote:
> Hi Simon
>
> On 04/01/2017 06:21 AM, Simon Glass wrote:
>> Hi Patrice,
>>
>> On 23 March 2017 at 03:59, Patrice CHOTARD  wrote:
>>> Hi Simon
>>>
>>> On 03/22/2017 02:05 PM, Simon Glass wrote:
 Hi,

 On 17 March 2017 at 10:25,   wrote:
> From: Patrice Chotard 
>
> Add support for on-chip ehci controller available
> on STMicrolectronics SoCs.
> ehci support will be then available on both type A
> USB 2.0 connectors.
>
> Signed-off-by: Patrice Chotard 
> ---
>  drivers/usb/host/Kconfig|  9 +
>  drivers/usb/host/Makefile   |  1 +
>  drivers/usb/host/ehci-sti.c | 91 
> +
>  3 files changed, 101 insertions(+)
>  create mode 100644 drivers/usb/host/ehci-sti.c
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 5129a57..d66f49e 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -120,6 +120,15 @@ config USB_EHCI_MSM
>   This driver supports combination of Chipidea USB controller
>   and Synapsys USB PHY in host mode only.
>
> +config USB_EHCI_STI
> +   bool "Support for STMicroelectronics on-chip EHCI USB controller"
> +   depends on ARCH_STI
> +   select STI_PHY_USB
> +   default y
> +   ---help---
> + Enables support for the on-chip EHCI controller on
> + STMicroelectronics SoCs.
> +
>  config USB_EHCI_ZYNQ
> bool "Support for Xilinx Zynq on-chip EHCI USB controller"
> depends on ARCH_ZYNQ
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 58c0cf5..303aa32 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_USB_EHCI_MARVELL) += ehci-marvell.o
>  obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
>  obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
>  obj-$(CONFIG_USB_EHCI_SPEAR) += ehci-spear.o
> +obj-$(CONFIG_USB_EHCI_STI) += ehci-sti.o
>  obj-$(CONFIG_USB_EHCI_SUNXI) += ehci-sunxi.o
>  obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o
>  obj-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o
> diff --git a/drivers/usb/host/ehci-sti.c b/drivers/usb/host/ehci-sti.c
> new file mode 100644
> index 000..89ca66a
> --- /dev/null
> +++ b/drivers/usb/host/ehci-sti.c
> @@ -0,0 +1,91 @@
> +/*
> + * Copyright (c) 2017
> + * Patrice Chotard 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "ehci.h"
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct sti_ehci_priv {
> +   struct ehci_ctrl ctrl;
> +   struct reset_ctl power_ctl;
> +   struct reset_ctl softreset_ctl;
> +};
> +
> +static int sti_ehci_probe(struct udevice *dev)
> +{
> +   struct sti_ehci_priv *priv = dev_get_priv(dev);
> +   struct ehci_hccr *hccr = priv->ctrl.hccr;
> +   struct ehci_hcor *hcor;
> +   struct udevice *dev_phy;
> +   int ret, phy_node;
> +
> +   hccr = (struct ehci_hccr *)dev_get_addr(dev);
> +
> +   if (hccr == (void *)FDT_ADDR_T_NONE)
> +   return -EINVAL;
> +
> +   ret = reset_get_by_name(dev, "power", >power_ctl);

 This is OK, but can you instead access it via a phandle in the device's 
 node?
>>>
>>> Sorry i didn't get your point. Why getting it using a phandle ?
>>
>> I mean that generally when a device needs another device this is
>> expressed by adding a phandle in the client device's node, or perhaps
>> some sort of name. That way it is possible (e.g.) to specify *which*
>> reset rather than hard-coding it.
>
> Agree with you, but i get one constraint. For this ehci IP, there are 2
> resets (power and softreset). I must identify each other to be able to
> assert/deassert them in the correct order.

One of those sounds like a reset. The other sounds like a regulator.

>
> I checked other U-boot drivers which already used reset, and all of them
> are using reset_get_by_name().

OK well it was a suggestion so will leave it to you. Is that how Linux
does it also?

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


Re: [U-Boot] [PATCH v2 3/4] env_sf: re-order error handling in single-buffer env_relocate_spec

2017-04-09 Thread Simon Glass
On 8 April 2017 at 03:59, Andreas Fenkart  wrote:
> this makes it easier comparable to the double-buffered version
>
> Signed-off-by: Andreas Fenkart 
> Reviewed-by: Simon Glass 
> ---
>  common/env_sf.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)

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


Re: [U-Boot] __FILE__ usage and and SPL limits for SRAM

2017-04-09 Thread Simon Glass
Hi Tom,

On 4 April 2017 at 13:06, Tom Rini  wrote:
> On Tue, Mar 28, 2017 at 11:37:45AM +0530, Lokesh Vutla wrote:
>> + more folks.
>>
>> On Tuesday 28 March 2017 03:14 AM, Nishanth Menon wrote:
>> > Hi,
>> >
>> > we've kind of run into an interesting situation recently, but might be
>> > of interest for various folks trying to reduce the image sizes.
>> >
>> > our AM335x device has a limited amount of sram.. and the SPL tries to
>> > fit into it (a bit tricky given the restricted space we have on it on
>> > certain class of devices).
>> >
>> > arch/arm/mach-omap2/am33xx/u-boot-spl.lds is a bit custom tailored
>> > around this.
>> >
>> > Key in this is:
>> > . = ALIGN(4);
>> > .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
>> >
>> > . = ALIGN(4);
>> > .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
>> >
>> >
>> > Now, our jenkins build system happens to use a varied build path and
>> > uses O= path. to simplify the details:
>> > mkdir
>> > /tmp//b/cc
>> >
>> > mkdir
>> > /tmp//b/cc/b
>> >
>> >
>> > git clone u-boot
>> > cd u-boot
>> >
>> > git clean -fdx
>> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b am335x_evm_defconfig
>> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b all
>> >
>> > depending on depth of the path, this would fail.. a little bit of
>> > headscratching later..
>> > when using O= build system uses absolute paths, which translates to
>> > __FILE__ being absolute paths as well..
>> >
>> > in u-boot, any printf("%s", __FILE__) makes u-boot allocate this file
>> > path in rodata.
>> >
>> > So, depending on how deep the path is rodata size varies and ends up
>> > pushing .data out of sram max range.
>> >
>> > we dont really care to put a print of complete absolute path anyways,
>> > and I am not really sure of a clean way to resolve this:
>> > a) override __FILE__ with something.. -Wbuiltin-macro-redefined kicks in
>> > b) replace usage of __FILE__ with something like __FILENAME__ as
>> > recommended by [1]
>> >
>> >
>> > What is the suggestion we do?
>> >
>> > [1] http://stackoverflow.com/questions/8487986/file-macro-shows-full-path
>>
>> Any suggestions would be really helpful.
>
> So here's what I've come up with, and it's slightly incomplete:
> diff --git a/include/common.h b/include/common.h
> index 2cbbd5a60cd3..cdc61ef5b144 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -145,20 +145,19 @@ typedef volatile unsigned charvu_char;
>   * in any case these failing assertions cannot be fixed with a reset (which
>   * may just do the same assertion again).
>   */
> -void __assert_fail(const char *assertion, const char *file, unsigned line,
> -  const char *function);
> +void __assert_fail(const char *assertion, unsigned line, const char 
> *function);
>  #define assert(x) \
> ({ if (!(x) && _DEBUG) \
> -   __assert_fail(#x, __FILE__, __LINE__, __func__); })
> +   __assert_fail(#x, __LINE__, __func__); })
>
>  #define error(fmt, args...) do {   \
> -   printf("ERROR: " pr_fmt(fmt) "\nat %s:%d/%s()\n",   \
> -   ##args, __FILE__, __LINE__, __func__);  \
> +   printf("ERROR: " pr_fmt(fmt) "\nat %s():%d\n",  \
> +   ##args, __func__, __LINE__);\
>  } while (0)
>
>  #ifndef BUG
>  #define BUG() do { \
> -   printf("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, 
> __FUNCTION__); \
> +   printf("BUG: failure at %s():%d!\n", __FUNCTION__, __LINE__); \
> panic("BUG!"); \
>  } while (0)
>  #define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); } 
> while(0)
> diff --git a/include/image.h b/include/image.h
> index 237251896029..a52c5355376e 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1218,12 +1218,12 @@ static inline int fit_image_check_target_arch(const 
> void *fdt, int node)
>  #ifdef CONFIG_FIT_VERBOSE
>  #define fit_unsupported(msg)   printf("! %s:%d " \
> "FIT images not supported for '%s'\n", \
> -   __FILE__, __LINE__, (msg))
> +   __func__, __LINE__, (msg))
>
>  #define fit_unsupported_reset(msg) printf("! %s:%d " \
> "FIT images not supported for '%s' " \
> "- must reset board to recover!\n", \
> -   __FILE__, __LINE__, (msg))
> +   __func__, __LINE__, (msg))
>  #else
>  #define 

Re: [U-Boot] [PATCH v2 09/10] dm: scsi: fix divide-by-0 error in scsi_scan()

2017-04-09 Thread Simon Glass
Hi,

On 7 April 2017 at 05:42, Jean-Jacques Hiblot  wrote:
> With DM_SCSI enabled, blk_create_devicef() is called with blkz = 0, leading
> to a divide-by-0 exception.
> scsi_detect_dev() can be used to get the required parameters (block size
> and number of blocks) from the drive before calling blk_create_devicef().
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  common/scsi.c | 35 ++-
>  1 file changed, 26 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 

Please see below.

>
> diff --git a/common/scsi.c b/common/scsi.c
> index 972ef338..d37222c 100644
> --- a/common/scsi.c
> +++ b/common/scsi.c
> @@ -580,9 +580,19 @@ int scsi_scan(int mode)
> for (lun = 0; lun < plat->max_lun; lun++) {
> struct udevice *bdev; /* block device */
> /* block device description */
> +   struct blk_desc _bd;
> struct blk_desc *bdesc;
> char str[10];
>
> +   scsi_init_dev_desc_priv(&_bd);
> +   ret = scsi_detect_dev(i, lun, &_bd);
> +   if (ret)
> +   /*
> +* no device detected?
> +* check the next lun.
> +*/
> +   continue;
> +
> /*
>  * Create only one block device and do 
> detection
>  * to make sure that there won't be a lot of
> @@ -590,20 +600,27 @@ int scsi_scan(int mode)
>  */
> snprintf(str, sizeof(str), "id%dlun%d", i, 
> lun);
> ret = blk_create_devicef(dev, "scsi_blk",
> - str, IF_TYPE_SCSI,
> - -1, 0, 0, );
> +   str, IF_TYPE_SCSI,
> +   -1,
> +   _bd.blksz,
> +   _bd.blksz * _bd.lba,
> +   );
> if (ret) {
> debug("Can't create device\n");
> return ret;
> }
> -   bdesc = dev_get_uclass_platdata(bdev);
>
> -   scsi_init_dev_desc_priv(bdesc);
> -   ret = scsi_detect_dev(i, lun, bdesc);
> -   if (ret) {
> -   device_unbind(bdev);
> -   continue;
> -   }
> +   bdesc = dev_get_uclass_platdata(bdev);
> +   bdesc->target = i;
> +   bdesc->lun = lun;
> +   bdesc->removable = _bd.removable;
> +   bdesc->type = _bd.type;
> +   memcpy(>vendor, &_bd.vendor,
> +  sizeof(_bd.vendor));
> +   memcpy(>product, &_bd.product,
> +  sizeof(_bd.product));
> +   memcpy(>revision, &_bd.revision,
> +  sizeof(_bd.revision));

Can you please move this block (inside the double for loops) into a
separate function? It is getting too long. A follow-up patch is fine
since you have already done this.

> part_init(bdesc);
>
> if (mode == 1) {
> --
> 1.9.1
>

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


Re: [U-Boot] [PATCH v4 0/7] board: sama5d4: convert boards to support DM/DT

2017-04-09 Thread Simon Glass
+Tom

Hi,

On 7 April 2017 at 01:28, Yang, Wenyou  wrote:
> Hi Andreas,
>
> Could you help find a time to take these patch series?
>
> They are here for a long time.
>

Tom might be able to take it, or if not I could bring it in via DM I
suppose, since it is a conversion.

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


Re: [U-Boot] [PATCH v2 2/4] enf_sf: reuse setup_flash_device instead of open coding it

2017-04-09 Thread Simon Glass
On 8 April 2017 at 03:59, Andreas Fenkart  wrote:
> setup_flash_device selects one of two code paths depending on the driver
> model being used (=CONFIG_DM_SPI_FLASH). env_relocate_spec only used
> the non driver-model code path. I'm unsure why, either none of the
> platforms that need relocation use the driver model, or - worse - the
> driver model is not yet usable when relocating.
>
> Signed-off-by: Andreas Fenkart 
> ---
>  common/env_sf.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)

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


Re: [U-Boot] [PATCH] dts: rk3399-puma: make the DTS dual-licensed

2017-04-09 Thread Simon Glass
On 7 April 2017 at 11:09, Philipp Tomsich
 wrote:
> The RK3399-Q7 (Puma) DTS should (of course) be dual-licensed.
> This updates the licensing info in the rk3399-puma.dts.
>
> Signed-off-by: Philipp Tomsich 
>
> ---
>
>  arch/arm/dts/rk3399-puma.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 03/10] drivers: phy: add generic PHY framework

2017-04-09 Thread Simon Glass
Hi,

On 7 April 2017 at 05:42, Jean-Jacques Hiblot  wrote:
> The PHY framework provides a set of APIs to control a PHY. This API is
> derived from the linux version of the generic PHY framework.
> Currently the API supports init(), deinit(), power_on, power_off() and
> reset(). The framework provides a way to get a reference to a phy from the
> device-tree.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  Makefile |  1 +
>  drivers/Kconfig  |  2 ++
>  drivers/Makefile |  1 +
>  drivers/phy/Kconfig  | 22 ++
>  drivers/phy/Makefile |  5 
>  drivers/phy/phy-uclass.c | 77 
> 
>  include/dm/uclass-id.h   |  1 +
>  include/generic-phy.h| 38 
>  8 files changed, 147 insertions(+)
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-uclass.c
>  create mode 100644 include/generic-phy.h

Can you please create a sandbox driver and a test?

>
> diff --git a/Makefile b/Makefile
> index 2638acf..06454ce 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -650,6 +650,7 @@ libs-y += fs/
>  libs-y += net/
>  libs-y += disk/
>  libs-y += drivers/
> +libs-y += drivers/phy/

Could this go in drivers/Makefile?

>  libs-y += drivers/dma/
>  libs-y += drivers/gpio/
>  libs-y += drivers/i2c/
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 0e5d97d..a90ceca 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -88,6 +88,8 @@ source "drivers/video/Kconfig"
>
>  source "drivers/watchdog/Kconfig"
>
> +source "drivers/phy/Kconfig"
> +
>  config PHYS_TO_BUS
> bool "Custom physical to bus address mapping"
> help
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 5d8baa5..4656509 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
>  obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
>  obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
>  obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
> +obj-$(CONFIG_SPL_GENERIC_PHY) += phy/
>  endif
>
>  ifdef CONFIG_TPL_BUILD
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> new file mode 100644
> index 000..b6fed9e
> --- /dev/null
> +++ b/drivers/phy/Kconfig
> @@ -0,0 +1,22 @@
> +
> +menu "PHY Subsystem"
> +
> +config GENERIC_PHY

Just a question: do you think we need the word GENERIC in this config?
I'm OK with it, but wonder if CONFIG_PHY would be enough?

> +   bool "PHY Core"
> +   depends on DM
> +   help
> + Generic PHY support.
> +
> + This framework is designed to provide a generic interface for PHY
> + devices.

Could you given a few examples of PHY devices and the types of
operations you can perform on them.

> +
> +config SPL_GENERIC_PHY
> +   bool "PHY Core in SPL"
> +   depends on DM
> +   help
> + Generic PHY support in SPL.
> +
> + This framework is designed to provide a generic interface for PHY
> + devices.
> +
> +endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> new file mode 100644
> index 000..ccd15ed
> --- /dev/null
> +++ b/drivers/phy/Makefile
> @@ -0,0 +1,5 @@
> +obj-$(CONFIG_$(SPL_)GENERIC_PHY) += phy-uclass.o
> +
> +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> +obj-y += marvell/
> +endif
> diff --git a/drivers/phy/phy-uclass.c b/drivers/phy/phy-uclass.c
> new file mode 100644
> index 000..4d1584d
> --- /dev/null
> +++ b/drivers/phy/phy-uclass.c
> @@ -0,0 +1,77 @@
> +/*
> + * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
> + * Written by Jean-Jacques Hiblot  
> + *
> + * 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.

SPDX?

> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define get_ops(dev)((struct generic_phy_ops *)(dev)->driver->ops)
> +
> +#define generic_phy_to_dev(x) ((struct udevice *)(x))
> +#define dev_to_generic_phy(x) ((struct generic_phy *)(x))
> +
> +struct generic_phy *dm_generic_phy_get(struct udevice *dev, const char 
> *string)
> +{
> +   struct udevice *generic_phy_dev;

dev is a shorter name :-)

> +
> +   int rc = uclass_get_device_by_phandle(UCLASS_PHY, dev,
> +  string, _phy_dev);
> +   if (rc) {
> +   error("unable to find generic_phy device %d\n", rc);
> +   return ERR_PTR(rc);
> +   }
> +   return dev_to_generic_phy(generic_phy_dev);
> +}
> +
> +int generic_phy_init(struct generic_phy *generic_phy)
> +{
> +   struct udevice *dev = generic_phy_to_dev(generic_phy);
> +   struct generic_phy_ops *ops = get_ops(dev);
> +
> +   return (ops && ops->init) ? ops->init(dev) : 0;
> +}
> +
> +int generic_phy_reset(struct generic_phy *generic_phy)
> +{
> 

Re: [U-Boot] [PATCH] power: regulator: pwm: support pwm polarity setting

2017-04-09 Thread Simon Glass
Hi,

On 7 April 2017 at 05:02, Kever Yang  wrote:
> The latest kernel PWM drivers enable the polarity settings. When system
> run from U-Boot to kerenl, if there are differences in polarity set or
> duty cycle, the PMW will re-init:
>   close -> set polarity and duty cycle -> enable the PWM.
> The power supply controled by pwm regulator may have voltage shaking,
> which lead to the system not stable.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/power/regulator/pwm_regulator.c | 12 ++--
>  drivers/pwm/pwm-uclass.c| 10 ++
>  drivers/pwm/rk_pwm.c| 17 -
>  include/pwm.h   |  9 +
>  4 files changed, 45 insertions(+), 3 deletions(-)

If the generic uclass change and the rk change can be separated, it is
good to do it.

Also we should have a test for pwm (test/dm/pwm.c). Are you able to do
that? If not I could give it a try.

>
> diff --git a/drivers/power/regulator/pwm_regulator.c 
> b/drivers/power/regulator/pwm_regulator.c
> index 4875238..f8a6712 100644
> --- a/drivers/power/regulator/pwm_regulator.c
> +++ b/drivers/power/regulator/pwm_regulator.c
> @@ -24,6 +24,8 @@ struct pwm_regulator_info {
> int pwm_id;
> /* the period of one PWM cycle */
> int period_ns;
> +   /* the polarity of one PWM */
> +   int polarity;

Can you update the comment to indicate what the values mean? E.g. is 0
the normal polarity and 1 inverted?

> struct udevice *pwm;
> /* initialize voltage of regulator */
> unsigned int init_voltage;
> @@ -49,7 +51,7 @@ static int pwm_voltage_to_duty_cycle_percentage(struct 
> udevice *dev, int req_uV)
> int max_uV = priv->max_voltage;
> int diff = max_uV - min_uV;
>
> -   return 100 - (((req_uV * 100) - (min_uV * 100)) / diff);
> +   return ((req_uV * 100) - (min_uV * 100)) / diff;
>  }
>
>  static int pwm_regulator_get_voltage(struct udevice *dev)
> @@ -67,6 +69,12 @@ static int pwm_regulator_set_voltage(struct udevice *dev, 
> int uvolt)
>
> duty_cycle = pwm_voltage_to_duty_cycle_percentage(dev, uvolt);
>
> +   ret = pwm_set_init(priv->pwm, priv->pwm_id, priv->polarity);

I wonder if it would be better to combine the polarity into the
pwm_set_config() call? Then we can do everything in one call. If not
then I think pwm_set_invert() would be a better name.

> +   if (ret) {
> +   dev_err(dev, "Failed to init PWM\n");
> +   return ret;
> +   }
> +
> ret = pwm_set_config(priv->pwm, priv->pwm_id,
> (priv->period_ns / 100) * duty_cycle, 
> priv->period_ns);
> if (ret) {
> @@ -97,9 +105,9 @@ static int pwm_regulator_ofdata_to_platdata(struct udevice 
> *dev)
> debug("%s: Cannot get PWM phandle: ret=%d\n", __func__, ret);
> return ret;
> }
> -   /* TODO: pwm_id here from device tree if needed */
>
> priv->period_ns = args.args[1];
> +   priv->polarity = args.args[2];

Does this mean that the binding has this argument and we have been ignoring it?

Can you bring in the DT binding file from Linux to U-Boot also?

>
> priv->init_voltage = fdtdec_get_int(blob, node,
> "regulator-init-microvolt", -1);
> diff --git a/drivers/pwm/pwm-uclass.c b/drivers/pwm/pwm-uclass.c
> index c2200af..287a7f3 100644
> --- a/drivers/pwm/pwm-uclass.c
> +++ b/drivers/pwm/pwm-uclass.c
> @@ -9,6 +9,16 @@
>  #include 
>  #include 
>
> +int pwm_set_init(struct udevice *dev, uint channel, uint polarity)
> +{
> +   struct pwm_ops *ops = pwm_get_ops(dev);
> +
> +   if (!ops->set_init)
> +   return -ENOSYS;
> +
> +   return ops->set_init(dev, channel, polarity);
> +}
> +
>  int pwm_set_config(struct udevice *dev, uint channel, uint period_ns,
>uint duty_ns)
>  {
> diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
> index 9254f5b..5ff1e00 100644
> --- a/drivers/pwm/rk_pwm.c
> +++ b/drivers/pwm/rk_pwm.c
> @@ -21,8 +21,22 @@ DECLARE_GLOBAL_DATA_PTR;
>  struct rk_pwm_priv {
> struct rk3288_pwm *regs;
> ulong freq;
> +   uint enable_conf;
>  };
>
> +static int rk_pwm_set_init(struct udevice *dev, uint channel, uint polarity)
> +{
> +   struct rk_pwm_priv *priv = dev_get_priv(dev);
> +
> +   debug("%s: polarity=%u\n", __func__, polarity);
> +   if (polarity)
> +   priv->enable_conf |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSTIVE;
> +   else
> +   priv->enable_conf |= PWM_DUTY_POSTIVE | PWM_INACTIVE_NEGATIVE;
> +
> +   return 0;
> +}
> +
>  static int rk_pwm_set_config(struct udevice *dev, uint channel, uint 
> period_ns,
>  uint duty_ns)
>  {
> @@ -32,7 +46,7 @@ static int rk_pwm_set_config(struct udevice *dev, uint 
> channel, uint period_ns,
>
> debug("%s: period_ns=%u, duty_ns=%u\n", 

Re: [U-Boot] [PATCH v2] ARM64: rockchip: split RK3399-Q7 board off the RK3399-EVB board

2017-04-09 Thread Simon Glass
On 7 April 2017 at 11:13, Philipp Tomsich
 wrote:
> From: Klaus Goger 
>
> The RK3399-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
> connector) system-on-module from Theobroma Systems, featuring the
> Rockchip RK3399.
>
> It provides the following feature set:
>  * up to 4GB DDR3
>  * on-module SPI-NOR flash
>  * on-module eMMC (with 8-bit interace)
>  * SD card (on a baseboad) via edge connector
>  * Gigabit Ethernet w/ on-module Micrel KSZ9031 GbE PHY
>  * HDMI/eDP/MIPI displays
>  * 2x MIPI-CSI
>  * USB
>- 1x USB 3.0 dual-role (direct connection)
>- 2x USB 3.0 host + 1x USB 2.0 (on-module USB 3.0 hub)
>  * on-module STM32 Cortex-M0 companion controller, implementing:
>- low-power RTC functionality (ISL1208 emulation)
>- fan controller (AMC6821 emulation)
>- USB<->CAN bridge controller
>
> Note that we use a multi-payload FIT image for booting and have
> Cortex-M0 payload in a separate subimage: we thus rely on the FIT
> image loader to put it into the SRAM region that ATF expects it in.
>
> Signed-off-by: Klaus Goger 
> Signed-off-by: Philipp Tomsich 
> ---
>
> Changes in v2:
> - fixes dram_init_banksize() to have the correct return type and to
>   return 0 (success) unconditionally
>
>  arch/arm/mach-rockchip/rk3399/Kconfig  | 19 ++
>  board/theobroma-systems/puma_rk3399/Kconfig| 15 +
>  board/theobroma-systems/puma_rk3399/MAINTAINERS| 10 +++
>  board/theobroma-systems/puma_rk3399/Makefile   |  7 +++
>  board/theobroma-systems/puma_rk3399/README | 73 
> ++
>  .../theobroma-systems/puma_rk3399/fit_spl_atf.its  | 57 +
>  board/theobroma-systems/puma_rk3399/puma-rk3399.c  | 71 +
>  configs/puma-rk3399_defconfig  |  3 +-
>  include/configs/puma_rk3399.h  | 26 
>  9 files changed, 280 insertions(+), 1 deletion(-)
>  create mode 100644 board/theobroma-systems/puma_rk3399/Kconfig
>  create mode 100644 board/theobroma-systems/puma_rk3399/MAINTAINERS
>  create mode 100644 board/theobroma-systems/puma_rk3399/Makefile
>  create mode 100644 board/theobroma-systems/puma_rk3399/README
>  create mode 100644 board/theobroma-systems/puma_rk3399/fit_spl_atf.its
>  create mode 100644 board/theobroma-systems/puma_rk3399/puma-rk3399.c
>  create mode 100644 include/configs/puma_rk3399.h

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


Re: [U-Boot] [PATCH 2/4] dm: core: Add DM_FLAG_PRE_OS_FINALIZE flag

2017-04-09 Thread Simon Glass
Hi Stefan,

On 6 April 2017 at 07:29, Stefan Roese  wrote:
> This new flag can be added to DM device drivers, which need to do some
> final configuration before U-Boot exits and the OS (e.g. Linux) is
> started. The remove functions of those drivers will get called at
> this stage to do these last-stage configuration steps.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  drivers/core/device-remove.c | 17 -
>  include/dm/device.h  | 11 ++-
>  2 files changed, 22 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 

You could perhaps have a separate patch to move the code into
flags_remove(), but I suppose it isn't important.

nit below.

>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 8b46f3343e..390be5a0d8 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -148,6 +148,16 @@ void device_free(struct udevice *dev)
> devres_release_probe(dev);
>  }
>
> +static int flags_remove(uint flags, uint drv_flags)

Can this be bool, and return true/false?

> +{
> +   if ((flags & DM_REMOVE_NORMAL) ||
> +   (flags & (drv_flags &
> + (DM_FLAG_ACTIVE_DMA | DM_FLAG_PRE_OS_FINALIZE

What do you think about OS_PREPARE instead? It doesn't really finalize the OS...

> +   return 1;
> +
> +   return 0;
> +}
> +
>  int device_remove(struct udevice *dev, uint flags)
>  {
> const struct driver *drv;
> @@ -174,9 +184,7 @@ int device_remove(struct udevice *dev, uint flags)
>  * Remove the device if called with the "normal" remove flag set,
>  * or if the remove flag matches any of the drivers remove flags
>  */
> -   if (drv->remove &&
> -   ((flags & DM_REMOVE_NORMAL) ||
> -(flags & (drv->flags & DM_FLAG_ACTIVE_DMA {
> +   if (drv->remove && flags_remove(flags, drv->flags)) {
> ret = drv->remove(dev);
> if (ret)
> goto err_remove;
> @@ -190,8 +198,7 @@ int device_remove(struct udevice *dev, uint flags)
> }
> }
>
> -   if ((flags & DM_REMOVE_NORMAL) ||
> -   (flags & (drv->flags & DM_FLAG_ACTIVE_DMA))) {
> +   if (flags_remove(flags, drv->flags)) {
> device_free(dev);
>
> dev->seq = -1;
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 079ec57003..c49b8e688e 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -55,6 +55,12 @@ struct driver_info;
>  #define DM_FLAG_ACTIVE_DMA (1 << 9)
>
>  /*
> + * Call driver remove function to do some final configuration, before
> + * U-Boot exits and the OS is started
> + */
> +#define DM_FLAG_PRE_OS_FINALIZE(1 << 10)
> +
> +/*
>   * One or multiple of these flags are passed to device_remove() so that
>   * a selective device removal as specified by the remove-stage and the
>   * driver flags can be done.
> @@ -66,10 +72,13 @@ enum {
> /* Remove devices with active DMA */
> DM_REMOVE_ACTIVE_DMA = DM_FLAG_ACTIVE_DMA,
>
> +   /* Remove devices which need some pre-OS finalization */
> +   DM_REMOVE_PRE_OS_FINALIZE = DM_FLAG_PRE_OS_FINALIZE,
> +
> /* Add more use cases here */
>
> /* Remove devices with any active flag */
> -   DM_REMOVE_ACTIVE_ALL = DM_REMOVE_ACTIVE_DMA,
> +   DM_REMOVE_ACTIVE_ALL = DM_REMOVE_ACTIVE_DMA | 
> DM_REMOVE_PRE_OS_FINALIZE,
>  };
>
>  /**
> --
> 2.12.2
>

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


Re: [U-Boot] [PATCH] tools: allow to override python

2017-04-09 Thread Simon Glass
On 5 April 2017 at 09:46, Stefano Babic  wrote:
> Not force to use python from PATH. Issue was noted when building with
> Yocto, because python from the distro is always taken instead of
> python-native built during Yocto process.
>
> Signed-off-by: Stefano Babic 
> CC: Simon Glass 
> ---
>  Makefile   | 2 +-
>  tools/Makefile | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

FYI the proper setup.py support just landed upstream so we could move
to using that to build _libfdt.so

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


Re: [U-Boot] [EXT] Re: [PATCH 7/7] scsi: dts: a3700: add scsi node

2017-04-09 Thread Simon Glass
Hi Ken,

On 5 April 2017 at 19:32, Ken Ma  wrote:
> Hi Stefan
>
> Please see my inline reply, thanks!
>
> Yours,
> Ken
>
> -Original Message-
> From: Stefan Roese [mailto:s...@denx.de]
> Sent: 2017年4月5日 21:46
> To: Ken Ma; Simon Glass
> Cc: u-boot@lists.denx.de; Michal Simek; Kostya Porotchkin; Hua Jing; Wilson 
> Ding
> Subject: Re: [EXT] Re: [PATCH 7/7] scsi: dts: a3700: add scsi node
>
> Hi Ken,
>
> On 05.04.2017 11:29, Ken Ma wrote:
>> Hi Stefan, Hi Simon
>>
>> Please see my inline reply, thanks!
>>
>> Yours,
>> Ken
>>
>> -Original Message-
>> From: Stefan Roese [mailto:s...@denx.de]
>> Sent: 2017年4月3日 14:14
>> To: Simon Glass; Ken Ma
>> Cc: u-boot@lists.denx.de; Michal Simek; Kostya Porotchkin; Hua Jing;
>> Wilson Ding
>> Subject: Re: [EXT] Re: [PATCH 7/7] scsi: dts: a3700: add scsi node
>>
>> Hi Simon, Hi Ken,
>>
>> On 01.04.2017 06:22, Simon Glass wrote:
>>> On 27 March 2017 at 02:28, Ken Ma  wrote:
 Hi Stefan



 Thanks a lot for your kind reply.



 But I still do not think it's very good to change sata's uclass id
 from "UCLASS_AHCI" to "UCLASS_SCSI".

 If we do such change, UCLASS_AHCI is lost since from the sata.c
 codes, it does the AHCI initialization work but not SCSI initialization 
 work.

 If u-boot supports ISIS scanner which supports SCSI, I think its
 uclass id should be like UCLASS_ISIS but not UCLASS_SCSI.

 And if we set sata's uclass id as "UCLASS_SCSI", it should provide
 basic SCSI function, then why can’t we connect a parallel SCSI
 device like SCSI scanner or cd-rom to the SATA interface?

 From https://en.wikipedia.org/wiki/Serial_ATA#SATA_and_SCSI

 In general, SATA devices link compatibly to SAS enclosures and
 adapters, whereas SCSI devices cannot be directly connected to a
 SATA bus





 Actually Marvell’s sata controller is SAS(Serial Attached SCSI
 system), it integrates SCSI and SATA(AHCI); SAS provides a SCSI bus
 which works only in SAS range(for example, 2 sata ports in SAS), so
 actually the SCSI bus controller is not "virtual" controllers but
 has the same device base register as SATA.



 From https://en.wikipedia.org/wiki/Serial_Attached_SCSI

 A typical Serial Attached SCSI system consists of the following
 basic
 components:

 1.An initiator: a device that originates device-service and
 task-management requests for processing by a target device and
 receives responses for the same requests from other target devices.
 Initiators may be provided as an on-board component on the
 motherboard (as is the case with many server-oriented motherboards) or as 
 an add-on host bus adapter.

 2.A target: …

 So in my opinion, there are two ways to implement SAS as below

 A.  If our codes provide SAS controller as an on-board component –
 then a uclass id of UCLASS_SAS should be defined and then in
 scsi_scan() of scsi_scan.c, both devices of UCLASS_SCSI and UCLASS_SAS 
 should be scanned.
 In such implementation, UCLASS_SCSI is for parallel SCSI while
 UCLASS_SAS is for serial attached SCSI;

 B.  SAS works as an add-on host bus adapter as above said, SAS’s
 SCSI controller and AHCI controller are both itself as below - SCSI
 controller is not a virtual device, it exists and only works in SAS
 internal range(since there is no UCLASS_SAS, I take this way);

 Although the SAS’s SCSI controller does not need to any special
 hardware configuration; but actually I think there is something to
 do, we should bind special scsi_exec() to SCSI devices in SCSI
 driver or SAS driver (For different SCSI controls, SAS must have
 different implementation of
 scsi_exec() comparing to SCSI scanner, or other SCSI devices)

 By the way, I think we should move the work of creating block
 devices to scsi-uclass.c

 scsi: scsi@e {

 compatible = "marvell,mvebu-scsi";

 reg = <0xe 0x2000>;

 sata: sata@e {

   compatible =
 "marvell,armada-3700-ahci";

   reg = <0xe 0x2000>;

   interrupts = >>> IRQ_TYPE_LEVEL_HIGH>;

 };
>>>
>>> Does this match the Linux DT?
>>
>> No, and this is my main concern. This patch series introduces a new
>> "scsi" DT node and moves the controller(s) one level up into this
>> newly created DT node (Ken please correct me if I'm wrong here).
>> We simply can't make such changes here in U-Boot without this being
>> first discussed and decided on the Linux DT mailing list with the DT
>> maintainers.
>>
>> Ken, how is this problem solved / handled in Linux without this DT

Re: [U-Boot] [PATCH] core/uclass: Print name of device in uclass_find_device_by_seq()

2017-04-09 Thread Simon Glass
On 4 April 2017 at 11:46, Alexandru Gagniuc  wrote:
> uclass_find_device_by_seq() prints seq and req_seq when debugging is
> enabled, but this information is not very useful by itself. Add the
> name of he driver to this information. This improves debugging as it
> shows which devices are being considered.
>
> Signed-off-by: Alexandru Gagniuc 
> ---
>  drivers/core/uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 01/10] image: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

2017-04-09 Thread Simon Glass
On 7 April 2017 at 09:00, Andrew F. Davis  wrote:
> From: Madan Srinivas 
>
> The function 'board_fit_image_post_process' is defined only when the
> config option CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure
> systems that do not use SPL but do use FIT kernel images, only
> CONFIG_FIT_IMAGE_POST_PROCESS will be defined, which will result in an
> implicit declaration of function 'board_fit_image_post_process' warning
> while building u-boot. Fix this warning.
>
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Tom Rini 
> ---
>  include/image.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 4/4] env_sf: use DIV_ROUND_UP to calculate number of sectors to erase

2017-04-09 Thread Simon Glass
On 8 April 2017 at 03:59, Andreas Fenkart  wrote:
> simpler to read
>
> Signed-off-by: Andreas Fenkart 
> ---
>  common/env_sf.c | 18 +-
>  1 file changed, 5 insertions(+), 13 deletions(-)

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


Re: [U-Boot] [PATCH] rockchip: arm: halt when enable bucks of PMIC rk808

2017-04-09 Thread Simon Glass
Hi Eric,

On 6 April 2017 at 00:58, Eric Gao  wrote:
> From: "Eric Gao" 
>
> when enable PMIC rk808,the system will halt at very
>  early stage,log is shown as bellow.
>
> INFO:plat_rockchip_pmu_init(1211): pd status 3e
> INFO:BL31: Initializing runtime services
> INFO:BL31: Preparing for EL3 exit to normal world
> INFO:Entry point address = 0x20
> INFO:SPSR = 0x3c9
> time 44561b, 0 (<
> It's caused by the absence of "{ }" in syscon_rk3399.c
> ,which will lead to memory overflow like below.According
>  to Sysmap file ,we can find the function buck_get_value
> of rk808 is just follow the compatible struct,the pointer
> "of_match" point to "buck_get_value",but it is not a
> struct and don't have member of compatible, In this case,
> system crash. So,on the face, it looks like that rk808 is
> guilty.but he is really innocent.
>
> while (of_match->compatible) { <<--
> if (!strcmp(of_match->compatible, compat)) {
> *of_idp = of_match;
> return 0;
> }
> of_match++;
> }

Great description, but for your commit title, could you say something
like 'rockchip: rk3399: Add missing sentinel in syscon'?

Your current message suggests that you are trying to halt the board.

>
> Signed-off-by: eric.gao 
> Signed-off-by: Eric Gao 

Some inconsistency here. Can you use the same capital letters?

> ---
>
>  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> index d32985b..74d4552 100644
> --- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> @@ -14,6 +14,7 @@ static const struct udevice_id rk3399_syscon_ids[] = {
> { .compatible = "rockchip,rk3399-pmugrf", .data = 
> ROCKCHIP_SYSCON_PMUGRF },
> { .compatible = "rockchip,rk3399-pmusgrf", .data = 
> ROCKCHIP_SYSCON_PMUSGRF },
> { .compatible = "rockchip,rk3399-cic", .data = ROCKCHIP_SYSCON_CIC },
> +   { }
>  };
>
>  U_BOOT_DRIVER(syscon_rk3399) = {
> --
> 1.9.1
>
>

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


Re: [U-Boot] [PATCH] rockchip: rk3399: defconfig: add CONFIG_OF_EMBED support

2017-04-09 Thread Simon Glass
Hi Kever,

On 7 April 2017 at 04:35, Kever Yang  wrote:
> Need to enablt CONFIG_OF_EMBED if we use separate uboot and dtb
> in FIT image for SPL loading.
>

Can you please explain that a bit more? We shouldn't OF_EMBED in
production code, only for debug/test.

> Run make savedefconfig to make the options order correct.
>
> Signed-off-by: Kever Yang 
> ---
>
>  configs/evb-rk3399_defconfig | 43 ---
>  1 file changed, 20 insertions(+), 23 deletions(-)

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


Re: [U-Boot] [PATCH v2 08/18] dm: gpio: Add driver for stm32f7 gpio controller

2017-04-09 Thread Simon Glass
Hi Vikas,

On 4 April 2017 at 15:45, Vikas Manocha  wrote:
> This patch adds gpio driver supporting driver model for stm32f7 gpio.
>
> Signed-off-by: Vikas Manocha 
> cc: Christophe KERELLO 
> ---
>
> Changes in v2:
> - included files in correct order.
> - moved the pinctrl specific routine from gpio driver to pinctrl
> - used dev_get_addr() instead of fdtdec_get_addr_size_auto_parent() in
>   gpio driver.
> - pointed gpio name to bank name in device tree blob rather than copy.
>
>  arch/arm/include/asm/arch-stm32f7/gpio.h |  16 
>  drivers/gpio/Kconfig |   9 +++
>  drivers/gpio/Makefile|   1 +
>  drivers/gpio/stm32f7_gpio.c  | 135 
> +++
>  drivers/pinctrl/pinctrl_stm32.c  |  36 -
>  5 files changed, 196 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpio/stm32f7_gpio.c
>

Reviewed-by: Simon Glass 

But please see below.

> diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h 
> b/arch/arm/include/asm/arch-stm32f7/gpio.h
> index 2942cd9..5c0300f 100644
> --- a/arch/arm/include/asm/arch-stm32f7/gpio.h
> +++ b/arch/arm/include/asm/arch-stm32f7/gpio.h
> @@ -96,6 +96,22 @@ struct stm32_gpio_ctl {
> enum stm32_gpio_af  af;
>  };
>
> +struct stm32_gpio_regs {
> +   u32 moder;  /* GPIO port mode */
> +   u32 otyper; /* GPIO port output type */
> +   u32 ospeedr;/* GPIO port output speed */
> +   u32 pupdr;  /* GPIO port pull-up/pull-down */
> +   u32 idr;/* GPIO port input data */
> +   u32 odr;/* GPIO port output data */
> +   u32 bsrr;   /* GPIO port bit set/reset */
> +   u32 lckr;   /* GPIO port configuration lock */
> +   u32 afr[2]; /* GPIO alternate function */
> +};
> +
> +struct stm32_gpio_priv {
> +   struct stm32_gpio_regs *regs;
> +};
> +
>  static inline unsigned stm32_gpio_to_port(unsigned gpio)
>  {
> return gpio / 16;
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 8d9ab52..c8af398 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -151,6 +151,15 @@ config PIC32_GPIO
> help
>   Say yes here to support Microchip PIC32 GPIOs.
>
> +config STM32F7_GPIO
> +   bool "ST STM32 GPIO driver"
> +   depends on DM_GPIO
> +   default y
> +   help
> + Device model driver support for STM32 GPIO controller. It should be
> + usable on many stm32 families like stm32f4 & stm32H7.
> + Tested on STM32F7.
> +
>  config MVEBU_GPIO
> bool "Marvell MVEBU GPIO driver"
> depends on DM_GPIO && ARCH_MVEBU
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 8939226..9c2a9cc 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -49,6 +49,7 @@ oby-$(CONFIG_SX151X)  += sx151x.o
>  obj-$(CONFIG_SUNXI_GPIO)   += sunxi_gpio.o
>  obj-$(CONFIG_LPC32XX_GPIO) += lpc32xx_gpio.o
>  obj-$(CONFIG_STM32_GPIO)   += stm32_gpio.o
> +obj-$(CONFIG_STM32F7_GPIO) += stm32f7_gpio.o
>  obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o
>  obj-$(CONFIG_ZYNQ_GPIO)+= zynq_gpio.o
>  obj-$(CONFIG_VYBRID_GPIO)  += vybrid_gpio.o
> diff --git a/drivers/gpio/stm32f7_gpio.c b/drivers/gpio/stm32f7_gpio.c
> new file mode 100644
> index 000..5ab1c5c
> --- /dev/null
> +++ b/drivers/gpio/stm32f7_gpio.c
> @@ -0,0 +1,135 @@
> +/*
> + * (C) Copyright 2017
> + * Vikas Manocha, 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 

common.h should always be first

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +

[..]

> diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
> index aa2c440..e5b6b3b 100644
> --- a/drivers/pinctrl/pinctrl_stm32.c
> +++ b/drivers/pinctrl/pinctrl_stm32.c
> @@ -1,10 +1,44 @@
>  #include 
> -#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#define MODE_BITS_MASK 3
> +#define OSPEED_MASK3
> +#define PUPD_MASK  3
> +#define OTYPE_MSK  1
> +#define AFR_MASK   0xF
> +
> +int stm32_gpio_config(struct gpio_desc *desc, const struct stm32_gpio_ctl 
> *ctl)

What is this function for? It does not seem to be called.

Also we should not be exporting functions from drivers. Instead here a
pinctrl driver should be accessed via the API in pinctrl.h.

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


Re: [U-Boot] [EXT] Re: [PATCH 1/7] scsi: move base, max_lun and max_id to uclass plat data

2017-04-09 Thread Simon Glass
Hi Ken,

On 5 April 2017 at 02:38, Ken Ma  wrote:
> Hi Simon
>
> Please see my inline reply, thanks a lot!
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2017年4月1日 12:22
> To: Ken Ma
> Cc: U-Boot Mailing List; Stefan Roese; Michal Simek
> Subject: [EXT] Re: [PATCH 1/7] scsi: move base, max_lun and max_id to uclass 
> plat data
>
> External Email
>
> --
> Hi Ken,
>
> On 23 March 2017 at 03:29,   wrote:
>> From: Ken Ma 
>>
>> - The members in scsi_platdata(base, max_lun and max_id) are generic,
>>   so now they are taken from fdt by the uclass_platdata instead of
>>   platdata code upon call to post bind callback.
>>
>> Signed-off-by: Ken Ma 
>> Cc: Simon Glass 
>> Cc: Stefan Roese 
>> Cc: Michal Simek 
>> Reviewed-on: http://vgitil04.il.marvell.com:8080/35304
>> Tested-by: iSoC Platform CI 
>> Reviewed-by: Omri Itach 
>> Reviewed-by: Kostya Porotchkin 
>> ---
>>  common/scsi.c   |  2 +-
>>  drivers/block/ahci.c|  2 +-
>>  drivers/block/scsi-uclass.c | 29 +
>>  3 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/scsi.c b/common/scsi.c index fb5b407..117c682
>> 100644
>> --- a/common/scsi.c
>> +++ b/common/scsi.c
>> @@ -574,7 +574,7 @@ int scsi_scan(int mode)
>> return ret;
>>
>> /* Get controller platdata */
>> -   plat = dev_get_platdata(dev);
>> +   plat = dev_get_uclass_platdata(dev);
>>
>> for (i = 0; i < plat->max_id; i++) {
>> for (lun = 0; lun < plat->max_lun; lun++) {
>> diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c index
>> 3fa14a7..368816e 100644
>> --- a/drivers/block/ahci.c
>> +++ b/drivers/block/ahci.c
>> @@ -479,7 +479,7 @@ static int ahci_init_one(pci_dev_t dev)
>> pci_write_config_byte(dev, 0x41, 0xa1);  #endif  #else
>> -   struct scsi_platdata *plat = dev_get_platdata(dev);
>> +   struct scsi_platdata *plat = dev_get_uclass_platdata(dev);
>> probe_ent->mmio_base = (void *)plat->base;  #endif
>>
>> diff --git a/drivers/block/scsi-uclass.c b/drivers/block/scsi-uclass.c
>> index 05da6cd..3bf026b 100644
>> --- a/drivers/block/scsi-uclass.c
>> +++ b/drivers/block/scsi-uclass.c
>> @@ -11,8 +11,11 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>>  static int scsi_post_probe(struct udevice *dev)  {
>> debug("%s: device %p\n", __func__, dev); @@ -20,8 +23,34 @@
>> static int scsi_post_probe(struct udevice *dev)
>> return 0;
>>  }
>>
>> +static void scsi_ofdata_to_uclass_platdata(struct udevice *dev)
>
> Please make this return an int since functions that decode the DT should 
> return an error code.
>
>> +{
>> +   struct scsi_platdata *plat = dev_get_uclass_platdata(dev);
>> +   const void *blob = gd->fdt_blob;
>> +   int node = dev->of_offset;
>> +
>> +   plat->base = (unsigned long)dev_get_addr_ptr(dev);
>> +   plat->max_id = fdtdec_get_uint(blob,
>> +  node,
>> +  "max-id",
>> +  CONFIG_SYS_SCSI_MAX_SCSI_ID);
>> +   plat->max_lun = fdtdec_get_uint(blob,
>> +   node,
>> +   "max-lun",
>> +   CONFIG_SYS_SCSI_MAX_LUN);
>> +   return;
>
> return 0
> [Ken] got it.
>
>> +}
>> +
>> +static int scsi_post_bind(struct udevice *dev) {
>> +   /* Get uclass plat data from fdt */
>> +   scsi_ofdata_to_uclass_platdata(dev);
>
> Do we need to have this info in bind(), or could it wait until 
> of_to_platdata()?
> [Ken] Stefan shows me a patch https://patchwork.ozlabs.org/patch/743160/ , it 
> fills the two field members(max_lun and max_id) in ahci's 
> scsi_low_level_init()
> As below, I think it's OK to get active link port number in ahci_host_init(), 
> and in my opinion, it's better to be a default way to get max_lun and max_id
> in ahci driver if the two members are not set in fdt since actually max_lun * 
> max_id = ffs(linkmap) and we can also set max_lun = 2 and max_id = 
> fls(linkmap)/2;
> And another question is whther ffs() or fls() for max_id?

OK well since it doesn't take any time, I am OK with it. I'm not sure
about your last question.

>
>> +   if (plat) {
>> +   plat->max_lun = 1;
>> +   plat->max_id = ffs(linkmap);
>> +   }
>
>
> Also, return the error code here.
> [Ken] got it.
>
>> +}
>> +
>>  UCLASS_DRIVER(scsi) = {
>> .id = UCLASS_SCSI,
>> .name   = "scsi",
>> +   

Re: [U-Boot] [PATCH v2 06/10] drivers: block: dwc_ahci: Implement a driver for Synopsys DWC sata device

2017-04-09 Thread Simon Glass
On 7 April 2017 at 05:42, Jean-Jacques Hiblot  wrote:
> From: Mugunthan V N 
>
> Implement a sata driver for Synopsys DWC sata device based on
> U-boot driver model.
>
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/block/Kconfig|  10 +
>  drivers/block/Makefile   |   1 +
>  drivers/block/dwc_ahci.c | 100 
> +++
>  3 files changed, 111 insertions(+)
>  create mode 100644 drivers/block/dwc_ahci.c

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


Re: [U-Boot] [PATCH] tools: binman: Add missing filenames for various x86 rom tests

2017-04-09 Thread Simon Glass
On 4 April 2017 at 22:17, Bin Meng  wrote:
> With recent changes, some x86-specific rom tests of binman fail to
> run. Fix it by adding missing filenames in corresponding entries.
>
> Signed-off-by: Bin Meng 
> ---
>
>  tools/binman/test/30_x86-rom-me-no-desc.dts | 1 +
>  tools/binman/test/31_x86-rom-me.dts | 2 ++
>  tools/binman/test/32_intel-vga.dts  | 1 +
>  tools/binman/test/42_intel-fsp.dts  | 1 +
>  tools/binman/test/43_intel-cmc.dts  | 1 +
>  5 files changed, 6 insertions(+)

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


Re: [U-Boot] [PATCH v2 04/10] drivers: phy: add PIPE3 phy driver

2017-04-09 Thread Simon Glass
On 7 April 2017 at 05:42, Jean-Jacques Hiblot  wrote:
> This phy is found on omap platforms with sata capabilities.
> Except for the part related to the DM and the PHY framework, the code is
> basically a copy paste from arch/arm/mach-omap2/pipe3-phy.c
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/phy/Kconfig|  12 ++
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/ti-pipe3-phy.c | 368 
> +
>  3 files changed, 381 insertions(+)
>  create mode 100644 drivers/phy/ti-pipe3-phy.c
>

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


Re: [U-Boot] [PATCH v2 0/5] Patches to reduce TPL code size

2017-04-09 Thread Simon Glass
Hi Heiko,

On 4 April 2017 at 04:43, Heiko Stuebner  wrote:
> Am Dienstag, 4. April 2017, 11:34:52 CEST schrieb Heiko Stübner:
>> Am Sonntag, 2. April 2017, 09:50:27 CEST schrieb Simon Glass:
>> > With the rockchip 'rock' board some build and code size problems have come
>> > to light with TPL. This series provides a few ideas to improve things.
>>
>> great stuff!
>>
>> With these patches applied, rk3188-rock still boots and the TPL has
>> come down to 616byte on gcc-4.9 and 592bytes on gcc-6.3, so
>
> Actually, after finding out that I should add a
> # CONFIG_TPL_DM_SERIAL is not set
> to my defconfig, the size goes down even more - to 488 bytes on both
> gcc-4.9 and gcc-6.3.
>
> Still works and all.

OK great thanks for the report.

Regards,
Simon

>
>
>> Tested-by: Heiko Stuebner 
>>
>> We have like vast amounts of free space in tpl now ;-)
>>
>> I guess I should fold your TINY_MEMSET option into my rock board,
>> once you've applied the core patch?
>>
>>
>> Heiko
>>
>>
>> >
>> > Changes in v2:
>> > - Adjust the option to be SPL-only
>> > - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET)
>> > - Add a new patch to enable CONFIG_SPL_TINY_MEMSET
>> > - Add new patch to allow driver model to be disabled for TPL
>> > - Add new patch to allow driver-model serial to be disabled for TPL
>> >
>> > Simon Glass (5):
>> >   string: Provide a slimmed-down memset()
>> >   rockchip: rock: Enable CONFIG_SPL_TINY_MEMSET
>> >   Makefile: Provide an option to select SPL or TPL
>> >   dm: core: Allow driver model to be disabled for TPL
>> >   dm: serial: Allow driver-model serial to be disabled for TPL
>> >
>> >  configs/rock_defconfig  |  1 +
>> >  drivers/Makefile|  2 +-
>> >  drivers/core/Kconfig| 14 ++
>> >  drivers/serial/Kconfig  | 20 
>> >  drivers/serial/Makefile |  2 +-
>> >  lib/Kconfig |  8 
>> >  lib/string.c|  6 --
>> >  scripts/Kbuild.include  |  6 ++
>> >  scripts/Makefile.spl|  6 ++
>> >  9 files changed, 61 insertions(+), 4 deletions(-)
>>
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC] tiny-printf: Add support for %p format

2017-04-09 Thread Simon Glass
Hi Vignesh,

On 7 April 2017 at 12:12, Vignesh R  wrote:
>
>
> On 4/7/2017 8:40 PM, Tom Rini wrote:
>> On Fri, Apr 07, 2017 at 03:20:34PM +0530, Vignesh R wrote:
>>
>>> Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
>>> %pM and %pI4 are widely used by SPL networking stack and is required if
>>> networking support is desired in SPL.
>>>
>>> Before this patch:
>>> $ size spl/u-boot-spl
>>>text data bss dec hex filename
>>>   99325 4899  218584  322808   4ecf8 spl/u-boot-spl
>>>
>>> After this patch (with CONFIG_SPL_NET_SUPPORT):
>>> $ size spl/u-boot-spl
>>>text data bss dec hex filename
>>>   99714 4899  218584  323197   4ee7d spl/u-boot-spl
>>>
>>> So, this patch adds ~390 bytes to code size.
>>>
>>> If CONFIG_SPL_NET_SUPPORT is not enabled then only %p, %pa, %pap are
>>> supported, this adds ~90 bytes to code size.
>>
>> Why do we need %p/%pa/%pap?  I'm fine with adding %pM/%pm/%pI4 under
>> SPL_NET_SUPPORT as you've done.
>>
>
> Ok, I can drop support for %p/%pa/%pap. Its just that, I see debug()
> prints in SPL code that use them. If the agreement is not to worry them,
> I am fine with it.

With the next rev can you also please compare the code size with and
without tiny printf()? It's good to know that we still have a wide
margin!

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


Re: [U-Boot] [EXT] Re: [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

2017-04-09 Thread Simon Glass
Hi,

On 2 April 2017 at 05:50, Konstantin Porotchkin  wrote:
> Hi, Simon,
>
> On 04/01/2017 07:23 AM, Simon Glass wrote:
>>
>> External Email
>>
>> --
>>
>> Hi Konstanitin,
>>
>> On 30 March 2017 at 07:58, Konstantin Porotchkin 
>> wrote:
>>>
>>>
>>>
>>> On 03/30/2017 04:31 PM, Stefan Roese wrote:


 (adding Simon to Cc for PCI related question)

 On 28.03.2017 17:36, kos...@marvell.com wrote:
>
>
> From: Konstantin Porotchkin 
>
> Add PCIe initialization at early init stage.
> This operation has a side effect of detecting all PCIe
> plug-in cards, so the operator is not obligated to issue
> "pci enum" command though CLI for this purpose.



 I'm not sure, if this should be handled this way. Simon, how
 is such a default PCI scan with DM supposed to get done? Is
 there a way do do this automatically without the need that
 the user has to issue "pci enum" manually?
>>>
>>>
>>> I was not sure either, but did not see any other way of doing so.
>>> I asked to add this change by our Robot/Jenkins automation test team.
>>
>>
>> It seems reasonable. We actually have some platforms that require PCI
>> buses to be probed before we know what devices are in the system, and
>> some of these are important.
>>
>> For example, if your network controller is on PCI then U-Boot will not
>> know about it (unless you have it in the device tree) until PCI is
>> probed.
>>
>> I am wondering whether we should add a uclass flag that indicates that
>> uclass members should be automatically probed on start-up?
>>
>> It would not be set for SATA, but would be for PCI.
>
> Thank you for your explanation.
> So, as the bottom line - Can I leave the PCIe init call in place and remove
> the SATA devices walk through from this patch?
> In my case the PCIe devices should be initialized for detection of a network
> card.
>

I think we should add a new DM_UC_FLAG_AUTO_PROBE to uclass.h which
causes U-Boot to probe all devices in that uclass. This code could be
added to dm_init_and_scan(). You could set the flag for PCI. Do you
want to work up a patch for that?

This is your board code so I don't have a strong opinion on exactly
what you do here - but I'd prefer to figure out a generic solution.

> Thanks
> Kosta
>
>>


> Also convert the SATA first device scan to a walk through
> all availabel SATA devices.



 This should be done in a separate patch. But seeing this,
 won't this SATA / AHCI code be gone completely from this
 file, once this is converted into a "real" DM AHCI / SCSI
 driver (please look at my preliminary patch for this).
>>>
>>>
>>> Will check your patch, thank you.
>>> Maybe this change has to be completely removed if Simon guide me to the
>>> right solution for automatic PCIe enumeration.
>>>
>>
>> Regards,
>> Simon
>>

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


Re: [U-Boot] [PATCH 5/6] Initial support for the Android Bootloader flow

2017-04-09 Thread Simon Glass
Hi Alex,

On 2 April 2017 at 02:49, Alex Deymo  wrote:
> An Android Bootloader must comply with certain boot modes and change
> the kernel command line accordingly. This patch introduces the Android
> boot mode concept which determines whether the device should boot to
> one of the following:
>  * recovery: which should boot to the recovery image,
>  * bootloader: which should boot to the "bootloader" (fastboot) and
>  * normal: which should boot to the system image.
>
> The boot mode is determined in part by the Boot Control Block (BCB)
> which is stored at the beginning of the "misc" partition. The BCB
> is defined in the "bootloader_message.h" file in AOSP, now copied
> here as android_bootloader_message.h with minor modifications.
>
> This patch implements the basic boot flow that loads and boots an
> Android kernel image assuming an A/B device which implies that it uses
> boot as recovery (BOARD_USES_RECOVERY_AS_BOOT in the BoardConfig.mk).
> This means that the recovery image shares the same kernel with the
> normal boot system image, but stores the recovery image as a ramdisk
> which is not used in normal mode.
>
> Among the limitations, this patch doesn't implement the A/B slot
> selection, it only boots from the provided slot.
>
> Test: Booted a rpi3 with this flow.

Could we have a sandbox test for this? Set test_vboot.py for an example.

> Signed-off-by: Alex Deymo 
> ---
>  README   |  19 +-
>  common/Kconfig   |  19 ++
>  common/Makefile  |   1 +
>  common/android_bootloader.c  | 350 
> +++
>  include/android_bootloader.h |  48 +
>  include/android_bootloader_message.h | 174 +
>  6 files changed, 607 insertions(+), 4 deletions(-)
>  create mode 100644 common/android_bootloader.c
>  create mode 100644 include/android_bootloader.h
>  create mode 100644 include/android_bootloader_messa.ge.h
>

This looks pretty clean so most of my comments are style-related

> diff --git a/README b/README
> index aa907ced8a..384cc6aabb 100644
> --- a/README
> +++ b/README
> @@ -1483,6 +1483,21 @@ The following options need to be configured:
> entering dfuMANIFEST state. Host waits this timeout, before
> sending again an USB request to the device.
>
> +- Android Bootloader support:
> +   CONFIG_ANDROID_BOOTLOADER

This name seems slightly off to me. Isn't this adding Android boot
support to and existing bootloader? Perhaps CONFIG_ANDROID_BOOT? Also
I'm not quite sure what is different between this and
CONFIG_ANDROID_BOOT_IMAGE. Does this new boot method have a name by
itself? (assuming it is a boot method).

> +   This enables support for the Android bootloader flow. Android
> +   devices can boot in normal mode, recovery mode or bootloader
> +   mode. The normal mode is the most common boot mode, but
> +   recovery mode is often used to perform factory reset and OTA
> +   (over-the-air) updates in the legacy updater. Also it is
> +   possible for an Android system to request a reboot to the
> +   "bootloader", which often means reboot to fastboot but may 
> also
> +   include a UI with a menu.
> +
> +   CONFIG_ANDROID_BOOT_IMAGE
> +   This enables support for booting images which use the Android
> +   image format header.

I think it is enough to put this documentation in Kconfig. It might be
useful for have a separate README for the boot flow description.

> +
>  - USB Device Android Fastboot support:
> CONFIG_USB_FUNCTION_FASTBOOT
> This enables the USB part of the fastboot gadget
> @@ -1494,10 +1509,6 @@ The following options need to be configured:
> used on Android devices.
> See doc/README.android-fastboot for more information.
>
> -   CONFIG_ANDROID_BOOT_IMAGE
> -   This enables support for booting images which use the Android
> -   image format header.
> -
> CONFIG_FASTBOOT_BUF_ADDR
> The fastboot protocol requires a large memory buffer for
> downloads. Define this to the starting RAM address to use for
> diff --git a/common/Kconfig b/common/Kconfig
> index 8f73c8f757..47e2ffa3d6 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -393,6 +393,25 @@ config DISPLAY_BOARDINFO
>   when U-Boot starts up. The board function checkboard() is called
>   to do this.
>
> +config ANDROID_BOOTLOADER
> +   bool "Support for Android Bootloader boot flow"
> +   default n
> +   depends on ANDROID_BOOT_IMAGE
> +   help
> + If enabled, adds support to boot an Android device following the
> + Android Bootloader boot flow. This flow requires an Android 
> Bootloader
> + to 

Re: [U-Boot] [PATCH v4 00/35] ARM: i.MX6: SabreSD: Add dts support

2017-04-09 Thread Jagan Teki
On Sun, Apr 9, 2017 at 6:17 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Sun, Apr 9, 2017 at 3:52 AM, Jagan Teki  wrote:
>> This series has full possible dts support for SabreSD DualLite,
>> Quad and Quad Plus and DCD code for DualLite has added in SPL code.
>>
>> The main intention of this series is to add the dts node step
>> by step and remove the legacy code at the end and to make
>> the full functional dts.
>>
>> Preserved non-spl defconfigs, So 3 spl defconfigs and 2 non-spl defconfigs
>
> Why do we need 3 SPL defconfigs? Can't we have a single SPL defconfig
> that works for MX6Q/MX6DL/MX6QP boards?

Bcz we need to define dtb through CONFIG_DEFAULT_DEVICE_TREE

>
> Do you have a git tree with this series applied? I would like to test it.

http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/sabresd

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [v2017.03] firefly-rk3288 link failure

2017-04-09 Thread Andreas Färber
Am 09.04.2017 um 20:04 schrieb Tom Rini:
> On Sun, Apr 09, 2017 at 02:02:56PM -0400, Tom Rini wrote:
>> On Sun, Apr 09, 2017 at 03:33:47PM +0200, Andreas Färber wrote:
>>> Am 09.04.2017 um 15:21 schrieb Andreas Färber:
 Hello,

 In v2017.03 the firefly-rk3288 target fails to link with our gcc 6.3.1.
 I've tried gcc 7.0.1 (CC=gcc-7), but no change.

 [   99s]   LD  u-boot
 [   99s] ld.bfd: u-boot: Not enough room for program headers, try
 linking with -N
 [   99s] ld.bfd: final link failed: Bad value
 [   99s] make: *** [Makefile:1206: u-boot] Error 1
>>>
>>> Just checked: Same issue with tinker-rk3288.
>>>
 Is there a known fix or workaround?
>>
>> Yes, we need someone to do the equivalent of
>> https://patchwork.ozlabs.org/patch/699815/ for U-Boot (which is easier
>> since we can rely on ld-version).  I'm pretty sure when we talked about
>> this last, no one followed up with a patch.  But maybe I'm just
>> forgetting?
> 
> Yes, I am forgetting.  We have
> https://patchwork.ozlabs.org/patch/706336/ where I asked for some
> changes and no v3 happened.

I've tested it on v2017.03 with the addition you requested, and sent a
v3. I took the liberty to fix the grammar in one sentence, otherwise
unchanged.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3] Makefile: Fix linking with modern binutils

2017-04-09 Thread Andreas Färber
From: Joel Stanley 

Since Binutils 1a9ccd70f9a7[1] u-boot will not link targets that set
CONFIG_SYS_TEXT_BASE=0 with the following error:

  LD  u-boot
arm-linux-gnueabi-ld.bfd: u-boot: Not enough room for program headers, try
 linking with -N
arm-linux-gnueabi-ld.bfd: final link failed: Bad value

The issue can be reproduced with the bad binutils and the rock2_defconfig
target.

This issue was also encountered by the powerpc kernel[2], with the fix
being to pass --no-dynamic-linker for linkers newer than 2.26 when this
flag was introduced. The option tells ld that the PIE or shared lib does
not need loaded program headers.

Ubuntu Zesty's Binutils 2.27.51.20161202 hits this error.

[1] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=1a9ccd70f9a7
[2] 
https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=next=ff45000fcb56b5b0f1a14a865d3541746d838a0a

Signed-off-by: Joel Stanley 
[AF: Apply to LDFLAGS_$(SPL_BIN) as well, suggested by Tom Rini]
Signed-off-by: Andreas Färber 
---
 Makefile | 4 
 scripts/Makefile.spl | 4 
 2 files changed, 8 insertions(+)

diff --git a/Makefile b/Makefile
index ca7d60d..09b597d 100644
--- a/Makefile
+++ b/Makefile
@@ -805,6 +805,10 @@ ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
 endif
 
 LDFLAGS_u-boot += $(LDFLAGS_FINAL)
+
+# Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
+LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
+
 ifneq ($(CONFIG_SYS_TEXT_BASE),)
 LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 endif
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 760acee..eb24292 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -291,6 +291,10 @@ $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE
$(call if_changed,objcopy)
 
 LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
+
+# Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
+LDFLAGS_$(SPL_BIN) += $(call ld-option, --no-dynamic-linker)
+
 ifneq ($(CONFIG_SPL_TEXT_BASE),)
 LDFLAGS_$(SPL_BIN) += -Ttext $(CONFIG_SPL_TEXT_BASE)
 endif
-- 
2.10.2

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


Re: [U-Boot] [v2017.03] firefly-rk3288 link failure

2017-04-09 Thread Tom Rini
On Sun, Apr 09, 2017 at 02:02:56PM -0400, Tom Rini wrote:
> On Sun, Apr 09, 2017 at 03:33:47PM +0200, Andreas Färber wrote:
> > Am 09.04.2017 um 15:21 schrieb Andreas Färber:
> > > Hello,
> > > 
> > > In v2017.03 the firefly-rk3288 target fails to link with our gcc 6.3.1.
> > > I've tried gcc 7.0.1 (CC=gcc-7), but no change.
> > > 
> > > [   99s]   LD  u-boot
> > > [   99s] ld.bfd: u-boot: Not enough room for program headers, try
> > > linking with -N
> > > [   99s] ld.bfd: final link failed: Bad value
> > > [   99s] make: *** [Makefile:1206: u-boot] Error 1
> > 
> > Just checked: Same issue with tinker-rk3288.
> > 
> > > Is there a known fix or workaround?
> 
> Yes, we need someone to do the equivalent of
> https://patchwork.ozlabs.org/patch/699815/ for U-Boot (which is easier
> since we can rely on ld-version).  I'm pretty sure when we talked about
> this last, no one followed up with a patch.  But maybe I'm just
> forgetting?

Yes, I am forgetting.  We have
https://patchwork.ozlabs.org/patch/706336/ where I asked for some
changes and no v3 happened.

-- 
Tom


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


Re: [U-Boot] [v2017.03] firefly-rk3288 link failure

2017-04-09 Thread Tom Rini
On Sun, Apr 09, 2017 at 03:33:47PM +0200, Andreas Färber wrote:
> Am 09.04.2017 um 15:21 schrieb Andreas Färber:
> > Hello,
> > 
> > In v2017.03 the firefly-rk3288 target fails to link with our gcc 6.3.1.
> > I've tried gcc 7.0.1 (CC=gcc-7), but no change.
> > 
> > [   99s]   LD  u-boot
> > [   99s] ld.bfd: u-boot: Not enough room for program headers, try
> > linking with -N
> > [   99s] ld.bfd: final link failed: Bad value
> > [   99s] make: *** [Makefile:1206: u-boot] Error 1
> 
> Just checked: Same issue with tinker-rk3288.
> 
> > Is there a known fix or workaround?

Yes, we need someone to do the equivalent of
https://patchwork.ozlabs.org/patch/699815/ for U-Boot (which is easier
since we can rely on ld-version).  I'm pretty sure when we talked about
this last, no one followed up with a patch.  But maybe I'm just
forgetting?

-- 
Tom


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


[U-Boot] [PATCH] sunxi: set up PLL1 on sun6i+ without use dividers

2017-04-09 Thread Icenowy Zheng
According to the researching result of Ondrej Jirman, the factor M of
PLL1 shouldn't be used and the factor P should be used only if the
intended frequency is lower than 288MHz. This is proven by the
clk-sun8iw7_tbl.c in the BSP source code -- in there the M value is
always 0 and the maximum frequency that P is not 0 is 224MHz.

As P is ignored on sun6i, it's not currently used. This patch removed
the usage of M.

This patch is an original work by Ondrej Jirman, however, he didn't add
a Signed-off-by tag here to his commit. So I take this code and added my
Signed-off-by.

Signed-off-by: Icenowy Zheng 
---

This is a critical patch, and should be added to 2017.05.

It has been verified by the Armbian.

 arch/arm/mach-sunxi/clock_sun6i.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 4762fbf0c3..ce4291b30e 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -98,11 +98,10 @@ void clock_set_pll1(unsigned int clk)
int k = 1;
int m = 1;
 
-   if (clk > 115200) {
-   k = 2;
-   } else if (clk > 76800) {
+   if (clk >= 136800) {
k = 3;
-   m = 2;
+   } else if (clk >= 76800) {
+   k = 2;
}
 
/* Switch to 24MHz clock while changing PLL1 */
-- 
2.12.2

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


Re: [U-Boot] [v2017.03] firefly-rk3288 link failure

2017-04-09 Thread Andreas Färber
Am 09.04.2017 um 15:21 schrieb Andreas Färber:
> Hello,
> 
> In v2017.03 the firefly-rk3288 target fails to link with our gcc 6.3.1.
> I've tried gcc 7.0.1 (CC=gcc-7), but no change.
> 
> [   99s]   LD  u-boot
> [   99s] ld.bfd: u-boot: Not enough room for program headers, try
> linking with -N
> [   99s] ld.bfd: final link failed: Bad value
> [   99s] make: *** [Makefile:1206: u-boot] Error 1

Just checked: Same issue with tinker-rk3288.

> Is there a known fix or workaround?
> 
> Thanks,
> Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [v2017.03] firefly-rk3288 link failure

2017-04-09 Thread Andreas Färber
Hello,

In v2017.03 the firefly-rk3288 target fails to link with our gcc 6.3.1.
I've tried gcc 7.0.1 (CC=gcc-7), but no change.

[   99s]   LD  u-boot
[   99s] ld.bfd: u-boot: Not enough room for program headers, try
linking with -N
[   99s] ld.bfd: final link failed: Bad value
[   99s] make: *** [Makefile:1206: u-boot] Error 1

This is a regression from v2017.01.

Is there a known fix or workaround?

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH RFC] omap_hsmmc: update struct hsmmc to accommodate omap3 from DT

2017-04-09 Thread Adam Ford
I am working on porting an OMAP3630 board to support device tree, and
I attempted to change enable DM_MMC.  Unfortunately, that broke MMC.

I discovered that the base addresses were originally updated to reflect a
change in the base address when using the device tree for some devices.

This was done in 11e1582506c6 ("omap_hsmmc: update struct hsmmc to accomodate
base address from DT")

Unfortunately, this breaks the base address on an OMAP3630 (and I assume
omap34xx) which currently doesn't have OF support yet.

Without this patch, the when driver attemps to write to mmc_base->sysconfig
at 4809c110 is used instead of mmc_base->sysconfig at 4809c010.  This makes any
attempt to use the mmc fail.  With this patch, I am able to read/write to the
MMC device with DM_MMC enabled with OF support.

If there is a better solution, I am open to ideas.  I verified this against
the OMAP3530 TRM and OMAP3630 TRM.  Since AM3359 TRM has the same value,
it might be helpful for other boards, but I don't have them to test.  If there
is a better solution, I am perfectly open for suggestions.

If this gets reviewed and approved, I can push the OMAP3630 (and OMAP3) device
trees which might let more boards move to DM and OF support.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index f2bf645..fd9b741 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -26,7 +26,7 @@
 #define OMAP_MMC_H_
 
 struct hsmmc {
-#ifdef CONFIG_DM_MMC
+#if defined(CONFIG_DM_MMC) && !defined(OMAP34XX)
unsigned char res0[0x100];
 #endif
unsigned char res1[0x10];
-- 
2.7.4

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


Re: [U-Boot] [PATCH v4 00/35] ARM: i.MX6: SabreSD: Add dts support

2017-04-09 Thread Fabio Estevam
Hi Jagan,

On Sun, Apr 9, 2017 at 3:52 AM, Jagan Teki  wrote:
> This series has full possible dts support for SabreSD DualLite,
> Quad and Quad Plus and DCD code for DualLite has added in SPL code.
>
> The main intention of this series is to add the dts node step
> by step and remove the legacy code at the end and to make
> the full functional dts.
>
> Preserved non-spl defconfigs, So 3 spl defconfigs and 2 non-spl defconfigs

Why do we need 3 SPL defconfigs? Can't we have a single SPL defconfig
that works for MX6Q/MX6DL/MX6QP boards?

Do you have a git tree with this series applied? I would like to test it.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] OMAP3: Correct name of omap34xx_gpios when using DM_GPIO

2017-04-09 Thread Adam Ford
The name of the gpio bank under DM_GPIO appear to be a copy-paste error.
This changes the name of the gpio bank from am33xx_gpios to omap34xx_gpios.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/mach-omap2/omap3/board.c 
b/arch/arm/mach-omap2/omap3/board.c
index f1436fb..01df579 100644
--- a/arch/arm/mach-omap2/omap3/board.c
+++ b/arch/arm/mach-omap2/omap3/board.c
@@ -46,7 +46,7 @@ static const struct omap_gpio_platdata omap34xx_gpio[] = {
{ 5, OMAP34XX_GPIO6_BASE },
 };
 
-U_BOOT_DEVICES(am33xx_gpios) = {
+U_BOOT_DEVICES(omap34xx_gpios) = {
{ "gpio_omap", _gpio[0] },
{ "gpio_omap", _gpio[1] },
{ "gpio_omap", _gpio[2] },
-- 
2.7.4

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


[U-Boot] [PATCH v4 23/35] ARM: i.MX6DL: sabresd: Move DCD reginit on SPL

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

DCD register initialization from mx6dlsabresd.cfg are moved to
SPL code in mx6dl_dcd_table.

Now mx6sabresd SPL code support Dual Lite, Quad, Quad Plus.

mx6dl_dcd_table reginit as
- GPR io regs
- DRAM io regs,
- MMDC Calibration io regs
- dram sdcke0 (0x020e04a4) and sdcke1(0x020e04a8) are not available
  in original mx6dlsabresd.cfg but initialized to default values.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- none
Changes for v3:
- Newly added
Changes for v2:
- none

 board/freescale/mx6sabresd/mx6sabresd.c | 64 -
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 67fc192..5595c08 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -893,6 +893,66 @@ static void gpr_init(void)
}
 }
 
+static int mx6dl_dcd_table[] = {
+   /* GPR io regs */
+   0x020e0774, 0x000C,
+   0x020e076c, 0x0030,
+   0x020e0760, 0x0002,
+   0x020e0754, 0x,
+   0x020e0750, 0x0002,
+   0x020e074c, 0x0030,
+   0x020e0748, 0x0030,
+   0x020e078c, 0x0030,
+   0x020e0784, 0x0030,
+   0x020e0780, 0x0030,
+   0x020e077c, 0x0030,
+   0x020e0778, 0x0030,
+   0x020e0770, 0x0030,
+   0x020e0764, 0x0030,
+
+   /* DRAM io regs */
+   0x020e04ac, 0x0030,
+   0x020e04b0, 0x0030,
+   0x020e0464, 0x0030,
+   0x020e0490, 0x0030,
+   0x020e0494, 0x0030,
+   0x020e04a4, 0x0030,
+   0x020e04a8, 0x0030,
+   0x020e04a0, 0x,
+   0x020e04b4, 0x0030,
+   0x020e04b8, 0x0030,
+   0x020e04bc, 0x0030,
+   0x020e04c0, 0x0030,
+   0x020e04c4, 0x0030,
+   0x020e04c8, 0x0030,
+   0x020e04cc, 0x0030,
+   0x020e04d0, 0x0030,
+   0x020e04d4, 0x0030,
+   0x020e04d8, 0x0030,
+   0x020e0470, 0x0030,
+   0x020e0474, 0x0030,
+   0x020e0478, 0x0030,
+   0x020e047c, 0x0030,
+   0x020e0480, 0x0030,
+   0x020e0484, 0x0030,
+   0x020e0488, 0x0030,
+   0x020e048c, 0x0030,
+
+   /* MMDC Calibration io regs */
+   0x021b080c, 0x001F001F,
+   0x021b0810, 0x001F001F,
+   0x021b480c, 0x001F001F,
+   0x021b4810, 0x001F001F,
+   0x021b083c, 0x4220021F,
+   0x021b0840, 0x0207017E,
+   0x021b483c, 0x4201020C,
+   0x021b4840, 0x01660172,
+   0x021b0848, 0x4A4D4E4D,
+   0x021b0850, 0x3F3C3D31,
+   0x021b4848, 0x4A4F5049,
+   0x021b4850, 0x3238372B,
+};
+
 static int mx6q_dcd_table[] = {
0x020e0798, 0x000C,
0x020e0758, 0x,
@@ -1085,7 +1145,9 @@ static void ddr_init(int *table, int size)
 
 static void spl_dram_init(void)
 {
-   if (is_mx6dq())
+   if (is_mx6dl())
+   ddr_init(mx6dl_dcd_table, ARRAY_SIZE(mx6dl_dcd_table));
+   else if (is_mx6dq())
ddr_init(mx6q_dcd_table, ARRAY_SIZE(mx6q_dcd_table));
else if (is_mx6dqp())
ddr_init(mx6qp_dcd_table, ARRAY_SIZE(mx6qp_dcd_table));
-- 
1.9.1

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


[U-Boot] [PATCH v4 33/35] ARM: i.MX6: sabresd: Update README

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Now SabreSD board support SPL and non-SPL with devicetree
enabled, so update the README according with images generated
with respective builds.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- Update the dtb-enabled image as u-boot-dtb.img
Changes for v3, v2:
- none

 board/freescale/imx6sabresd/README | 50 ++
 1 file changed, 34 insertions(+), 16 deletions(-)

diff --git a/board/freescale/imx6sabresd/README 
b/board/freescale/imx6sabresd/README
index 43070e1..32f31ce 100644
--- a/board/freescale/imx6sabresd/README
+++ b/board/freescale/imx6sabresd/README
@@ -3,9 +3,9 @@ How to use and build U-Boot on mx6sabresd:
 
 Currently there are three methods for booting mx6sabresd boards:
 
-1. Booting via Normal U-Boot (u-boot.imx)
+1. Booting via Normal U-Boot (u-boot-dtb.imx)
 
-2. Booting via SPL (SPL and u-boot.img)
+2. Booting via SPL (SPL and u-boot-dtb.img)
 
 3. Booting via Falcon mode (SPL launches the kernel directly)
 
@@ -13,56 +13,74 @@ Currently there are three methods for booting mx6sabresd 
boards:
 1. Booting via Normal U-Boot
 
 
-$ make mx6qsabresd_defconfig (If you want to build for mx6qsabresd)
+$ make imx6dl_sabresd_defconfig (If you want to build for imx6 duallite 
sabresd)
 
 or
 
-$ make mx6dlsabresd_defconfig (If you want to build for mx6dlsabresd)
+$ make imx6q_sabresd_defconfig (If you want to build for imx6 quad sabresd)
 
 $ make
 
-This will generate the image called u-boot.imx.
+This will generate the image called u-boot-dtb.imx.
 
-- Flash the u-boot.imx binary into the SD card:
+- Flash the u-boot-dtb.imx binary into the SD card:
 
-$ sudo dd if=u-boot.imx of=/dev/sdb bs=1K seek=1 && sync
+$ sudo dd if=u-boot-dtb.imx of=/dev/sdb bs=1K seek=1 && sync
 
 
 2. Booting via SPL
 --
 
-Other method for building U-Boot on mx6qsabresd and mx6qpsabresd is
+Other method for building U-Boot on imx6 duallite, quad and quad plus is
 through SPL. In order to do so:
 
-$ make mx6sabresd_spl_defconfig
+$ make imx6dl_sabresd_spl_defconfig (If you want to build for imx6 duallite 
sabresd)
+
+or
+
+$ make imx6q_sabresd_spl_defconfig (If you want to build for imx6 quad sabresd)
+
+or
+
+$ make imx6q_sabresd_spl_defconfig (If you want to build for imx6 quad plus 
sabresd)
+
 $ make
 
-This will generate the SPL image called SPL and the u-boot.img.
+This will generate the SPL image called SPL and the u-boot-dtb.img.
 
 - Flash the SPL image into the SD card:
 
 $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
 
-- Flash the u-boot.img image into the SD card:
+- Flash the u-boot-dtb.img image into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdb bs=1K seek=69 && sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1K seek=69 && sync
 
 
 3. Booting via Falcon mode
 --
 
-$ make mx6sabresd_spl_defconfig
+$ make imx6dl_sabresd_spl_defconfig (If you want to build for imx6 duallite 
sabresd)
+
+or
+
+$ make imx6q_sabresd_spl_defconfig (If you want to build for imx6 quad sabresd)
+
+or
+
+$ make imx6q_sabresd_spl_defconfig (If you want to build for imx6 quad plus 
sabresd)
+
 $ make
 
-This will generate the SPL image called SPL and the u-boot.img.
+This will generate the SPL image called SPL and the u-boot-dtb.img.
 
 - Flash the SPL image into the SD card:
 
 $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 oflag=sync status=none && sync
 
-- Flash the u-boot.img image into the SD card:
+- Flash the u-boot-dtb.img image into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdb bs=1K seek=69 oflag=sync status=none && 
sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1K seek=69 oflag=sync status=none 
&& sync
 
 Create a partition for root file system and extract it there:
 
-- 
1.9.1

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


[U-Boot] [PATCH v4 34/35] ARM: i.MX6: sabresd: Drop checkboard

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Since SabreSD is supporting fdt, there is no use
of printing the board name explicitly using checkboard
because dtb supported u-boot will print model like this

Model: Freescale i.MX6 Quad Plus SABRE Smart Device Board

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/imx6sabresd/imx6sabresd.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/board/freescale/imx6sabresd/imx6sabresd.c 
b/board/freescale/imx6sabresd/imx6sabresd.c
index 595e1db..3c00ea6 100644
--- a/board/freescale/imx6sabresd/imx6sabresd.c
+++ b/board/freescale/imx6sabresd/imx6sabresd.c
@@ -449,12 +449,6 @@ int board_late_init(void)
return 0;
 }
 
-int checkboard(void)
-{
-   puts("Board: MX6-SabreSD\n");
-   return 0;
-}
-
 #ifdef CONFIG_SPL_BUILD
 #include 
 #include 
-- 
1.9.1

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


[U-Boot] [PATCH v4 21/35] ARM: i.MX6: sabresd: Add imx6_pcie_toggle_power

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add imx6_pcie_toggle_power on board file using dm_gpio_*
calls for OF_CONTROL configs.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/mx6sabresd/mx6sabresd.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 1631dbc..f4e14be 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -533,6 +533,36 @@ int overwrite_console(void)
return 1;
 }
 
+#ifdef CONFIG_OF_CONTROL
+int imx6_pcie_toggle_power(void)
+{
+#ifdef CONFIG_PCIE_IMX_POWER_GPIO
+   struct gpio_desc toggle;
+   int ret;
+
+   ret = dm_gpio_lookup_name("GPIO3_19", );
+   if (ret) {
+   printf("Cannot get GPIO3_19\n");
+   return ret;
+   }
+
+   ret = dm_gpio_request(, "toggle");
+   if (ret) {
+   printf("Cannot request GPIO3_19\n");
+   return ret;
+   }
+
+   dm_gpio_set_dir_flags(, GPIOD_IS_OUT);
+
+   dm_gpio_set_value(, 0);
+   mdelay(20);
+   dm_gpio_set_value(, 1);
+   mdelay(20);
+#endif
+   return 0;
+}
+#endif
+
 #ifndef CONFIG_OF_CONTROL
 int board_eth_init(bd_t *bis)
 {
-- 
1.9.1

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


[U-Boot] [PATCH v4 11/35] ARM: i.MX6: sabresd: Enable DM_I2C and DM_PMIC

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Enable DM_I2C, DM_PMIC and DM_PMIC_PFUZE100 for dt
supported sabresd config boards:
- imx6q_sabresd_spl_defconfig
- imx6qp_sabresd_spl_defconfig

I2C Log:

=> i2c bus
Bus 0:  i2c@021a
Bus 1:  i2c@021a4000
   08: pfuze100@08, offset len 1, flags 0
Bus 2:  i2c@021a8000
=> i2c dev 1
Setting bus to 1
=> i2c speed 10
Setting bus speed to 10 Hz
=> i2c probe
Valid chip addresses: 08 48
=> i2c md 08 0x0 0x20
: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=> i2c md 48 0x0 0x20
: 00 f0 00 00 00 00 00 00 00 00 00 80 70 41 41 41pAAA
0010: 00 00 00 80 70 41 41 41 41 41 41 41 41 41 41 41pAAA

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/mx6sabresd/mx6sabresd.c | 7 ++-
 configs/imx6q_sabresd_spl_defconfig | 3 +++
 configs/imx6qp_sabresd_spl_defconfig| 3 +++
 include/configs/mx6sabresd.h| 4 +++-
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index db25dad..5776b39 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -202,6 +202,7 @@ static void enable_lvds(struct display_info_t const *dev)
enable_backlight();
 }
 
+#ifndef CONFIG_DM_I2C
 static struct i2c_pads_info i2c_pad_info1 = {
.scl = {
.i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | I2C_PAD,
@@ -214,6 +215,7 @@ static struct i2c_pads_info i2c_pad_info1 = {
.gp = IMX_GPIO_NR(4, 13)
}
 };
+#endif
 
 static void setup_spi(void)
 {
@@ -594,8 +596,9 @@ int board_init(void)
 #ifdef CONFIG_MXC_SPI
setup_spi();
 #endif
+#ifndef CONFIG_DM_I2C
setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
-
+#endif
 #ifdef CONFIG_USB_EHCI_MX6
setup_usb();
 #endif
@@ -603,6 +606,7 @@ int board_init(void)
return 0;
 }
 
+#ifndef CONFIG_DM_PMIC
 int power_init_board(void)
 {
struct pmic *p;
@@ -631,6 +635,7 @@ int power_init_board(void)
 
return 0;
 }
+#endif
 
 #ifdef CONFIG_MXC_SPI
 int board_spi_cs_gpio(unsigned bus, unsigned cs)
diff --git a/configs/imx6q_sabresd_spl_defconfig 
b/configs/imx6q_sabresd_spl_defconfig
index e1bea93..2076418 100644
--- a/configs/imx6q_sabresd_spl_defconfig
+++ b/configs/imx6q_sabresd_spl_defconfig
@@ -50,10 +50,13 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_OF_CONTROL=y
+CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
+CONFIG_DM_PMIC=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_DM_PMIC_PFUZE100=y
 CONFIG_SYS_I2C_MXC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
diff --git a/configs/imx6qp_sabresd_spl_defconfig 
b/configs/imx6qp_sabresd_spl_defconfig
index eab8570..55df0b5 100644
--- a/configs/imx6qp_sabresd_spl_defconfig
+++ b/configs/imx6qp_sabresd_spl_defconfig
@@ -50,10 +50,13 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_OF_CONTROL=y
+CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
+CONFIG_DM_PMIC=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_DM_PMIC_PFUZE100=y
 CONFIG_SYS_I2C_MXC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 7c0e7a5..6ece575 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -52,7 +52,7 @@
 #endif
 
 /* I2C Configs */
-#ifdef CONFIG_SYS_I2C_MXC
+#if defined(CONFIG_SYS_I2C_MXC) && !defined(CONFIG_DM_I2C)
 #define CONFIG_SYS_I2C
 #define CONFIG_SYS_I2C_MXC_I2C1/* enable I2C bus 1 */
 #define CONFIG_SYS_I2C_MXC_I2C2/* enable I2C bus 2 */
@@ -61,10 +61,12 @@
 #endif
 
 /* PMIC */
+#ifndef CONFIG_DM_PMIC_PFUZE100
 #define CONFIG_POWER
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_PFUZE100
 #define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
+#endif
 
 /* USB Configs */
 #ifdef CONFIG_CMD_USB
-- 
1.9.1

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


[U-Boot] [PATCH v4 29/35] ARM: i.MX6: sabresd: Drop legacy non-fdt code

2017-04-09 Thread Jagan Teki
- Removed non-fdt code (becuase which has dt support)
- Remove mx6sabresd_spl_defconfig
- Re-arrange the header includes and removed unneeded includes.
- Move the SPL code in #ifdef CONFIG_SPL_BUILD area.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- Don't drop non-spl defconfigs
Changes for v3:
- none
Changes for v2:
- none

 board/freescale/mx6sabresd/MAINTAINERS  |   1 -
 board/freescale/mx6sabresd/mx6sabresd.c | 396 +---
 configs/mx6sabresd_spl_defconfig|  54 -
 include/configs/mx6sabresd.h|  23 --
 4 files changed, 63 insertions(+), 411 deletions(-)
 delete mode 100644 configs/mx6sabresd_spl_defconfig

diff --git a/board/freescale/mx6sabresd/MAINTAINERS 
b/board/freescale/mx6sabresd/MAINTAINERS
index d46b0d2..281e709 100644
--- a/board/freescale/mx6sabresd/MAINTAINERS
+++ b/board/freescale/mx6sabresd/MAINTAINERS
@@ -5,7 +5,6 @@ F:  board/freescale/mx6sabresd/
 F: include/configs/mx6sabresd.h
 F: configs/imx6dl_sabresd_defconfig
 F: configs/imx6q_sabresd_defconfig
-F: configs/mx6sabresd_spl_defconfig
 F: configs/imx6dl_sabresd_spl_defconfig
 F: configs/imx6q_sabresd_spl_defconfig
 F: configs/imx6qp_sabresd_spl_defconfig
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 5595c08..595e1db 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -6,30 +6,24 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
 #include 
-#include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "../common/pfuze.h"
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -37,28 +31,9 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 
-#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP |   \
-   PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
-   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
-#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
-   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
-
 #define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
  PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
 
-#define I2C_PAD_CTRL  (PAD_CTL_PUS_100K_UP |   \
-   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
-   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
-
-#define I2C_PMIC   1
-
-#define I2C_PAD MUX_PAD_CTRL(I2C_PAD_CTRL)
-
-#define DISP0_PWR_EN   IMX_GPIO_NR(1, 21)
-
-#define KEY_VOL_UP IMX_GPIO_NR(1, 4)
-
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -70,80 +45,6 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
 };
 
-#ifndef CONFIG_OF_CONTROL
-static iomux_v3_cfg_t const enet_pads[] = {
-   MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET_MDC__ENET_MDC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL  | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET_REF_CLK__ENET_TX_CLK   | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_RXC__RGMII_RXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_RD0__RGMII_RD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_RD1__RGMII_RD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_RD2__RGMII_RD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_RD3__RGMII_RD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL  | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   /* AR8031 PHY Reset */
-   MX6_PAD_ENET_CRS_DV__GPIO1_IO25 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static void setup_iomux_enet(void)
-{
-   imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
-
-   /* Reset AR8031 PHY */
-   gpio_direction_output(IMX_GPIO_NR(1, 25) , 0);
-   mdelay(10);
-   gpio_set_value(IMX_GPIO_NR(1, 25), 1);
-   udelay(100);
-}
-#endif
-
-static iomux_v3_cfg_t const usdhc2_pads[] = {
-   MX6_PAD_SD2_CLK__SD2_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX6_PAD_SD2_CMD__SD2_CMD| 

[U-Boot] [PATCH v4 18/35] ARM: i.MX6: sabre: Move CONFIG_FEC_MXC to defconfigs

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Moved CONFIG_FEC_MXC from include/configs/mxsabresd.h
to imx6 sabresd and sabreauto defconfigs.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- Move CONFIG_FEC_MXC to mx6[dl|q|qp]sabreauto_defconfig
Changes for v3, v2:
- none

 configs/imx6q_sabresd_spl_defconfig  | 1 +
 configs/imx6qp_sabresd_spl_defconfig | 1 +
 configs/mx6dlsabreauto_defconfig | 2 ++
 configs/mx6dlsabresd_defconfig   | 1 +
 configs/mx6qpsabreauto_defconfig | 2 ++
 configs/mx6qsabreauto_defconfig  | 2 ++
 configs/mx6qsabresd_defconfig| 1 +
 configs/mx6sabresd_spl_defconfig | 1 +
 include/configs/mx6sabre_common.h| 3 ++-
 9 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/configs/imx6q_sabresd_spl_defconfig 
b/configs/imx6q_sabresd_spl_defconfig
index 9ac3c9c..377a489 100644
--- a/configs/imx6q_sabresd_spl_defconfig
+++ b/configs/imx6q_sabresd_spl_defconfig
@@ -62,5 +62,6 @@ CONFIG_DM_USB=y
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_DM_PMIC_PFUZE100=y
 CONFIG_SYS_I2C_MXC=y
+CONFIG_FEC_MXC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
diff --git a/configs/imx6qp_sabresd_spl_defconfig 
b/configs/imx6qp_sabresd_spl_defconfig
index 1be1eac..13c2288 100644
--- a/configs/imx6qp_sabresd_spl_defconfig
+++ b/configs/imx6qp_sabresd_spl_defconfig
@@ -62,5 +62,6 @@ CONFIG_DM_USB=y
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_DM_PMIC_PFUZE100=y
 CONFIG_SYS_I2C_MXC=y
+CONFIG_FEC_MXC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
diff --git a/configs/mx6dlsabreauto_defconfig b/configs/mx6dlsabreauto_defconfig
index ba5ab8a..dae89fe 100644
--- a/configs/mx6dlsabreauto_defconfig
+++ b/configs/mx6dlsabreauto_defconfig
@@ -42,3 +42,5 @@ CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
+CONFIG_NETDEVICES=y
+CONFIG_FEC_MXC=y
diff --git a/configs/mx6dlsabresd_defconfig b/configs/mx6dlsabresd_defconfig
index 64a024b..c61fcd2 100644
--- a/configs/mx6dlsabresd_defconfig
+++ b/configs/mx6dlsabresd_defconfig
@@ -45,3 +45,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_SYS_I2C_MXC=y
+CONFIG_FEC_MXC=y
diff --git a/configs/mx6qpsabreauto_defconfig b/configs/mx6qpsabreauto_defconfig
index 96a248e..2f95ab0 100644
--- a/configs/mx6qpsabreauto_defconfig
+++ b/configs/mx6qpsabreauto_defconfig
@@ -41,3 +41,5 @@ CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
+CONFIG_NETDEVICES=y
+CONFIG_FEC_MXC=y
diff --git a/configs/mx6qsabreauto_defconfig b/configs/mx6qsabreauto_defconfig
index 015207d..20b39dc 100644
--- a/configs/mx6qsabreauto_defconfig
+++ b/configs/mx6qsabreauto_defconfig
@@ -42,3 +42,5 @@ CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
+CONFIG_NETDEVICES=y
+CONFIG_FEC_MXC=y
diff --git a/configs/mx6qsabresd_defconfig b/configs/mx6qsabresd_defconfig
index 8617094..e9758e3 100644
--- a/configs/mx6qsabresd_defconfig
+++ b/configs/mx6qsabresd_defconfig
@@ -45,3 +45,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_SYS_I2C_MXC=y
+CONFIG_FEC_MXC=y
diff --git a/configs/mx6sabresd_spl_defconfig b/configs/mx6sabresd_spl_defconfig
index c3eb03c..bba77b6 100644
--- a/configs/mx6sabresd_spl_defconfig
+++ b/configs/mx6sabresd_spl_defconfig
@@ -51,3 +51,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_SYS_I2C_MXC=y
+CONFIG_FEC_MXC=y
diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index a2ab77a..19ef6dc 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -21,7 +21,7 @@
 /* MMC Configs */
 #define CONFIG_SYS_FSL_ESDHC_ADDR  0
 
-#define CONFIG_FEC_MXC
+#ifdef CONFIG_FEC_MXC
 #define CONFIG_MII
 #define IMX_FEC_BASE   ENET_BASE_ADDR
 #define CONFIG_FEC_XCV_TYPERGMII
@@ -30,6 +30,7 @@
 
 #define CONFIG_PHYLIB
 #define CONFIG_PHY_ATHEROS
+#endif
 
 #ifdef CONFIG_CMD_SF
 #define CONFIG_MXC_SPI
-- 
1.9.1

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


[U-Boot] [PATCH v4 35/35] ARM: i.MX6: sabresd: Cleanup board code

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

- Give proper tab alignment for display_info_t structure
- Add tab spaces UART_PAD_CTRL and SPI_PAD_CTRL
- Give proper alignment of reg init values on setup_display
- Add space and newline on board_init_f

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/imx6sabresd/imx6sabresd.c | 183 +++---
 1 file changed, 94 insertions(+), 89 deletions(-)

diff --git a/board/freescale/imx6sabresd/imx6sabresd.c 
b/board/freescale/imx6sabresd/imx6sabresd.c
index 3c00ea6..8d75873 100644
--- a/board/freescale/imx6sabresd/imx6sabresd.c
+++ b/board/freescale/imx6sabresd/imx6sabresd.c
@@ -27,12 +27,11 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
-   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
-   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
-#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
- PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+#define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
+   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
+#define SPI_PAD_CTRL   (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
+   PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
 
 int dram_init(void)
 {
@@ -201,67 +200,72 @@ static void do_enable_hdmi(struct display_info_t const 
*dev)
imx_enable_hdmi_phy();
 }
 
-struct display_info_t const displays[] = {{
-   .bus= -1,
-   .addr   = 0,
-   .pixfmt = IPU_PIX_FMT_RGB666,
-   .detect = NULL,
-   .enable = enable_lvds,
-   .mode   = {
-   .name   = "Hannstar-XGA",
-   .refresh= 60,
-   .xres   = 1024,
-   .yres   = 768,
-   .pixclock   = 15384,
-   .left_margin= 160,
-   .right_margin   = 24,
-   .upper_margin   = 29,
-   .lower_margin   = 3,
-   .hsync_len  = 136,
-   .vsync_len  = 6,
-   .sync   = FB_SYNC_EXT,
-   .vmode  = FB_VMODE_NONINTERLACED
-} }, {
-   .bus= -1,
-   .addr   = 0,
-   .pixfmt = IPU_PIX_FMT_RGB24,
-   .detect = detect_hdmi,
-   .enable = do_enable_hdmi,
-   .mode   = {
-   .name   = "HDMI",
-   .refresh= 60,
-   .xres   = 1024,
-   .yres   = 768,
-   .pixclock   = 15384,
-   .left_margin= 160,
-   .right_margin   = 24,
-   .upper_margin   = 29,
-   .lower_margin   = 3,
-   .hsync_len  = 136,
-   .vsync_len  = 6,
-   .sync   = FB_SYNC_EXT,
-   .vmode  = FB_VMODE_NONINTERLACED
-} }, {
-   .bus= 0,
-   .addr   = 0,
-   .pixfmt = IPU_PIX_FMT_RGB24,
-   .detect = NULL,
-   .enable = enable_rgb,
-   .mode   = {
-   .name   = "SEIKO-WVGA",
-   .refresh= 60,
-   .xres   = 800,
-   .yres   = 480,
-   .pixclock   = 29850,
-   .left_margin= 89,
-   .right_margin   = 164,
-   .upper_margin   = 23,
-   .lower_margin   = 10,
-   .hsync_len  = 10,
-   .vsync_len  = 10,
-   .sync   = 0,
-   .vmode  = FB_VMODE_NONINTERLACED
-} } };
+struct display_info_t const displays[] = {
+   {
+   .bus= -1,
+   .addr   = 0,
+   .pixfmt = IPU_PIX_FMT_RGB666,
+   .detect = NULL,
+   .enable = enable_lvds,
+   .mode   = {
+   .name   = "Hannstar-XGA",
+   .refresh= 60,
+   .xres   = 1024,
+   .yres   = 768,
+   .pixclock   = 15384,
+   .left_margin= 160,
+   .right_margin   = 24,
+   .upper_margin   = 29,
+   .lower_margin   = 3,
+   .hsync_len  = 136,
+   .vsync_len  = 6,
+   .sync   = FB_SYNC_EXT,
+   .vmode  = FB_VMODE_NONINTERLACED
+   }
+   }, {
+   .bus= -1,
+   .addr   = 0,
+   .pixfmt = IPU_PIX_FMT_RGB24,
+   .detect = detect_hdmi,
+   .enable = do_enable_hdmi,
+   .mode   = {
+   .name   = "HDMI",
+   

[U-Boot] [PATCH v4 17/35] ARM: dts: imx6qdl-sabresd: Add FEC node

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add FEC node for i.MX6QDL Sabresd boards.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 arch/arm/dts/imx6qdl-sabresd.dtsi | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/dts/imx6qdl-sabresd.dtsi
index 0e104c1..ca1aa58 100644
--- a/arch/arm/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd.dtsi
@@ -44,6 +44,14 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet>;
+   phy-mode = "rgmii";
+   phy-reset-gpios = < 25 0>;
+   status = "okay";
+};
+
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -124,6 +132,27 @@
 
  {
imx6qdl-sabresd {
+   pinctrl_enet: enetgrp {
+   fsl,pins = <
+   MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+   MX6QDL_PAD_ENET_MDC__ENET_MDC   0x1b0b0
+   MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
+   MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
+   MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
+   MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
+   MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
+   MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b030
+   MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK0x1b0b0
+   MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+   MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+   MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+   MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+   MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+   MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
+   MX6QDL_PAD_GPIO_16__ENET_REF_CLK
0x4001b0a8
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT8__I2C1_SDA  
0x4001b8b1
-- 
1.9.1

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


[U-Boot] [PATCH v4 14/35] ARM: dts: imx6qdl-sabresd: Add usb otg node

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add usb otg node for i.MX6QDL sabresd boards.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 arch/arm/dts/imx6qdl-sabresd.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/dts/imx6qdl-sabresd.dtsi
index e38e370..0e104c1 100644
--- a/arch/arm/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd.dtsi
@@ -21,6 +21,17 @@
reg = <0x1000 0x4000>;
};
 
+   reg_usb_otg_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "usb_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 22 0>;
+   enable-active-high;
+   vin-supply = <_reg>;
+   };
+
reg_usb_h1_vbus: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -77,6 +88,13 @@
status = "okay";
 };
 
+ {
+   vbus-supply = <_usb_otg_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usbotg>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_usdhc2>;
@@ -134,6 +152,11 @@
>;
};
 
+   pinctrl_usbotg: usbotggrp {
+   fsl,pins = <
+   MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID   0x17059
+   >;
+   };
 
pinctrl_usdhc2: usdhc2grp {
fsl,pins = <
-- 
1.9.1

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


[U-Boot] [PATCH v4 24/35] ARM: dts: imx6qdl-sabresd: Add imx6dl-sabresd.dts

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add initial dts support for i.MX6 DualLite Sabresd board.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- none
Changes for v3:
- Newly added
Changes for v2:
- none

 arch/arm/dts/Makefile   |  1 +
 arch/arm/dts/imx6dl-sabresd.dts | 17 +
 2 files changed, 18 insertions(+)
 create mode 100644 arch/arm/dts/imx6dl-sabresd.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b6042f3..4ce0722 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -315,6 +315,7 @@ dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6sll-evk.dtb \
imx6dl-icore.dtb \
imx6dl-icore-rqs.dtb \
+   imx6dl-sabresd.dtb \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6q-sabresd.dtb \
diff --git a/arch/arm/dts/imx6dl-sabresd.dts b/arch/arm/dts/imx6dl-sabresd.dts
new file mode 100644
index 000..1e45f2f
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabresd.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sabresd.dtsi"
+
+/ {
+   model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
+   compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
+};
-- 
1.9.1

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


[U-Boot] [PATCH v4 15/35] ARM: i.MX6: sabresd: Enable CONFIG_DM_REGULATOR

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Enable CONFIG_DM_REGULATOR for i.MX6QDL sabresd boards.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 configs/imx6q_sabresd_spl_defconfig  | 1 +
 configs/imx6qp_sabresd_spl_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/imx6q_sabresd_spl_defconfig 
b/configs/imx6q_sabresd_spl_defconfig
index 5e26409..84e34f1 100644
--- a/configs/imx6q_sabresd_spl_defconfig
+++ b/configs/imx6q_sabresd_spl_defconfig
@@ -56,6 +56,7 @@ CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_DM_PMIC=y
+CONFIG_DM_REGULATOR=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_DM_PMIC_PFUZE100=y
diff --git a/configs/imx6qp_sabresd_spl_defconfig 
b/configs/imx6qp_sabresd_spl_defconfig
index 02ab803..a626d68 100644
--- a/configs/imx6qp_sabresd_spl_defconfig
+++ b/configs/imx6qp_sabresd_spl_defconfig
@@ -56,6 +56,7 @@ CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_DM_PMIC=y
+CONFIG_DM_REGULATOR=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_DM_PMIC_PFUZE100=y
-- 
1.9.1

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


[U-Boot] [PATCH v4 13/35] ARM: dts: imx6qdl-sabresd: Add usb host node

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add usb host node for i.MX6QDL sabresd boards.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 arch/arm/dts/imx6qdl-sabresd.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/dts/imx6qdl-sabresd.dtsi
index 4afa108..e38e370 100644
--- a/arch/arm/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd.dtsi
@@ -20,6 +20,17 @@
memory {
reg = <0x1000 0x4000>;
};
+
+   reg_usb_h1_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   regulator-name = "usb_h1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 29 0>;
+   enable-active-high;
+   vin-supply = <_reg>;
+   };
 };
 
  {
@@ -38,6 +49,13 @@
pmic: pfuze100@08 {
compatible = "fsl,pfuze100";
reg = <0x08>;
+
+   regulators {
+   swbst_reg: swbst {
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <515>;
+   };
+   };
};
 };
 
@@ -54,6 +72,11 @@
status = "okay";
 };
 
+ {
+   vbus-supply = <_usb_h1_vbus>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_usdhc2>;
-- 
1.9.1

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


[U-Boot] [PATCH v4 10/35] ARM: dts: imx6qdl-sabresd: Add PMIC pfuze100 node

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add PMIC pfuze100 node via i2c2 for i.MX6QDL sabresd boards.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 arch/arm/dts/imx6qdl-sabresd.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/dts/imx6qdl-sabresd.dtsi
index 491fdbf..4afa108 100644
--- a/arch/arm/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd.dtsi
@@ -34,6 +34,11 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+   pmic: pfuze100@08 {
+   compatible = "fsl,pfuze100";
+   reg = <0x08>;
+   };
 };
 
  {
-- 
1.9.1

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


[U-Boot] [PATCH v4 07/35] ARM: i.MX6QP: sabresd: Add initial devicetree support

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add initial dts support for i.MX6 Quad Plus Sabresd board.

Boot from MMC:
-
U-Boot SPL 2017.03-33690-ga80e4f6-dirty (Mar 30 2017 - 00:40:29)
Trying to boot from MMC1

U-Boot 2017.03-33690-ga80e4f6-dirty (Mar 30 2017 - 00:40:29 +0530)

CPU:   Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 29C
Reset cause: POR
Model: Freescale i.MX6 Quad Plus SABRE Smart Device Board
Board: MX6-SabreSD
I2C:   ready
DRAM:  1 GiB
PMIC:  PFUZE100 ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
*** Warning - bad CRC, using default environment

gpio@020a4000: dir_output: error: gpio GPIO3_19 not reserved
gpio@020a4000: set_value: error: gpio GPIO3_19 not reserved
gpio@020b4000: dir_output: error: gpio GPIO7_12 not reserved
gpio@020b4000: set_value: error: gpio GPIO7_12 not reserved
PCI:   pcie phy link never came up
No panel detected: default to Hannstar-XGA
gpio@0209c000: dir_output: error: gpio GPIO1_21 not reserved
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   gpio@0209c000: dir_output: error: gpio GPIO1_25 not reserved
gpio@0209c000: set_value: error: gpio GPIO1_25 not reserved
FEC [PRIME]
Hit any key to stop autoboot:  0
=>

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- Rename imx6qp_sabresd_defconfig to imx6qp_sabresd_spl_defconfig
Changes for v3, v2:
- none

 board/freescale/mx6sabresd/MAINTAINERS |  1 +
 configs/imx6qp_sabresd_spl_defconfig   | 58 ++
 2 files changed, 59 insertions(+)
 create mode 100644 configs/imx6qp_sabresd_spl_defconfig

diff --git a/board/freescale/mx6sabresd/MAINTAINERS 
b/board/freescale/mx6sabresd/MAINTAINERS
index a08f576..d458b6a 100644
--- a/board/freescale/mx6sabresd/MAINTAINERS
+++ b/board/freescale/mx6sabresd/MAINTAINERS
@@ -7,3 +7,4 @@ F:  configs/mx6dlsabresd_defconfig
 F: configs/mx6qsabresd_defconfig
 F: configs/mx6sabresd_spl_defconfig
 F: configs/imx6q_sabresd_spl_defconfig
+F: configs/imx6qp_sabresd_spl_defconfig
diff --git a/configs/imx6qp_sabresd_spl_defconfig 
b/configs/imx6qp_sabresd_spl_defconfig
new file mode 100644
index 000..75a21d7
--- /dev/null
+++ b/configs/imx6qp_sabresd_spl_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_TARGET_MX6SABRESD=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_VIDEO=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6qp-sabresd"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,MX6Q"
+CONFIG_BOOTDELAY=3
+# CONFIG_CONSOLE_MUX is not set
+CONFIG_SYS_CONSOLE_IS_IN_ENV=y
+CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
+CONFIG_SPL=y
+CONFIG_SPL_EXT_SUPPORT=y
+CONFIG_SPL_OS_BOOT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PCI=y
+CONFIG_USB=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="FSL"
+CONFIG_G_DNL_VENDOR_NUM=0x0525
+CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
+# CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_OF_LIBFDT=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_MMC=y
+# CONFIG_BLK is not set
+# CONFIG_DM_MMC_OPS is not set
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX6=y
-- 
1.9.1

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


[U-Boot] [PATCH v4 19/35] ARM: i.MX6: sabresd: Enable DM_ETH

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Enable DM_ETH for dt supported sabresd config boards:
- imx6q_sabresd_defconfig
- imx6qp_sabresd_defconfig

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/mx6sabresd/mx6sabresd.c | 6 ++
 configs/imx6q_sabresd_spl_defconfig | 1 +
 configs/imx6qp_sabresd_spl_defconfig| 1 +
 3 files changed, 8 insertions(+)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index a143dbb..10bc7c6 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -70,6 +70,7 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
 };
 
+#ifndef CONFIG_OF_CONTROL
 static iomux_v3_cfg_t const enet_pads[] = {
MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDC__ENET_MDC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
@@ -100,6 +101,7 @@ static void setup_iomux_enet(void)
gpio_set_value(IMX_GPIO_NR(1, 25), 1);
udelay(100);
 }
+#endif
 
 static iomux_v3_cfg_t const usdhc2_pads[] = {
MX6_PAD_SD2_CLK__SD2_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -222,6 +224,7 @@ static void setup_spi(void)
imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads));
 }
 
+#ifndef CONFIG_OF_CONTROL
 iomux_v3_cfg_t const pcie_pads[] = {
MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),/* 
POWER */
MX6_PAD_GPIO_17__GPIO7_IO12 | MUX_PAD_CTRL(NO_PAD_CTRL),/* 
RESET */
@@ -231,6 +234,7 @@ static void setup_pcie(void)
 {
imx_iomux_v3_setup_multiple_pads(pcie_pads, ARRAY_SIZE(pcie_pads));
 }
+#endif
 
 iomux_v3_cfg_t const di0_pads[] = {
MX6_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,/* DISP0_CLK */
@@ -507,6 +511,7 @@ int overwrite_console(void)
return 1;
 }
 
+#ifndef CONFIG_OF_CONTROL
 int board_eth_init(bd_t *bis)
 {
setup_iomux_enet();
@@ -514,6 +519,7 @@ int board_eth_init(bd_t *bis)
 
return cpu_eth_init(bis);
 }
+#endif
 
 #if defined(CONFIG_USB_EHCI_MX6) && !defined(CONFIG_DM_USB)
 #define USB_OTHERREGS_OFFSET   0x800
diff --git a/configs/imx6q_sabresd_spl_defconfig 
b/configs/imx6q_sabresd_spl_defconfig
index 377a489..8c7baee 100644
--- a/configs/imx6q_sabresd_spl_defconfig
+++ b/configs/imx6q_sabresd_spl_defconfig
@@ -52,6 +52,7 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_OF_CONTROL=y
+CONFIG_DM_ETH=y
 CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
diff --git a/configs/imx6qp_sabresd_spl_defconfig 
b/configs/imx6qp_sabresd_spl_defconfig
index 13c2288..7568329 100644
--- a/configs/imx6qp_sabresd_spl_defconfig
+++ b/configs/imx6qp_sabresd_spl_defconfig
@@ -52,6 +52,7 @@ CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
 CONFIG_OF_CONTROL=y
+CONFIG_DM_ETH=y
 CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
-- 
1.9.1

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


[U-Boot] [PATCH v4 09/35] ARM: dts: imx6qdl-sabresd: Add I2C node's

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add I2C nodes for i.MX6QDL sabresd boards.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 arch/arm/dts/imx6qdl-sabresd.dtsi | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/dts/imx6qdl-sabresd.dtsi
index 2986cb4..491fdbf 100644
--- a/arch/arm/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd.dtsi
@@ -22,6 +22,27 @@
};
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1>;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2>;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
@@ -57,6 +78,27 @@
 
  {
imx6qdl-sabresd {
+   pinctrl_i2c1: i2c1grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT8__I2C1_SDA  
0x4001b8b1
+   MX6QDL_PAD_CSI0_DAT9__I2C1_SCL  
0x4001b8b1
+   >;
+   };
+
+   pinctrl_i2c2: i2c2grp {
+   fsl,pins = <
+   MX6QDL_PAD_KEY_COL3__I2C2_SCL   
0x4001b8b1
+   MX6QDL_PAD_KEY_ROW3__I2C2_SDA   
0x4001b8b1
+   >;
+   };
+
+   pinctrl_i2c3: i2c3grp {
+   fsl,pins = <
+   MX6QDL_PAD_GPIO_3__I2C3_SCL 
0x4001b8b1
+   MX6QDL_PAD_GPIO_6__I2C3_SDA 
0x4001b8b1
+   >;
+   };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA0x1b0b1
-- 
1.9.1

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


[U-Boot] [PATCH v4 22/35] ARM: i.MX6: sabresd: Add imx6_pcie_toggle_reset

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Add imx6_pcie_toggle_reset on board file using dm_gpio_*
calls for OF_CONTROL configs.

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/mx6sabresd/mx6sabresd.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index f4e14be..67fc192 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -561,6 +561,37 @@ int imx6_pcie_toggle_power(void)
 #endif
return 0;
 }
+
+int imx6_pcie_toggle_reset(void)
+{
+#ifdef CONFIG_PCIE_IMX_PERST_GPIO
+   struct gpio_desc reset;
+   int ret;
+
+   ret = dm_gpio_lookup_name("GPIO7_12", );
+   if (ret) {
+   printf("Cannot get GPIO7_12\n");
+   return ret;
+   }
+
+   ret = dm_gpio_request(, "reset");
+   if (ret) {
+   printf("Cannot request GPIO7_12\n");
+   return ret;
+   }
+
+   dm_gpio_set_dir_flags(, GPIOD_IS_OUT);
+
+   dm_gpio_set_value(, 0);
+   mdelay(20);
+   dm_gpio_set_value(, 1);
+   mdelay(20);
+
+#else
+   puts("WARNING: Make sure the PCIe #PERST line is connected!\n");
+#endif
+   return 0;
+}
 #endif
 
 #ifndef CONFIG_OF_CONTROL
-- 
1.9.1

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


[U-Boot] [PATCH v4 16/35] ARM: i.MX6: sabresd: Enable DM_USB

2017-04-09 Thread Jagan Teki
From: Jagan Teki 

Enable DM_USB for dt supported sabresd config boards:
- imx6q_sabresd_defconfig
- imx6qp_sabresd_defconfig

Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
Changes for v4, v3, v2:
- none

 board/freescale/mx6sabresd/mx6sabresd.c | 4 ++--
 configs/imx6q_sabresd_spl_defconfig | 1 +
 configs/imx6qp_sabresd_spl_defconfig| 1 +
 include/configs/mx6sabresd.h| 9 ++---
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 5776b39..a143dbb 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -515,7 +515,7 @@ int board_eth_init(bd_t *bis)
return cpu_eth_init(bis);
 }
 
-#ifdef CONFIG_USB_EHCI_MX6
+#if defined(CONFIG_USB_EHCI_MX6) && !defined(CONFIG_DM_USB)
 #define USB_OTHERREGS_OFFSET   0x800
 #define UCTRL_PWR_POL  (1 << 9)
 
@@ -599,7 +599,7 @@ int board_init(void)
 #ifndef CONFIG_DM_I2C
setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
 #endif
-#ifdef CONFIG_USB_EHCI_MX6
+#if defined(CONFIG_USB_EHCI_MX6) && !defined(CONFIG_DM_USB)
setup_usb();
 #endif
 
diff --git a/configs/imx6q_sabresd_spl_defconfig 
b/configs/imx6q_sabresd_spl_defconfig
index 84e34f1..9ac3c9c 100644
--- a/configs/imx6q_sabresd_spl_defconfig
+++ b/configs/imx6q_sabresd_spl_defconfig
@@ -57,6 +57,7 @@ CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_REGULATOR=y
+CONFIG_DM_USB=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_DM_PMIC_PFUZE100=y
diff --git a/configs/imx6qp_sabresd_spl_defconfig 
b/configs/imx6qp_sabresd_spl_defconfig
index a626d68..1be1eac 100644
--- a/configs/imx6qp_sabresd_spl_defconfig
+++ b/configs/imx6qp_sabresd_spl_defconfig
@@ -57,6 +57,7 @@ CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_REGULATOR=y
+CONFIG_DM_USB=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_DM_PMIC_PFUZE100=y
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 6abe7a4..4f6bb1b 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -70,12 +70,15 @@
 
 /* USB Configs */
 #ifdef CONFIG_USB_EHCI_MX6
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 #define CONFIG_USB_HOST_ETHER
 #define CONFIG_USB_ETHER_ASIX
 #define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
-#define CONFIG_MXC_USB_FLAGS   0
-#define CONFIG_USB_MAX_CONTROLLER_COUNT1 /* Enabled USB controller 
number */
+
+# ifndef CONFIG_DM_USB
+#  define CONFIG_MXC_USB_FLAGS 0
+#  define CONFIG_USB_MAX_CONTROLLER_COUNT  1 /* Enabled USB controller 
number */
+#  define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+# endif
 #endif
 
 #endif /* __MX6QSABRESD_CONFIG_H */
-- 
1.9.1

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


  1   2   >