Re: [U-Boot] [PATCH v2] miniarm-rk3288: set isp/vop qos priority level

2016-12-13 Thread Kever Yang

Hi Simon,

On 12/12/2016 04:27 AM, Simon Glass wrote:

Hi Nickey,

On 8 December 2016 at 21:39, Nickey Yang  wrote:

isp-camera image will be broken when enter dual screen display mode.
We set isp qos high to solve this problem.

Signed-off-by: Nickey Yang 
---
  arch/arm/include/asm/arch-rockchip/qos_rk3288.h | 21 +
  board/rockchip/miniarm_rk3288/miniarm-rk3288.c  | 21 +
  2 files changed, 42 insertions(+)
  create mode 100644 arch/arm/include/asm/arch-rockchip/qos_rk3288.h

diff --git a/arch/arm/include/asm/arch-rockchip/qos_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/qos_rk3288.h
new file mode 100644
index 000..d3d6c3e
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/qos_rk3288.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2016 Rockchip Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef _ASM_ARCH_QOS_RK3288_H
+#define _ASM_ARCH_QOS_RK3288_H
+
+/* cpu axi qos priority */
+#define CPU_AXI_QOS_PRIORITY_LEVEL(h, l) \
+   h) & 3) << 2) | ((l) & 3))

Can you instead define

XXX_SHIFT   2
XXX_MASK  (3 << XXX_SHIFT)

and then use these in the .c code?


+
+#define CPU_AXI_QOS_PRIORITY0x08
+
+#define VIO0_VOP_QOS0xffad0400
+#define VIO1_VOP_QOS0xffad
+#define VIO1_ISP_R_QOS  0xffad0900
+#define VIO1_ISP_W0_QOS 0xffad0100
+#define VIO1_ISP_W1_QOS 0xffad0180
+
+#endif
diff --git a/board/rockchip/miniarm_rk3288/miniarm-rk3288.c 
b/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
index 79541a3..ba0f3a3 100644
--- a/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
+++ b/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
@@ -5,3 +5,24 @@
   */

  #include 
+#include 
+#include 
+
+int rk_board_late_init(void)
+{
+   /* set isp qos to higher priority */
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_R_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_W0_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_W1_QOS + CPU_AXI_QOS_PRIORITY);
+
+   /* set vop qos to higher priority */
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO0_VOP_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_VOP_QOS + CPU_AXI_QOS_PRIORITY);

Can you add a register struct for this in arch/arm/include/asm/arch-rockchip/ ?

Also I think it would be best to put this code somewhere in
arch/arm/mach-rockchip and call it from your late init routine.


I understand people don't like source cod in hardcode(or nearly) and out of
any framwork, but there do have some different one time init program for
different SoC or board, I think it's OK to add then in soc_init() or 
board_init()

with appropriate comment.

Back to the case here, setting the ISP NOC niu to higher priority is 
only needed
for the miniarm board for the use case in that board. It might have 
other requirement
for other board for different use cases, so it's OK to add the code in 
board file.
I think you would like to have some API function for this setting then 
different board can use it

instead of do SoC setting in board file, right?
Before other board need this blob of code, would it be more clear to put 
the code in board file?


@Nickey, I'm sure the patch V3 is not what we need. Simon's suggestion 
could be detail in this:

- add a rk3288_qos_init() in arch/arm/mach-rockchip/rk3288-board.c
- call the rk3288_qos_init() in rk_board_late_init() of 
board/rockchip/miniarm_rk3288/miniarm-rk3288.c


Thanks,
- Kever



+
+   return 0;
+}
--
1.9.1



Regards,
Simon






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


[U-Boot] [PATCH] usb: dwc2-otg: remove unused variable

2016-12-13 Thread Masahiro Yamada
GCC 6.1 complains about this.

drivers/usb/gadget/dwc2_udc_otg.c:72:19: warning: 'driver_desc'
defined but not used [-Wunused-const-variable=]
 static const char driver_desc[] = DRIVER_DESC;
   ^~~

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/gadget/dwc2_udc_otg.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index d72bfdf..cb44374 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -63,13 +63,11 @@ static char *state_names[] = {
"WAIT_FOR_NULL_COMPLETE",
 };
 
-#define DRIVER_DESC "DWC2 HS USB OTG Device Driver, (c) Samsung Electronics"
 #define DRIVER_VERSION "15 March 2009"
 
 struct dwc2_udc*the_controller;
 
 static const char driver_name[] = "dwc2-udc";
-static const char driver_desc[] = DRIVER_DESC;
 static const char ep0name[] = "ep0-control";
 
 /* Max packet size*/
-- 
2.7.4

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


Re: [U-Boot] [PATCHv5 03/17] dm: pci: remove pci_bus_to_hose(0) calling

2016-12-13 Thread Z.Q. Hou
Hi Bin,

Thanks for your review!

B.R
Zhiqiang

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: 2016年12月13日 15:48
> To: Z.Q. Hou 
> Cc: U-Boot Mailing List ; Albert ARIBAUD
> ; Prabhakar Kushwaha
> ; Alison Wang ;
> Sumit Garg ; Ruchika Gupta ;
> york sun ; M.H. Lian ; Simon
> Glass ; Mingkai Hu 
> Subject: Re: [PATCHv5 03/17] dm: pci: remove pci_bus_to_hose(0) calling
> 
> On Tue, Dec 13, 2016 at 2:54 PM, Zhiqiang Hou 
> wrote:
> > From: Minghuan Lian 
> >
> > There may be multiple PCIe controllers in a SoC.
> > It is not correct that always calling pci_bus_to_hose(0) to get the
> > first PCIe controller for the PCIe device connected other controllers.
> > We just remove this calling because hose always point the correct PCIe
> > controller.
> >
> > Signed-off-by: Minghuan Lian 
> > Signed-off-by: Hou Zhiqiang 
> > Reviewed-by: Simon Glass 
> > ---
> > V5:
> >  - No change
> >
> >  drivers/pci/pci_common.c | 17 +++--
> >  1 file changed, 7 insertions(+), 10 deletions(-)
> >
> 
> Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mmc: sdhci-cadence: add Cadence SD4HC support

2016-12-13 Thread Masahiro Yamada
Hi Jaehoon,

2016-12-14 11:15 GMT+09:00 Jaehoon Chung :

>> + host->name = dev->name;
>> + host->ioaddr = plat->hrs_addr + SDHCI_CDNS_SRS_BASE;
>> + host->version = SDHCI_SPEC_300;
>
> Maybe you don't put this..version is checked in sdhci_setup_cfg() with 
> register.
>

You are right, this line seems unnecessary.

I will fix it in v2. Thanks!




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


Re: [U-Boot] [RFC PATCH 1/3] sunxi: Add clocks for DE2/HDMI/TCON

2016-12-13 Thread Chen-Yu Tsai
On Wed, Dec 14, 2016 at 3:20 AM, Jernej Škrabec  wrote:
> Hi,
>
> On Tue, Dec 13, 2016 at 16:18:58 CET, Maxime Ripard wrote:
>> Hi,
>>
>> First off, thanks a lot for working on this.
>>
>> On Tue, Dec 13, 2016 at 01:36:28AM +0100, Jernej Skrabec wrote:
>> > This is needed for HDMI support, which will be added later.
>> >
>> > Signed-off-by: Jernej Skrabec 
>> > ---
>> >
>> >  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 43
>> >  +++ arch/arm/mach-sunxi/clock_sun6i.c
>> >   | 28 + 2 files changed, 71 insertions(+)
>> >
>> > diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> > b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h index be9fcfd..c19c200
>> > 100644
>> > --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> > +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> > @@ -67,12 +67,20 @@ struct sunxi_ccm_reg {
>> >
>> > u32 dram_pll_cfg;   /* 0xf8 PLL_DDR cfg register, A33 only */
>> > u32 mbus_reset; /* 0xfc MBUS reset control, A33 only */
>> > u32 dram_clk_gate;  /* 0x100 DRAM module gating */
>> >
>> > +#ifdef CONFIG_MACH_SUN8I_H3
>> > +   u32 de_clk_cfg; /* 0x104 DE module clock */
>> > +#else
>> >
>> > u32 be0_clk_cfg;/* 0x104 BE0 module clock */
>> >
>> > +#endif
>> >
>> > u32 be1_clk_cfg;/* 0x108 BE1 module clock */
>> > u32 fe0_clk_cfg;/* 0x10c FE0 module clock */
>> > u32 fe1_clk_cfg;/* 0x110 FE1 module clock */
>> > u32 mp_clk_cfg; /* 0x114 MP module clock */
>> >
>> > +#ifdef CONFIG_MACH_SUN8I_H3
>> > +   u32 tcon0_clk_cfg;  /* 0x118 TCON0 module clock */
>> > +#else
>> >
>> > u32 lcd0_ch0_clk_cfg;   /* 0x118 LCD0 CH0 module clock */
>> >
>> > +#endif
>> >
>> > u32 lcd1_ch0_clk_cfg;   /* 0x11c LCD1 CH0 module clock */
>> > u32 reserved14[3];
>> > u32 lcd0_ch1_clk_cfg;   /* 0x12c LCD0 CH1 module clock */
>> >
>> > @@ -85,7 +93,11 @@ struct sunxi_ccm_reg {
>> >
>> > u32 dmic_clk_cfg;   /* 0x148 Digital Mic module clock*/
>> > u32 reserved15;
>> > u32 hdmi_clk_cfg;   /* 0x150 HDMI module clock */
>> >
>> > +#ifdef CONFIG_MACH_SUN8I_H3
>> > +   u32 hdmi_slow_clk_cfg;  /* 0x154 HDMI slow module clock */
>> > +#else
>> >
>> > u32 ps_clk_cfg; /* 0x154 PS module clock */
>> >
>> > +#endif
>> >
>> > u32 mtc_clk_cfg;/* 0x158 MTC module clock */
>> > u32 mbus0_clk_cfg;  /* 0x15c MBUS0 module clock */
>> > u32 mbus1_clk_cfg;  /* 0x160 MBUS1 module clock */
>> >
>> > @@ -220,6 +232,15 @@ struct sunxi_ccm_reg {
>> >
>> >  #define CCM_MIPI_PLL_CTRL_LDO_EN   (0x3 << 22)
>> >  #define CCM_MIPI_PLL_CTRL_EN   (0x1 << 31)
>> >
>> > +#define CCM_PLL10_CTRL_M_SHIFT 0
>> > +#define CCM_PLL10_CTRL_M_MASK  (0xf << CCM_PLL10_CTRL_M_SHIFT)
>> > +#define CCM_PLL10_CTRL_M(n)n) - 1) & 0xf) << 0)
>> > +#define CCM_PLL10_CTRL_N_SHIFT 8
>> > +#define CCM_PLL10_CTRL_N_MASK  (0x7f << 
>> > CCM_PLL10_CTRL_N_SHIFT)
>> > +#define CCM_PLL10_CTRL_N(n)n) - 1) & 0x7f) << 8)
>> > +#define CCM_PLL10_CTRL_INTEGER_MODE(0x1 << 24)
>> > +#define CCM_PLL10_CTRL_EN  (0x1 << 31)
>> > +
>> >
>> >  #define CCM_PLL11_CTRL_N(n)n) - 1) & 0x3f) << 8)
>> >  #define CCM_PLL11_CTRL_SIGMA_DELTA_EN  (0x1 << 24)
>> >  #define CCM_PLL11_CTRL_UPD (0x1 << 30)
>> >
>> > @@ -271,9 +292,12 @@ struct sunxi_ccm_reg {
>> >
>> >  #define AHB_GATE_OFFSET_DRC0   25
>> >  #define AHB_GATE_OFFSET_DE_FE0 14
>> >  #define AHB_GATE_OFFSET_DE_BE0 12
>> >
>> > +#define AHB_GATE_OFFSET_DE 12
>> >
>> >  #define AHB_GATE_OFFSET_HDMI   11
>> >  #define AHB_GATE_OFFSET_LCD1   5
>> >  #define AHB_GATE_OFFSET_LCD0   4
>> >
>> > +#define AHB_GATE_OFFSET_TCON1  4
>> > +#define AHB_GATE_OFFSET_TCON0  3
>>
>> Maybe having some ifdef here would help, only to differentiate between
>> the DE1 and DE2 cases that would require different defines here.
>>
>> Note that it also applies to the rest of that patch.
>
> You mean something like this?
>
> #ifdef CONFIG_SUNXI_DE2
> #define AHB_GATE_OFFSET_TCON1   4
> #define AHB_GATE_OFFSET_TCON0   3
> #else
> #define AHB_GATE_OFFSET_LCD15
> #define AHB_GATE_OFFSET_LCD04
> #endif

LCD/TCON seems like a bad example though... They really are the
same thing, and Allwinner uses LCD / TCON interchangeably in the
manuals of the old SoCs.

The difference in the new SoCs is simply they moved the offsets.
For this particular case, can you use the old names instead?
I think this will also help with pulling the TCON code into
a separate library or driver.

For the DE clocks, you should probably enclose all the DE FE/BE
clock registers and defines in the DE 1.0 block, and add reserved
blocks for 

Re: [U-Boot] [PATCH] mmc: sdhci-cadence: add Cadence SD4HC support

2016-12-13 Thread Jaehoon Chung
Hi Masahiro.

On 12/09/2016 03:46 PM, Masahiro Yamada wrote:
> Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  - This is a counterpart of the Linux driver,
>which has been merged in the MMC subsystem:
>(commit ff6af28fa in linux-next)
>The DT binding for this driver should be referred
>in the kernel tree.
> 
>  - This will be applied cleanly after my SDHCI Kconfig moves:
>http://patchwork.ozlabs.org/patch/703578/
>Until then, please review.
> 
> 
>  drivers/mmc/Kconfig |  13 +
>  drivers/mmc/Makefile|   1 +
>  drivers/mmc/sdhci-cadence.c | 125 
> 
>  3 files changed, 139 insertions(+)
>  create mode 100644 drivers/mmc/sdhci-cadence.c
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 12df3cf..9ca2f98 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -159,6 +159,19 @@ config MMC_SDHCI_BCM2835
>  
> If unsure, say N.
>  
> +config MMC_SDHCI_CADENCE
> + bool "SDHCI support for the Cadence SD/SDIO/eMMC controller"
> + depends on MMC_SDHCI
> + depends on DM_MMC_OPS
> + depends on BLK
> + depends on OF_CONTROL
> + help
> +   This selects the Cadence SD/SDIO/eMMC driver.
> +
> +   If you have a controller with this interface, say Y or M here.
> +
> +   If unsure, say N.
> +
>  config MMC_SDHCI_KONA
>   bool "SDHCI support on Broadcom KONA platform"
>   depends on MMC_SDHCI
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 2b136ea..a543188 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -64,6 +64,7 @@ obj-$(CONFIG_MSM_SDHCI) += msm_sdhci.o
>  # SDHCI
>  obj-$(CONFIG_MMC_SDHCI)  += sdhci.o
>  obj-$(CONFIG_MMC_SDHCI_BCM2835)  += bcm2835_sdhci.o
> +obj-$(CONFIG_MMC_SDHCI_CADENCE)  += sdhci-cadence.o
>  obj-$(CONFIG_MMC_SDHCI_KONA) += kona_sdhci.o
>  obj-$(CONFIG_MMC_SDHCI_MV)   += mv_sdhci.o
>  obj-$(CONFIG_MMC_SDHCI_S5P)  += s5p_sdhci.o
> diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
> new file mode 100644
> index 000..1a59a5d
> --- /dev/null
> +++ b/drivers/mmc/sdhci-cadence.c
> @@ -0,0 +1,125 @@
> +/*
> + * Copyright (C) 2016 Socionext Inc.
> + *   Author: Masahiro Yamada 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* HRS - Host Register Set (specific to Cadence) */
> +#define SDHCI_CDNS_HRS04 0x10/* PHY access port */
> +#define   SDHCI_CDNS_HRS04_ACK   BIT(26)
> +#define   SDHCI_CDNS_HRS04_RDBIT(25)
> +#define   SDHCI_CDNS_HRS04_WRBIT(24)
> +#define   SDHCI_CDNS_HRS04_RDATA_SHIFT   12
> +#define   SDHCI_CDNS_HRS04_WDATA_SHIFT   8
> +#define   SDHCI_CDNS_HRS04_ADDR_SHIFT0
> +
> +/* SRS - Slot Register Set (SDHCI-compatible) */
> +#define SDHCI_CDNS_SRS_BASE  0x200
> +
> +/* PHY */
> +#define SDHCI_CDNS_PHY_DLY_SD_HS 0x00
> +#define SDHCI_CDNS_PHY_DLY_SD_DEFAULT0x01
> +#define SDHCI_CDNS_PHY_DLY_UHS_SDR12 0x02
> +#define SDHCI_CDNS_PHY_DLY_UHS_SDR25 0x03
> +#define SDHCI_CDNS_PHY_DLY_UHS_SDR50 0x04
> +#define SDHCI_CDNS_PHY_DLY_UHS_DDR50 0x05
> +#define SDHCI_CDNS_PHY_DLY_EMMC_LEGACY   0x06
> +#define SDHCI_CDNS_PHY_DLY_EMMC_SDR  0x07
> +#define SDHCI_CDNS_PHY_DLY_EMMC_DDR  0x08
> +
> +struct sdhci_cdns_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> + void __iomem *hrs_addr;
> +};
> +
> +static void sdhci_cdns_write_phy_reg(struct sdhci_cdns_plat *plat,
> +  u8 addr, u8 data)
> +{
> + void __iomem *reg = plat->hrs_addr + SDHCI_CDNS_HRS04;
> + u32 tmp;
> +
> + tmp = (data << SDHCI_CDNS_HRS04_WDATA_SHIFT) |
> +   (addr << SDHCI_CDNS_HRS04_ADDR_SHIFT);
> + writel(tmp, reg);
> +
> + tmp |= SDHCI_CDNS_HRS04_WR;
> + writel(tmp, reg);
> +
> + tmp &= ~SDHCI_CDNS_HRS04_WR;
> + writel(tmp, reg);

Is there a special reason for writing after reading?

> +}
> +
> +static void sdhci_cdns_phy_init(struct sdhci_cdns_plat *plat)
> +{
> + sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_SD_HS, 4);
> + sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_SD_DEFAULT, 4);
> + sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_EMMC_LEGACY, 9);
> + sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_EMMC_SDR, 2);
> + sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_EMMC_DDR, 3);
> +}
> +
> +static int sdhci_cdns_bind(struct udevice *dev)
> +{
> + struct sdhci_cdns_plat *plat = dev_get_platdata(dev);
> +
> + return sdhci_bind(dev, >mmc, >cfg);
> +}
> +
> +static int sdhci_cdns_probe(struct udevice *dev)
> +{
> + struct mmc_uclass_priv *upriv 

Re: [U-Boot] [PATCH v2 0/6] cleanup and enhancements for Colibri VFxx

2016-12-13 Thread Stefan Agner
On 2016-11-30 13:41, Stefan Agner wrote:
> From: Stefan Agner 
> 
> This patchset cleans up the board file, speeds up NAND slightly
> and enhances the board support with device tree MTD partition
> support.
> 
> It also fixes a bug in the new Toradex config block code.
> 
> Not sure through which tree that should go, especially since
> patch 1 and 2 touches common code... Tom?

Anything holding us back merging this?

--
Stefan

> 
> --
> Stefan
> 
> Changes in v2:
> - Rebased ontop of master (after config block support merged)
> - Add patch which uses proper config to guard g_dnl_bind_fixup
> - Add patch to fix device tree warning
> 
> Stefan Agner (6):
>   toradex: fix USB Download gadget fixup callback
>   toradex: allow custom fdt board setup in board file
>   colibri_vf: use device-tree for MTD partitions
>   colibri_vf: cleanup USB clock initialization
>   colibri_vf: use same NAND clock as Linux uses
>   ARM: dts: vf: Fix warning about missing reg property
> 
>  arch/arm/dts/vf.dtsi  |  2 ++
>  board/toradex/apalis_t30/apalis_t30.c |  8 ++
>  board/toradex/colibri_imx7/colibri_imx7.c |  8 ++
>  board/toradex/colibri_pxa270/colibri_pxa270.c |  8 ++
>  board/toradex/colibri_t20/colibri_t20.c   |  8 ++
>  board/toradex/colibri_t30/colibri_t30.c   |  8 ++
>  board/toradex/colibri_vf/colibri_vf.c | 37 
> +++
>  board/toradex/common/tdx-common.c | 12 -
>  board/toradex/common/tdx-common.h |  2 ++
>  9 files changed, 81 insertions(+), 12 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-13 Thread Icenowy Zheng


14.12.2016, 04:29, "Simon Glass" :
> Hi,
>
> On 12 December 2016 at 19:36, Jernej Skrabec  wrote:
>>  This patch series add support for HDMI output. Support for other,
>>  newer, SoCs, which also uses DE2 and same or similar HDMI controller
>>  and PHY can be easily added later (A83T/A64/H5/R40). Current driver
>>  can also be easily extended with TV out support, just like video
>>  driver for older Allwinner SoCs.
>>
>>  While driver works, I would like to get few opinions first.
>>  - From what I understand, drivers which supports DT are preferred.
>>    Would it be better to rewrite this driver to support device tree?
>
> Yes I think so, and in fact it should use driver model also.
>
> The rockchip driver provides a reasonable example of how to split the
> driver up as you suggest below. The VIDEO driver provides the
> top-level video interface, DISPLAY drivers provide display output for
> the video, and you have PANEL as well for receiving the display
> output. VIDCONSOLE works automatically to display text.
>
> I actually took a bit of a look at this a few weeks ago so am happy to
> help with review or discussions.

Yes, I think go to Driver Model is also valuable, as Allwinner's display parts
are really in reusable components.

In addition, Driver Model provides the possibility to use EFI GOP, which can
be a more standardized replacement of SimpleFB, especially for OSes other
than Linux. (For example, Windows, if we can really get it running ;-) )

>
>>  - TCON code is currently exactly the same as in driver for older
>>    SoCs. Should I split it out into shared module? Also TV out code
>>    seems to be similar, but I didn't manage to confirm that it works
>>    as-is on H3.
>>  - A80 SoC is mix of older display engine and newer HDMI controller,
>>    so it doesn't really work with either of sunxi video drivers. Two
>>    solutions I see here are either combine both driver into one massive
>>    display driver or, much better, split everything by components
>>    (TCON/DE/DE2/HDMI/TV) and instantiate compatible ones. I guess this
>>    is not much different than adding support for DT in drivers. Note
>>    that I don't have any A80 board, I'm just thinking ahead.
>>
>>  Best regards,
>>  Jernej Skrabec
>>
>>  Jernej Skrabec (3):
>>    sunxi: Add clocks for DE2/HDMI/TCON
>>    sunxi: video: Add video driver for H3 SoC
>>    sunxi: Enable H3 video driver in defconfigs
>>
>>   arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 43 +
>>   arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 +
>>   arch/arm/include/asm/arch-sunxi/display2.h | 377 +
>>   arch/arm/mach-sunxi/clock_sun6i.c | 28 +
>>   board/sunxi/Kconfig | 4 +-
>>   configs/orangepi_2_defconfig | 1 +
>>   configs/orangepi_lite_defconfig | 1 +
>>   configs/orangepi_one_defconfig | 1 +
>>   configs/orangepi_pc_defconfig | 1 +
>>   configs/orangepi_pc_plus_defconfig | 1 +
>>   configs/orangepi_plus2e_defconfig | 1 +
>>   configs/orangepi_plus_defconfig | 1 +
>>   drivers/video/Makefile | 1 +
>>   drivers/video/sunxi_display2.c | 1037 +
>>   include/configs/sunxi-common.h | 17 +-
>>   scripts/config_whitelist.txt | 1 +
>>   16 files changed, 1516 insertions(+), 7 deletions(-)
>>   create mode 100644 arch/arm/include/asm/arch-sunxi/display2.h
>>   create mode 100644 drivers/video/sunxi_display2.c
>>
>>  --
>>  2.10.2
>
> Regards,
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Enable redundant u-boot environment for iMX6 (Yocto)

2016-12-13 Thread brendan
Hello,

I'm looking to enable a redundancy enabled "ping-pong" u-boot environment
for my iMX6 (VAR-SOM-MX6 CPU: NXP/Freescale iMX6) to ensure that if there
was system failure that there will always be a CRC checked and valid
environment available in NAND flash.  I have read the documentation and
noticed that there is the available functionality of CONFIG_ENV_ADDR_REDUND
and CONFIG_ENV_SIZE_REDUND.

My questions are; how do I determine my redundant address and size?  Should
they just match my original defines?  I am using a custom mtd partition
sizing which I have configured by the use of a sw-description file (using
swupdate to handle the update process), will there be any issues that can be
foreseen?

Also, because I am using Yocto (I know this is outside the scope of u-boot)
would it be wise to add a patch or append file within Yocto?  or simply host
this in a separate repository?

Any help would be greatly appreciated, I cannot find any in depth
documentation relating to this so I am looking for any resources available.

Regards,
Brendan



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Enable-redundant-u-boot-environment-for-iMX6-Yocto-tp276498.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image

2016-12-13 Thread Simon Glass
Hi Igor,

On 12 December 2016 at 01:37, Igor Grinberg  wrote:
> On 12/11/16 22:27, Simon Glass wrote:
>> Hi Igor,
>>
>> On 11 December 2016 at 10:37, Igor Grinberg  wrote:
>>> Hi Tomas, Simon,
>>>
>>> Sorry, to break in that late...
>>> I have a quick question below.
>>>
>>> On 12/05/16 09:36, Tomas Melin wrote:
 Enable support for loading a splash image from within a FIT image.
 The image is assumed to be generated with mkimage -E flag to hold
 the data external to the FIT.

 Signed-off-by: Tomas Melin 
>>>
>>> [...]
>>>
 diff --git a/common/splash_source.c b/common/splash_source.c
 index 70d724f..94b46d3 100644
 --- a/common/splash_source.c
 +++ b/common/splash_source.c
>>>
>>> [...]
>>>
 +#ifdef CONFIG_FIT
 +static int splash_load_fit(struct splash_location *location, u32 
 bmp_load_addr)
 +{
 + int res;
 + int node_offset;
 + int splash_offset;
 + int splash_size;
 + struct image_header *img_header;
 + const u32 *fit_header;
 + u32 fit_size;
 + const size_t header_size = sizeof(struct image_header);
 +
 + /* Read in image header */
 + res = splash_storage_read_raw(location, bmp_load_addr, header_size);
 + if (res < 0)
 + return res;
 +
 + img_header = (struct image_header *)bmp_load_addr;
 + fit_size = fdt_totalsize(img_header);
 +
 + /* Read in entire FIT */
 + fit_header = (const u32 *)(bmp_load_addr + header_size);
 + res = splash_storage_read_raw(location, (u32)fit_header, fit_size);
 + if (res < 0)
 + return res;
 +
 + res = fit_check_format(fit_header);
 + if (!res) {
 + debug("Could not find valid FIT image\n");
 + return -EINVAL;
 + }
 +
 + node_offset = fit_image_get_node(fit_header, location->name);
 + if (node_offset < 0) {
 + debug("Could not find splash image '%s' in FIT\n",
 +   location->name);
 + return -ENOENT;
 + }
 +
>>>
>>> I think two above debug() are very legitimate - no need to shout if no FIT 
>>> image
>>> or no splash in it...
>>>
 + res = fit_image_get_data_offset(fit_header, node_offset,
 + _offset);
 + if (res < 0) {
 + debug("Could not find 'data-offset' property in FIT\n");
 + return res;
 + }
 +
 + res = fit_image_get_data_size(fit_header, node_offset, _size);
 + if (res < 0) {
 + debug("Could not find 'data-size' property in FIT\n");
 + return res;
 + }
>>>
>>> Now regarding these two, I'm not sure.
>>> Since we have found a valid FIT and also a node with a correct splash name,
>>> probably the intent is that we show the splash, right?
>>> But in the two above checks, we find inconsistencies that do not allow us to
>>> show the splash - meaning the FIT is not actually good (am I right here?).
>>> So may be we should report it to the 'user' and allow correcting the FIT?
>>> Otherwise, it is impossible to debug the image w/o a debug version of 
>>> U-Boot...
>>> Do I make sense, or do I miss something?
>>
>> Yes that makes some sense, but the problem is that then you are
>> including error messages always which would never happen in a working
>> system (i.e. it just bloats the code).
>
> Unless, there a kind of corruption or a user mistake and then that same
> user can't even understand what happened because we do not help him with
> an error message.
> You cannot know that these error messages will never happen...
> This is a generic code which can be used by a wide variety of platforms -
> I don't think you can foresee all the possible use cases.
>
> We are talking about several tens of bytes vs. usability.
> If there is an error, it should be stated as such. It should not just
> exit silently...

I agree with that, there should definitely be an error printed. It
should say something like 'Failed to load splash screen (err=-4)' or
something like that. The error number should provide some clues and
people can dig in.

This patch would add around 200 bytes if debug() was changed to
printf(). Multiply that by several hundred if we did that sort of
thing throughout U-Boot.

>
> I think that debug() is a good thing to use, but we shouldn't be obsessed
> with it.

Fair enough, I don't want to get obsessed about it either! But general
code-size bloat is a real problem. so I think in general we should
make sure an error is printed when one occurs, and only cover some
common cases where the user can actually fix it (e.g SD card missing)
with more detailed error messages.

>
>>
>> So long as the error is reported (even if it is not a very specific
>> error), people can add DEBUG and 

Re: [U-Boot] [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-13 Thread Simon Glass
Hi,

On 12 December 2016 at 19:36, Jernej Skrabec  wrote:
> This patch series add support for HDMI output. Support for other,
> newer, SoCs, which also uses DE2 and same or similar HDMI controller
> and PHY can be easily added later (A83T/A64/H5/R40). Current driver
> can also be easily extended with TV out support, just like video
> driver for older Allwinner SoCs.
>
> While driver works, I would like to get few opinions first.
> - From what I understand, drivers which supports DT are preferred.
>   Would it be better to rewrite this driver to support device tree?

Yes I think so, and in fact it should use driver model also.

The rockchip driver provides a reasonable example of how to split the
driver up as you suggest below. The VIDEO driver provides the
top-level video interface, DISPLAY drivers provide display output for
the video, and you have PANEL as well for receiving the display
output. VIDCONSOLE works automatically to display text.

I actually took a bit of a look at this a few weeks ago so am happy to
help with review or discussions.

> - TCON code is currently exactly the same as in driver for older
>   SoCs. Should I split it out into shared module? Also TV out code
>   seems to be similar, but I didn't manage to confirm that it works
>   as-is on H3.
> - A80 SoC is mix of older display engine and newer HDMI controller,
>   so it doesn't really work with either of sunxi video drivers. Two
>   solutions I see here are either combine both driver into one massive
>   display driver or, much better, split everything by components
>   (TCON/DE/DE2/HDMI/TV) and instantiate compatible ones. I guess this
>   is not much different than adding support for DT in drivers. Note
>   that I don't have any A80 board, I'm just thinking ahead.
>
> Best regards,
> Jernej Skrabec
>
>
> Jernej Skrabec (3):
>   sunxi: Add clocks for DE2/HDMI/TCON
>   sunxi: video: Add video driver for H3 SoC
>   sunxi: Enable H3 video driver in defconfigs
>
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h |   43 +
>  arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |8 +
>  arch/arm/include/asm/arch-sunxi/display2.h|  377 +
>  arch/arm/mach-sunxi/clock_sun6i.c |   28 +
>  board/sunxi/Kconfig   |4 +-
>  configs/orangepi_2_defconfig  |1 +
>  configs/orangepi_lite_defconfig   |1 +
>  configs/orangepi_one_defconfig|1 +
>  configs/orangepi_pc_defconfig |1 +
>  configs/orangepi_pc_plus_defconfig|1 +
>  configs/orangepi_plus2e_defconfig |1 +
>  configs/orangepi_plus_defconfig   |1 +
>  drivers/video/Makefile|1 +
>  drivers/video/sunxi_display2.c| 1037 
> +
>  include/configs/sunxi-common.h|   17 +-
>  scripts/config_whitelist.txt  |1 +
>  16 files changed, 1516 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-sunxi/display2.h
>  create mode 100644 drivers/video/sunxi_display2.c
>
> --
> 2.10.2
>

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


Re: [U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

2016-12-13 Thread Jernej Škrabec
Hi,

On Tue, Dec 13, 2016 at 16:40:55 CET, Maxime Ripard wrote:
> Hi,
> 
> On Tue, Dec 13, 2016 at 01:36:29AM +0100, Jernej Skrabec wrote:
> > This patch adds support for hdmi output. It is designed in the same
> > way as video driver for older Allwinner SoCs.
> > 
> > First it checks if monitor is attached. If it is, recommended
> > timings are read from EDID. After that, DE2, TCON and HDMI are
> > configured according to this timings.
> > 
> > 32MB of RAM is used for framebuffer. This is just enough to support
> > 4K resolution.
> > 
> > SimpleFB is also supported by this driver.
> > 
> > Signed-off-by: Jernej Skrabec 
> 
> From the linux discussion, I recall that you said that the TCON was
> still the same, and the HDMI was something that could be shared with
> the Rockchip implementation. Did you look into sharing the TCON code
> (for example using a small "library" to share the functions) and to
> reuse Rockchip's HDMI code?

For now, I only reused one TCON function and some defines. I tought that split 
would be better done a bit later, when the driver will get support for LCD 
screens (A64, for example). At that time TCON code would also be refactored to 
be more generic and properly tested that it can be used with both drivers. 
Unfortunatelly, I don't have any board with older SoC for testing.

While I took Rockchip HDMI code for reference, it can't be easily reused. 
First of, it uses DT nodes. I guess I could write DT binding or modify 
existing driver to work without it. Second issue here is same as in Linux, PHY 
code is tightly coupled with controller code, so it needs to be decoupled 
first. Thirdly, and in my opinion most annoying, Rockchip driver uses 32 bit 
aligned registers, but H3 does not. This also means a lot of work to make it 
more generic. Actually, H3 is more similar to i.MX6 HDMI in this regard, but 
driver's code is scattered throughout multiple files (search for mxc_hdmi.h 
inclusion). It is certainly doable, but it will take much more time.
Basically, U-Boot already has two drivers for DWC HDMI and with this patch it 
will get third. Merging all three implementations into one would be very 
tedious, but very desirable goal. I must state that I didn't really try to 
understand i.MX6 HDMI code at all, so I don't now how hard it would be to pull 
it out.

By the way, did you get cover letter?

Best regards,
Jernej Skrabec

> 
> Thanks,
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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


[U-Boot] [PATCH] i2c: mv_i2c.c: Correct address endianness

2016-12-13 Thread Bradley Bolen
0c0f719ad2f46c8566a56daee37ebdb7c078c3b1 accidentally changed the
endianness of the i2c read and write addresses.  This was noticable when
accessing EEPROMs that use 2 byte addressing as the LSB was being sent
first.

Signed-off-by: Bradley Bolen 
---
 drivers/i2c/mv_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c
index 7f52fa2..c780272 100644
--- a/drivers/i2c/mv_i2c.c
+++ b/drivers/i2c/mv_i2c.c
@@ -270,7 +270,7 @@ static int __i2c_read(struct mv_i2c *base, uchar chip, u8 
*addr, int alen,
msg.condition = I2C_COND_NORMAL;
msg.acknack   = I2C_ACKNAK_WAITACK;
msg.direction = I2C_WRITE;
-   msg.data  = *(addr++);
+   msg.data  = addr[alen];
if (i2c_transfer(base, ))
return -1;
}
@@ -341,7 +341,7 @@ static int __i2c_write(struct mv_i2c *base, uchar chip, u8 
*addr, int alen,
msg.condition = I2C_COND_NORMAL;
msg.acknack   = I2C_ACKNAK_WAITACK;
msg.direction = I2C_WRITE;
-   msg.data  = *(addr++);
+   msg.data  = addr[alen];
if (i2c_transfer(base, ))
return -1;
}
-- 
2.7.4

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


Re: [U-Boot] [RFC PATCH 1/3] sunxi: Add clocks for DE2/HDMI/TCON

2016-12-13 Thread Jernej Škrabec
Hi,

On Tue, Dec 13, 2016 at 16:18:58 CET, Maxime Ripard wrote:
> Hi,
> 
> First off, thanks a lot for working on this.
> 
> On Tue, Dec 13, 2016 at 01:36:28AM +0100, Jernej Skrabec wrote:
> > This is needed for HDMI support, which will be added later.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 43
> >  +++ arch/arm/mach-sunxi/clock_sun6i.c   
> >   | 28 + 2 files changed, 71 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> > b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h index be9fcfd..c19c200
> > 100644
> > --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> > +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> > @@ -67,12 +67,20 @@ struct sunxi_ccm_reg {
> > 
> > u32 dram_pll_cfg;   /* 0xf8 PLL_DDR cfg register, A33 only */
> > u32 mbus_reset; /* 0xfc MBUS reset control, A33 only */
> > u32 dram_clk_gate;  /* 0x100 DRAM module gating */
> > 
> > +#ifdef CONFIG_MACH_SUN8I_H3
> > +   u32 de_clk_cfg; /* 0x104 DE module clock */
> > +#else
> > 
> > u32 be0_clk_cfg;/* 0x104 BE0 module clock */
> > 
> > +#endif
> > 
> > u32 be1_clk_cfg;/* 0x108 BE1 module clock */
> > u32 fe0_clk_cfg;/* 0x10c FE0 module clock */
> > u32 fe1_clk_cfg;/* 0x110 FE1 module clock */
> > u32 mp_clk_cfg; /* 0x114 MP module clock */
> > 
> > +#ifdef CONFIG_MACH_SUN8I_H3
> > +   u32 tcon0_clk_cfg;  /* 0x118 TCON0 module clock */
> > +#else
> > 
> > u32 lcd0_ch0_clk_cfg;   /* 0x118 LCD0 CH0 module clock */
> > 
> > +#endif
> > 
> > u32 lcd1_ch0_clk_cfg;   /* 0x11c LCD1 CH0 module clock */
> > u32 reserved14[3];
> > u32 lcd0_ch1_clk_cfg;   /* 0x12c LCD0 CH1 module clock */
> > 
> > @@ -85,7 +93,11 @@ struct sunxi_ccm_reg {
> > 
> > u32 dmic_clk_cfg;   /* 0x148 Digital Mic module clock*/
> > u32 reserved15;
> > u32 hdmi_clk_cfg;   /* 0x150 HDMI module clock */
> > 
> > +#ifdef CONFIG_MACH_SUN8I_H3
> > +   u32 hdmi_slow_clk_cfg;  /* 0x154 HDMI slow module clock */
> > +#else
> > 
> > u32 ps_clk_cfg; /* 0x154 PS module clock */
> > 
> > +#endif
> > 
> > u32 mtc_clk_cfg;/* 0x158 MTC module clock */
> > u32 mbus0_clk_cfg;  /* 0x15c MBUS0 module clock */
> > u32 mbus1_clk_cfg;  /* 0x160 MBUS1 module clock */
> > 
> > @@ -220,6 +232,15 @@ struct sunxi_ccm_reg {
> > 
> >  #define CCM_MIPI_PLL_CTRL_LDO_EN   (0x3 << 22)
> >  #define CCM_MIPI_PLL_CTRL_EN   (0x1 << 31)
> > 
> > +#define CCM_PLL10_CTRL_M_SHIFT 0
> > +#define CCM_PLL10_CTRL_M_MASK  (0xf << CCM_PLL10_CTRL_M_SHIFT)
> > +#define CCM_PLL10_CTRL_M(n)n) - 1) & 0xf) << 0)
> > +#define CCM_PLL10_CTRL_N_SHIFT 8
> > +#define CCM_PLL10_CTRL_N_MASK  (0x7f << CCM_PLL10_CTRL_N_SHIFT)
> > +#define CCM_PLL10_CTRL_N(n)n) - 1) & 0x7f) << 8)
> > +#define CCM_PLL10_CTRL_INTEGER_MODE(0x1 << 24)
> > +#define CCM_PLL10_CTRL_EN  (0x1 << 31)
> > +
> > 
> >  #define CCM_PLL11_CTRL_N(n)n) - 1) & 0x3f) << 8)
> >  #define CCM_PLL11_CTRL_SIGMA_DELTA_EN  (0x1 << 24)
> >  #define CCM_PLL11_CTRL_UPD (0x1 << 30)
> > 
> > @@ -271,9 +292,12 @@ struct sunxi_ccm_reg {
> > 
> >  #define AHB_GATE_OFFSET_DRC0   25
> >  #define AHB_GATE_OFFSET_DE_FE0 14
> >  #define AHB_GATE_OFFSET_DE_BE0 12
> > 
> > +#define AHB_GATE_OFFSET_DE 12
> > 
> >  #define AHB_GATE_OFFSET_HDMI   11
> >  #define AHB_GATE_OFFSET_LCD1   5
> >  #define AHB_GATE_OFFSET_LCD0   4
> > 
> > +#define AHB_GATE_OFFSET_TCON1  4
> > +#define AHB_GATE_OFFSET_TCON0  3
> 
> Maybe having some ifdef here would help, only to differentiate between
> the DE1 and DE2 cases that would require different defines here.
> 
> Note that it also applies to the rest of that patch.

You mean something like this?

#ifdef CONFIG_SUNXI_DE2
#define AHB_GATE_OFFSET_TCON1   4
#define AHB_GATE_OFFSET_TCON0   3
#else
#define AHB_GATE_OFFSET_LCD15
#define AHB_GATE_OFFSET_LCD04
#endif

and then in include/configs/sun8i.h something like this?

#if defined(CONFIG_MACH_SUN8I_H3)
#define CONFIG_SUNXI_DE21
#endif

Best regards,
Jernej Skrabec

> 
> Thanks,
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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


[U-Boot] [U-boot] [bug report] After update from "2016.01" to "2016.09.01" display is shifted vertically - atmel lcd fb

2016-12-13 Thread Robert Grzyb
Current version of "drivers\video\atmel_lcdfb.c" seem to contain a
typo in the "lcd_ctrl_init" function:


diff -Naur u-boot-2016.09.01.orig/drivers/video/atmel_lcdfb.c
u-boot-2016.09.01/drivers/video/atmel_lcdfb.c
--- u-boot-2016.09.01.orig/drivers/video/atmel_lcdfb.c2016-09-19
16:45:12.0 +0100
+++ u-boot-2016.09.01/drivers/video/atmel_lcdfb.c2016-12-13
16:49:29.966346400 +
@@ -228,9 +228,9 @@
 timing.hsync_len.typ = panel_info.vl_hsync_len;

 timing.vactive.typ = panel_info.vl_row;
-timing.vfront_porch.typ = panel_info.vl_clk;
-timing.vback_porch.typ = panel_info.vl_clk;
-timing.vsync_len.typ = panel_info.vl_clk;
+timing.vfront_porch.typ = panel_info.vl_lower_margin;
+timing.vback_porch.typ = panel_info.vl_upper_margin;
+timing.vsync_len.typ = panel_info.vl_vsync_len;

 atmel_fb_init(panel_info.mmio, , panel_info.vl_bpix,
   panel_info.vl_tft, panel_info.vl_cont_pol_low,



This change was introduced by this commit:
http://git.denx.de/?p=u-boot.git;a=commit;h=d63ec26a49a1ae8c0fd65c24e8c0b6c67b79cd01
referenced in this thread:
"[U-Boot] [PATCH 15/18] at91: video: Prepare for driver-model conversion"
http://lists.denx.de/pipermail/u-boot/2016-May/253489.html ""

In my case the display was shifted down by approximately 80 pixels but I presume
that this could have other effects depending on the value in 'panel_info.vl_clk'

Hope this helps someone,
Trebor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] armv8/fsl_lsch2: Add the OCRAM initialization

2016-12-13 Thread york sun
On 12/13/2016 01:45 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Clear the content to zero and the ECC error bit of OCRAM1/2.
>
> The OCRAM must be initialized to ZERO by the unit of 8-Byte before
> accessing it, or else it will generate ECC error. And the IBR has
> accessed the OCRAM before this initialization, so the ECC error
> status bit should to be cleared.
>
> Signed-off-by: Hou Zhiqiang 
> Signed-off-by: Pratiyush Srivastava 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  | 37 
> +++
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |  3 ++
>  2 files changed, 40 insertions(+)
>

Zhiqiang,

This looks like an updated version of previous patch "armv8/ls1043a: Add 
the OCRAM initialization". Was there any effort to include LSCH3?

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


[U-Boot] [PATCH v4 09/16] arm: imx6q: Add Engicam i.CoreM6 Solo/Duallite RQS Starter Kit initial support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Boot from MMC:
-
U-Boot SPL 2016.11-rc2-g217bd8e-dirty (Nov 08 2016 - 22:56:07)
Trying to boot from MMC1

U-Boot 2016.11-rc2-g217bd8e-dirty (Nov 08 2016 - 22:56:07 +0530)

CPU:   Freescale i.MX6DL rev1.3 at 792 MHz
Reset cause: POR
Model: Engicam i.CoreM6 DualLite/Solo RQS Starter Kit
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   CPU Net Initialization Failed
No ethernet found.
Hit any key to stop autoboot:  0
icorem6qdl-rqs>

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile  |  1 +
 arch/arm/dts/imx6dl-icore-rqs.dts  | 50 ++
 board/engicam/icorem6_rqs/MAINTAINERS  |  1 +
 board/engicam/icorem6_rqs/README   |  7 +++--
 configs/imx6dl_icore_rqs_mmc_defconfig | 38 ++
 5 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/imx6dl-icore-rqs.dts
 create mode 100644 configs/imx6dl_icore_rqs_mmc_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 96e98c6..7b7a38c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -291,6 +291,7 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
 
 dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6dl-icore.dtb \
+   imx6dl-icore-rqs.dtb \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6ul-geam-kit.dtb
diff --git a/arch/arm/dts/imx6dl-icore-rqs.dts 
b/arch/arm/dts/imx6dl-icore-rqs.dts
new file mode 100644
index 000..0f1de3f
--- /dev/null
+++ b/arch/arm/dts/imx6dl-icore-rqs.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2015 Amarula Solutions B.V.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore-rqs.dtsi"
+
+/ {
+   model = "Engicam i.CoreM6 DualLite/Solo RQS Starter Kit";
+   compatible = "engicam,imx6-icore-rqs", "fsl,imx6q";
+};
diff --git a/board/engicam/icorem6_rqs/MAINTAINERS 
b/board/engicam/icorem6_rqs/MAINTAINERS
index 4c6bd62..0556211 100644
--- a/board/engicam/icorem6_rqs/MAINTAINERS
+++ b/board/engicam/icorem6_rqs/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/engicam/icorem6_rqs
 F: include/configs/imx6qdl_icore_rqs.h
 F: configs/imx6q_icore_rqs_mmc_defconfig
+F: configs/imx6dl_icore_rqs_mmc_defconfig
diff --git a/board/engicam/icorem6_rqs/README b/board/engicam/icorem6_rqs/README
index f94e6e1..ccce622 100644
--- a/board/engicam/icorem6_rqs/README
+++ b/board/engicam/icorem6_rqs/README
@@ -1,11 +1,14 @@
-How to use U-Boot on Engicam i.CoreM6 RQS Quad/Dual Starter Kit:
-
+How to use U-Boot on Engicam i.CoreM6 RQS Solo/DualLite and Quad/Dual Starter 
Kit:
+--
 
 $ make mrproper
 
 - Configure U-Boot for Engicam i.CoreM6 RQS Quad/Dual:
 $ make 

[U-Boot] [PATCH v4 04/16] imx6: geam6ul: Add I2C support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add I2C support for Engicam GEAM6UL module.

geam6ul> i2c bus
Bus 0:  i2c@021a
Bus 1:  i2c@021a4000
geam6ul> i2c dev 0
Setting bus to 0
geam6ul> i2c dev
Current bus is 0
geam6ul> i2c speed 10
Setting bus speed to 10 Hz
geam6ul> i2c probe
Valid chip addresses: 2C
geam6ul> i2c md 2C 0xff
00ff: 00 00 00 00 0f f0 01 64 ff ff 00 00 00 00 00 00...d

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig| 1 +
 configs/imx6ul_geam_mmc_defconfig | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 4ba5338..bbdb5a1 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -163,6 +163,7 @@ config TARGET_MX6UL_GEAM
select OF_CONTROL
select DM
select DM_GPIO
+   select DM_I2C
select DM_MMC
select DM_THERMAL
select SUPPORT_SPL
diff --git a/configs/imx6ul_geam_mmc_defconfig 
b/configs/imx6ul_geam_mmc_defconfig
index 24f3fd6..e1e1dd2 100644
--- a/configs/imx6ul_geam_mmc_defconfig
+++ b/configs/imx6ul_geam_mmc_defconfig
@@ -25,11 +25,13 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
 CONFIG_MXC_UART=y
 CONFIG_IMX_THERMAL=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
+CONFIG_SYS_I2C_MXC=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-- 
1.9.1

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


[U-Boot] [PATCH v4 07/16] imx6: geam6ul: Add default mtd nand partition table

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

geam6ul> mtdparts

device nand0 , # parts = 6
0: spl 0x0020  0x  0
1: uboot   0x0020  0x0020  0
2: env 0x0010  0x0040  0
3: kernel  0x0040  0x0050  0
4: dtb 0x0010  0x0090  0
5: rootfs  0x1f60  0x00a0  0

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 include/configs/imx6ul_geam.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/imx6ul_geam.h b/include/configs/imx6ul_geam.h
index 8938b80..7cfdfef 100644
--- a/include/configs/imx6ul_geam.h
+++ b/include/configs/imx6ul_geam.h
@@ -129,6 +129,8 @@
 # define CONFIG_CMD_MTDPARTS
 # define CONFIG_MTD_PARTITIONS
 # define MTDIDS_DEFAULT"nand0=nand"
+# define MTDPARTS_DEFAULT  "mtdparts=nand:2m(spl),2m(uboot)," \
+   "1m(env),4m(kernel),1m(dtb),-(rootfs)"
 
 # define CONFIG_APBH_DMA
 # define CONFIG_APBH_DMA_BURST
-- 
1.9.1

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


[U-Boot] [PATCH v4 06/16] imx6: geam6ul: Enable MTD device support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Enable MTD device, partition and command support.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 include/configs/imx6ul_geam.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/configs/imx6ul_geam.h b/include/configs/imx6ul_geam.h
index 4fe130b..8938b80 100644
--- a/include/configs/imx6ul_geam.h
+++ b/include/configs/imx6ul_geam.h
@@ -124,6 +124,12 @@
 # define CONFIG_SYS_NAND_U_BOOT_START  CONFIG_SYS_TEXT_BASE
 # define CONFIG_SYS_NAND_U_BOOT_OFFS   0x20
 
+/* MTD device */
+# define CONFIG_MTD_DEVICE
+# define CONFIG_CMD_MTDPARTS
+# define CONFIG_MTD_PARTITIONS
+# define MTDIDS_DEFAULT"nand0=nand"
+
 # define CONFIG_APBH_DMA
 # define CONFIG_APBH_DMA_BURST
 # define CONFIG_APBH_DMA_BURST8
-- 
1.9.1

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


[U-Boot] [PATCH v4 02/16] arm: imx6ul: Add Engicam GEAM6UL Starter Kit initial support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Boot Log:

U-Boot SPL 2016.11-rc2-00144-g922adaa-dirty (Oct 28 2016 - 18:55:30)
Trying to boot from MMC1

U-Boot 2016.11-rc2-00144-g922adaa-dirty (Oct 28 2016 - 18:55:30 +0530)

CPU:   Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 43C
Reset cause: POR
Model: Engicam GEAM6UL
DRAM:  128 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   CPU Net Initialization Failed
No ethernet found.
Hit any key to stop autoboot:  0
geam6ul>

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig|  11 ++
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/imx6ul-geam-kit.dts  | 119 ++
 board/engicam/geam6ul/Kconfig |  12 ++
 board/engicam/geam6ul/MAINTAINERS |   6 +
 board/engicam/geam6ul/Makefile|   6 +
 board/engicam/geam6ul/README  |  28 +
 board/engicam/geam6ul/geam6ul.c   | 246 ++
 configs/imx6ul_geam_mmc_defconfig |  39 ++
 include/configs/imx6ul_geam.h | 125 +++
 10 files changed, 594 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6ul-geam-kit.dts
 create mode 100644 board/engicam/geam6ul/Kconfig
 create mode 100644 board/engicam/geam6ul/MAINTAINERS
 create mode 100644 board/engicam/geam6ul/Makefile
 create mode 100644 board/engicam/geam6ul/README
 create mode 100644 board/engicam/geam6ul/geam6ul.c
 create mode 100644 configs/imx6ul_geam_mmc_defconfig
 create mode 100644 include/configs/imx6ul_geam.h

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index b686476..4ba5338 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -157,6 +157,16 @@ config TARGET_MX6UL_14X14_EVK
select DM_THERMAL
select SUPPORT_SPL
 
+config TARGET_MX6UL_GEAM
+   bool "Support Engicam GEAM6UL"
+   select MX6UL
+   select OF_CONTROL
+   select DM
+   select DM_GPIO
+   select DM_MMC
+   select DM_THERMAL
+   select SUPPORT_SPL
+
 config TARGET_MX6ULL_14X14_EVK
bool "Support mx6ull_14x14_evk"
select MX6ULL
@@ -255,6 +265,7 @@ source "board/compulab/cm_fx6/Kconfig"
 source "board/congatec/cgtqmx6eval/Kconfig"
 source "board/el/el6x/Kconfig"
 source "board/embest/mx6boards/Kconfig"
+source "board/engicam/geam6ul/Kconfig"
 source "board/engicam/icorem6/Kconfig"
 source "board/freescale/mx6qarm2/Kconfig"
 source "board/freescale/mx6qsabreauto/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ae47d81..14eebe7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -291,7 +291,8 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
 
 dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6dl-icore.dtb \
-   imx6q-icore.dtb
+   imx6q-icore.dtb \
+   imx6ul-geam-kit.dtb
 
 dtb-$(CONFIG_MX7) += imx7-colibri.dtb
 
diff --git a/arch/arm/dts/imx6ul-geam-kit.dts b/arch/arm/dts/imx6ul-geam-kit.dts
new file mode 100644
index 000..a039b6d
--- /dev/null
+++ b/arch/arm/dts/imx6ul-geam-kit.dts
@@ -0,0 +1,119 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE 

[U-Boot] [PATCH v4 00/16] imx6: Add Engicam GEAM6UL/i.CoreM6 RQS board support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

This is v4 for previous v3, v2 series[1] [2] on top of [3] series

Changes for v4:
- Add FEC patches.

Changes for v3:
- Add I2C support

Changes for v2:
- Add 'Acked-by' from Joe
- Add new i.CoreM6 RQS patches

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg230990.html
[2] https://www.mail-archive.com/u-boot@lists.denx.de/msg230283.html
[3] [PATCH v3 00/13] imx6: icorem6: Add dm-eth, framebuffer and I2C support

Jagan Teki (16):
  arm: dts: Add devicetree for i.MX6UL
  arm: imx6ul: Add Engicam GEAM6UL Starter Kit initial support
  arm: dts: imx6ul-geam: Add I2C nodes
  imx6: geam6ul: Add I2C support
  imx6: geam6ul: Add NAND support
  imx6: geam6ul: Enable MTD device support
  imx6: geam6ul: Add default mtd nand partition table
  arm: imx6q: Add Engicam i.CoreM6 Quad/Dual RQS Starter Kit initial
support
  arm: imx6q: Add Engicam i.CoreM6 Solo/Duallite RQS Starter Kit initial
support
  imx6: icorem6: Rename engicam icorem6 defconfig files
  arm: dts: imx6qdl-icore-rqs: Add I2C node's
  imx6: icorem6_rqs: Add I2C support
  arm: dts: imx6ul-geam: Add FEC node
  imx6: geam6ul: Add FEC support
  arm: dts: imx6qdl-icore-rqs: Add FEC node
  imx6: icorem6_rqs: Add FEC support

 arch/arm/cpu/armv7/mx6/Kconfig |  26 +
 arch/arm/dts/Makefile  |   5 +-
 arch/arm/dts/imx6dl-icore-rqs.dts  |  50 ++
 arch/arm/dts/imx6q-icore-rqs.dts   |  50 ++
 arch/arm/dts/imx6qdl-icore-rqs.dtsi| 170 
 arch/arm/dts/imx6ul-geam-kit.dts   | 168 
 arch/arm/dts/imx6ul.dtsi   | 942 +
 board/engicam/geam6ul/Kconfig  |  12 +
 board/engicam/geam6ul/MAINTAINERS  |   6 +
 board/engicam/geam6ul/Makefile |   6 +
 board/engicam/geam6ul/README   |  28 +
 board/engicam/geam6ul/geam6ul.c| 317 +++
 board/engicam/icorem6/MAINTAINERS  |   6 +-
 board/engicam/icorem6/README   |  19 +-
 board/engicam/icorem6_rqs/Kconfig  |  12 +
 board/engicam/icorem6_rqs/MAINTAINERS  |   7 +
 board/engicam/icorem6_rqs/Makefile |   6 +
 board/engicam/icorem6_rqs/README   |  33 +
 board/engicam/icorem6_rqs/icorem6_rqs.c| 399 +
 ...re_mmc_defconfig => imx6dl_icore_mmc_defconfig} |   0
 ..._nand_defconfig => imx6dl_icore_nand_defconfig} |   0
 configs/imx6dl_icore_rqs_mmc_defconfig |  43 +
 configs/imx6q_icore_mmc_defconfig  |  46 +
 configs/imx6q_icore_nand_defconfig |  41 +
 configs/imx6q_icore_rqs_mmc_defconfig  |  43 +
 configs/imx6ul_geam_mmc_defconfig  |  44 +
 configs/imx6ul_geam_nand_defconfig |  37 +
 include/configs/imx6qdl_icore_rqs.h| 135 +++
 include/configs/imx6ul_geam.h  | 165 
 include/dt-bindings/clock/imx6ul-clock.h   |   1 +
 30 files changed, 2802 insertions(+), 15 deletions(-)
 create mode 100644 arch/arm/dts/imx6dl-icore-rqs.dts
 create mode 100644 arch/arm/dts/imx6q-icore-rqs.dts
 create mode 100644 arch/arm/dts/imx6qdl-icore-rqs.dtsi
 create mode 100644 arch/arm/dts/imx6ul-geam-kit.dts
 create mode 100644 arch/arm/dts/imx6ul.dtsi
 create mode 100644 board/engicam/geam6ul/Kconfig
 create mode 100644 board/engicam/geam6ul/MAINTAINERS
 create mode 100644 board/engicam/geam6ul/Makefile
 create mode 100644 board/engicam/geam6ul/README
 create mode 100644 board/engicam/geam6ul/geam6ul.c
 create mode 100644 board/engicam/icorem6_rqs/Kconfig
 create mode 100644 board/engicam/icorem6_rqs/MAINTAINERS
 create mode 100644 board/engicam/icorem6_rqs/Makefile
 create mode 100644 board/engicam/icorem6_rqs/README
 create mode 100644 board/engicam/icorem6_rqs/icorem6_rqs.c
 rename configs/{imx6qdl_icore_mmc_defconfig => imx6dl_icore_mmc_defconfig} 
(100%)
 rename configs/{imx6qdl_icore_nand_defconfig => imx6dl_icore_nand_defconfig} 
(100%)
 create mode 100644 configs/imx6dl_icore_rqs_mmc_defconfig
 create mode 100644 configs/imx6q_icore_mmc_defconfig
 create mode 100644 configs/imx6q_icore_nand_defconfig
 create mode 100644 configs/imx6q_icore_rqs_mmc_defconfig
 create mode 100644 configs/imx6ul_geam_mmc_defconfig
 create mode 100644 configs/imx6ul_geam_nand_defconfig
 create mode 100644 include/configs/imx6qdl_icore_rqs.h
 create mode 100644 include/configs/imx6ul_geam.h

-- 
1.9.1

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


[U-Boot] [PATCH v4 15/16] arm: dts: imx6qdl-icore-rqs: Add FEC node

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add FEC node for Engicam i.CoreM6 RQS modules.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6qdl-icore-rqs.dtsi | 46 +
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-icore-rqs.dtsi 
b/arch/arm/dts/imx6qdl-icore-rqs.dtsi
index 2aaa6e4..750229b 100644
--- a/arch/arm/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/dts/imx6qdl-icore-rqs.dtsi
@@ -48,6 +48,31 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet>;
+   phy-handle = <_phy>;
+   phy-mode = "rgmii";
+   status = "okay";
+
+   mdio {
+   eth_phy: ethernet-phy {
+   rxc-skew-ps = <1140>;
+   txc-skew-ps = <1140>;
+   txen-skew-ps = <600>;
+   rxdv-skew-ps = <240>;
+   rxd0-skew-ps = <420>;
+   rxd1-skew-ps = <600>;
+   rxd2-skew-ps = <420>;
+   rxd3-skew-ps = <240>;
+   txd0-skew-ps = <60>;
+   txd1-skew-ps = <60>;
+   txd2-skew-ps = <60>;
+   txd3-skew-ps = <240>;
+   };
+   };
+};
+
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -83,6 +108,27 @@
 };
 
  {
+   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_CLK  0x1b0b0
+   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_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
-- 
1.9.1

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


[U-Boot] [PATCH v4 16/16] imx6: icorem6_rqs: Add FEC support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add FEC support for Engicam i.CoreM6 RQS modules.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig |  1 +
 configs/imx6dl_icore_rqs_mmc_defconfig |  3 +++
 configs/imx6q_icore_rqs_mmc_defconfig  |  3 +++
 include/configs/imx6qdl_icore_rqs.h| 11 +++
 4 files changed, 18 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index d57ce9b..f036717 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -120,6 +120,7 @@ config TARGET_MX6Q_ICORE_RQS
select MX6QDL
select OF_CONTROL
select DM
+   select DM_ETH
select DM_GPIO
select DM_I2C
select DM_MMC
diff --git a/configs/imx6dl_icore_rqs_mmc_defconfig 
b/configs/imx6dl_icore_rqs_mmc_defconfig
index 19a721c..230cd20 100644
--- a/configs/imx6dl_icore_rqs_mmc_defconfig
+++ b/configs/imx6dl_icore_rqs_mmc_defconfig
@@ -18,6 +18,8 @@ CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -27,6 +29,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FEC_MXC=y
 CONFIG_MXC_UART=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
diff --git a/configs/imx6q_icore_rqs_mmc_defconfig 
b/configs/imx6q_icore_rqs_mmc_defconfig
index bbd10af..f7c25c4 100644
--- a/configs/imx6q_icore_rqs_mmc_defconfig
+++ b/configs/imx6q_icore_rqs_mmc_defconfig
@@ -18,6 +18,8 @@ CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -27,6 +29,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FEC_MXC=y
 CONFIG_MXC_UART=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
diff --git a/include/configs/imx6qdl_icore_rqs.h 
b/include/configs/imx6qdl_icore_rqs.h
index 7960355..0121563 100644
--- a/include/configs/imx6qdl_icore_rqs.h
+++ b/include/configs/imx6qdl_icore_rqs.h
@@ -111,6 +111,17 @@
 # define CONFIG_SYS_FSL_ESDHC_ADDR 0
 #endif
 
+/* Ethernet */
+#ifdef CONFIG_FEC_MXC
+# define CONFIG_FEC_MXC_PHYADDR3
+# define CONFIG_FEC_XCV_TYPE   RGMII
+
+# define CONFIG_MII
+# define CONFIG_PHYLIB
+# define CONFIG_PHY_MICREL
+# define CONFIG_PHY_MICREL_KSZ9021
+#endif
+
 /* SPL */
 #ifdef CONFIG_SPL
 # define CONFIG_SPL_MMC_SUPPORT
-- 
1.9.1

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


[U-Boot] [PATCH v4 14/16] imx6: geam6ul: Add FEC support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add FEC support for Engicam GEAM6UL module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig |  1 +
 configs/imx6ul_geam_mmc_defconfig  |  3 +++
 configs/imx6ul_geam_nand_defconfig |  3 +++
 include/configs/imx6ul_geam.h  | 10 ++
 4 files changed, 17 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 50e9b4b..d57ce9b 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -173,6 +173,7 @@ config TARGET_MX6UL_GEAM
select MX6UL
select OF_CONTROL
select DM
+   select DM_ETH
select DM_GPIO
select DM_I2C
select DM_MMC
diff --git a/configs/imx6ul_geam_mmc_defconfig 
b/configs/imx6ul_geam_mmc_defconfig
index e1e1dd2..d5be076 100644
--- a/configs/imx6ul_geam_mmc_defconfig
+++ b/configs/imx6ul_geam_mmc_defconfig
@@ -18,6 +18,8 @@ CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -27,6 +29,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FEC_MXC=y
 CONFIG_MXC_UART=y
 CONFIG_IMX_THERMAL=y
 CONFIG_PINCTRL=y
diff --git a/configs/imx6ul_geam_nand_defconfig 
b/configs/imx6ul_geam_nand_defconfig
index b7a44c7..cc45602 100644
--- a/configs/imx6ul_geam_nand_defconfig
+++ b/configs/imx6ul_geam_nand_defconfig
@@ -18,9 +18,12 @@ CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_NAND=y
 CONFIG_CMD_CACHE=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FEC_MXC=y
 CONFIG_MXC_UART=y
 CONFIG_NAND_MXS=y
 CONFIG_IMX_THERMAL=y
diff --git a/include/configs/imx6ul_geam.h b/include/configs/imx6ul_geam.h
index 7cfdfef..48b1120 100644
--- a/include/configs/imx6ul_geam.h
+++ b/include/configs/imx6ul_geam.h
@@ -137,6 +137,16 @@
 # define CONFIG_APBH_DMA_BURST8
 #endif
 
+/* Ethernet */
+#ifdef CONFIG_FEC_MXC
+# define CONFIG_FEC_MXC_PHYADDR0
+# define CONFIG_FEC_XCV_TYPE   RMII
+
+# define CONFIG_MII
+# define CONFIG_PHYLIB
+# define CONFIG_PHY_SMSC
+#endif
+
 /* SPL */
 #ifdef CONFIG_SPL
 # ifdef CONFIG_NAND_MXS
-- 
1.9.1

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


[U-Boot] [PATCH v4 13/16] arm: dts: imx6ul-geam: Add FEC node

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add FEC node for Engicam GEAM6UL module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6ul-geam-kit.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/dts/imx6ul-geam-kit.dts b/arch/arm/dts/imx6ul-geam-kit.dts
index 3672b02..07c21cb 100644
--- a/arch/arm/dts/imx6ul-geam-kit.dts
+++ b/arch/arm/dts/imx6ul-geam-kit.dts
@@ -59,6 +59,13 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet1>;
+   phy-mode = "rmii";
+   status = "okay";
+};
+
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -91,6 +98,20 @@
 };
 
  {
+   pinctrl_enet1: enet1grp {
+   fsl,pins = <
+   MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0
+   MX6UL_PAD_GPIO1_IO06__ENET2_MDIO0x1b0b0
+   MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN  0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+   MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN  0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+   MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1  0x4001b031
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
-- 
1.9.1

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


[U-Boot] [PATCH v4 10/16] imx6: icorem6: Rename engicam icorem6 defconfig files

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Rename defconfig files for better compatible with
respective board names and dts files.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 board/engicam/icorem6/MAINTAINERS  |  6 ++-
 board/engicam/icorem6/README   | 19 -
 ...re_mmc_defconfig => imx6dl_icore_mmc_defconfig} |  0
 ..._nand_defconfig => imx6dl_icore_nand_defconfig} |  0
 configs/imx6q_icore_mmc_defconfig  | 46 ++
 configs/imx6q_icore_nand_defconfig | 41 +++
 6 files changed, 98 insertions(+), 14 deletions(-)
 rename configs/{imx6qdl_icore_mmc_defconfig => imx6dl_icore_mmc_defconfig} 
(100%)
 rename configs/{imx6qdl_icore_nand_defconfig => imx6dl_icore_nand_defconfig} 
(100%)
 create mode 100644 configs/imx6q_icore_mmc_defconfig
 create mode 100644 configs/imx6q_icore_nand_defconfig

diff --git a/board/engicam/icorem6/MAINTAINERS 
b/board/engicam/icorem6/MAINTAINERS
index a425afb..0ef3a2c 100644
--- a/board/engicam/icorem6/MAINTAINERS
+++ b/board/engicam/icorem6/MAINTAINERS
@@ -3,5 +3,7 @@ M:  Jagan Teki 
 S: Maintained
 F: board/engicam/icorem6
 F: include/configs/imx6qdl_icore.h
-F: configs/imx6qdl_icore_mmc_defconfig
-F: configs/imx6qdl_icore_nand_defconfig
+F: configs/imx6q_icore_mmc_defconfig
+F: configs/imx6q_icore_nand_defconfig
+F: configs/imx6dl_icore_mmc_defconfig
+F: configs/imx6dl_icore_nand_defconfig
diff --git a/board/engicam/icorem6/README b/board/engicam/icorem6/README
index e47f85f..6461c0a 100644
--- a/board/engicam/icorem6/README
+++ b/board/engicam/icorem6/README
@@ -1,18 +1,16 @@
-How to use U-Boot on Engicam i.CoreM6 DualLite/Solo and Quad/Dual Starter Kit:
+How to use U-Boot on Engicam i.CoreM6 Solo/DualLite and Quad/Dual Starter Kit:
 -
 
-- Configure U-Boot for Engicam i.CoreM6 QDL:
-
 $ make mrproper
-$ make imx6qdl_icore_mmc_defconfig
-
-- Build for i.CoreM6 DualLite/Solo
 
-$ make
+- Configure U-Boot for Engicam i.CoreM6 Quad/Dual:
+$ make imx6q_icore_mmc_defconfig
 
-- Build for i.CoreM6 Quad/Dual
+- Configure U-Boot for Engicam i.CoreM6 Solo/DualLite:
+$ make imx6dl_icore_mmc_defconfig
 
-$ make DEVICE_TREE=imx6q-icore
+- Build U-Boot
+$ make
 
 This will generate the SPL image called SPL and the u-boot-dtb.img.
 
@@ -33,6 +31,3 @@ MMC Boot: JM3 Closed
 
 - Insert the micro SD card in the board, power it up and U-Boot messages should
 come up.
-
-- Note: For loading Linux on Quad/Dual modules set the dtb as
-  icorem6qdl> setenv fdt_file imx6q-icore.dtb
diff --git a/configs/imx6qdl_icore_mmc_defconfig 
b/configs/imx6dl_icore_mmc_defconfig
similarity index 100%
rename from configs/imx6qdl_icore_mmc_defconfig
rename to configs/imx6dl_icore_mmc_defconfig
diff --git a/configs/imx6qdl_icore_nand_defconfig 
b/configs/imx6dl_icore_nand_defconfig
similarity index 100%
rename from configs/imx6qdl_icore_nand_defconfig
rename to configs/imx6dl_icore_nand_defconfig
diff --git a/configs/imx6q_icore_mmc_defconfig 
b/configs/imx6q_icore_mmc_defconfig
new file mode 100644
index 000..adbd4e7
--- /dev/null
+++ b/configs/imx6q_icore_mmc_defconfig
@@ -0,0 +1,46 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_TARGET_MX6Q_ICORE=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,ENV_IS_IN_MMC"
+CONFIG_DEFAULT_FDT_FILE="imx6q-icore.dtb"
+CONFIG_DEFAULT_DEVICE_TREE="imx6q-icore"
+CONFIG_SYS_PROMPT="icorem6qdl> "
+CONFIG_SPL=y
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_HUSH_PARSER=y
+CONFIG_AUTO_COMPLETE=y
+CONFIG_SYS_MAXARGS=32
+# CONFIG_CMD_IMLS is not set
+# CONFIG_BLK is not set
+# CONFIG_DM_MMC_OPS is not set
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MMC=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_OF_LIBFDT=y
+CONFIG_FEC_MXC=y
+CONFIG_MXC_UART=y
+CONFIG_IMX_THERMAL=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX6=y
+CONFIG_SYS_I2C_MXC=y
+CONFIG_VIDEO=y
+CONFIG_SYS_CONSOLE_IS_IN_ENV=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SPL_EXT_SUPPORT=y
diff --git a/configs/imx6q_icore_nand_defconfig 
b/configs/imx6q_icore_nand_defconfig
new file mode 100644
index 000..03f5c62
--- /dev/null
+++ b/configs/imx6q_icore_nand_defconfig
@@ -0,0 +1,41 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_TARGET_MX6Q_ICORE=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,ENV_IS_IN_NAND"
+CONFIG_DEFAULT_FDT_FILE="imx6q-icore.dtb"

[U-Boot] [PATCH v4 12/16] imx6: icorem6_rqs: Add I2C support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add I2C support for Engicam i.CoreM6 RQS modules.

icorem6qdl-rqs> i2c bus
Bus 0:  i2c@021a
Bus 1:  i2c@021a4000
Bus 2:  i2c@021a8000
icorem6qdl-rqs> i2c dev 0
Setting bus to 0
icorem6qdl-rqs> i2c speed 10
Setting bus speed to 10 Hz
icorem6qdl-rqs> i2c probe
Valid chip addresses: 4F
icorem6qdl-rqs> i2c md 4F 0xff
00ff: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
icorem6qdl-rqs> i2c bus
Bus 0:  i2c@021a  (active 0)
   4f: generic_4f, offset len 1, flags 0
Bus 1:  i2c@021a4000
Bus 2:  i2c@021a8000

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig | 1 +
 configs/imx6dl_icore_rqs_mmc_defconfig | 2 ++
 configs/imx6q_icore_rqs_mmc_defconfig  | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index a9403bf..50e9b4b 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -121,6 +121,7 @@ config TARGET_MX6Q_ICORE_RQS
select OF_CONTROL
select DM
select DM_GPIO
+   select DM_I2C
select DM_MMC
select DM_THERMAL
select SUPPORT_SPL
diff --git a/configs/imx6dl_icore_rqs_mmc_defconfig 
b/configs/imx6dl_icore_rqs_mmc_defconfig
index 7fc7fa0..19a721c 100644
--- a/configs/imx6dl_icore_rqs_mmc_defconfig
+++ b/configs/imx6dl_icore_rqs_mmc_defconfig
@@ -25,10 +25,12 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
 CONFIG_MXC_UART=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
+CONFIG_SYS_I2C_MXC=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
diff --git a/configs/imx6q_icore_rqs_mmc_defconfig 
b/configs/imx6q_icore_rqs_mmc_defconfig
index eeecef8..bbd10af 100644
--- a/configs/imx6q_icore_rqs_mmc_defconfig
+++ b/configs/imx6q_icore_rqs_mmc_defconfig
@@ -25,10 +25,12 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
 CONFIG_MXC_UART=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
+CONFIG_SYS_I2C_MXC=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-- 
1.9.1

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


[U-Boot] [PATCH v4 11/16] arm: dts: imx6qdl-icore-rqs: Add I2C node's

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add I2C nodes for Engicam i.CoreM6 RQS modules.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6qdl-icore-rqs.dtsi | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-icore-rqs.dtsi 
b/arch/arm/dts/imx6qdl-icore-rqs.dtsi
index 343ab35..2aaa6e4 100644
--- a/arch/arm/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/dts/imx6qdl-icore-rqs.dtsi
@@ -48,6 +48,26 @@
};
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1>;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_uart4>;
@@ -63,6 +83,27 @@
 };
 
  {
+   pinctrl_i2c1: i2c1grp {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+   MX6QDL_PAD_EIM_D28__I2C1_SDA 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_5__I2C3_SCL  0x4001b8b1
+   MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+   >;
+   };
+
pinctrl_uart4: uart4grp {
fsl,pins = <
MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
-- 
1.9.1

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


[U-Boot] [PATCH v4 05/16] imx6: geam6ul: Add NAND support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add NAND support for Engicam GEAM6UL board.

Boot Log:

U-Boot SPL 2016.11-g537fa5f (Nov 28 2016 - 11:42:28)
Trying to boot from NAND
NAND : 256 MiB

U-Boot 2016.11-g537fa5f (Nov 28 2016 - 11:20:06 +0100)

CPU:   Freescale i.MX6UL rev1.1 69 MHz (running at 396 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 42C
Reset cause: WDOG
Model: Engicam GEAM6UL
DRAM:  128 MiB
NAND:  256 MiB
MMC:   FSL_SDHC: 0
* Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 board/engicam/geam6ul/geam6ul.c| 71 ++
 configs/imx6ul_geam_nand_defconfig | 34 ++
 include/configs/imx6ul_geam.h  | 24 -
 3 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 configs/imx6ul_geam_nand_defconfig

diff --git a/board/engicam/geam6ul/geam6ul.c b/board/engicam/geam6ul/geam6ul.c
index 8530845..40f20a9 100644
--- a/board/engicam/geam6ul/geam6ul.c
+++ b/board/engicam/geam6ul/geam6ul.c
@@ -13,6 +13,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,11 +37,81 @@ int board_early_init_f(void)
return 0;
 }
 
+#ifdef CONFIG_NAND_MXS
+
+#define GPMI_PAD_CTRL0 (PAD_CTL_PKE | PAD_CTL_PUE | 
PAD_CTL_PUS_100K_UP)
+#define GPMI_PAD_CTRL1 (PAD_CTL_DSE_40ohm | PAD_CTL_SPEED_MED | \
+   PAD_CTL_SRE_FAST)
+#define GPMI_PAD_CTRL2 (GPMI_PAD_CTRL0 | GPMI_PAD_CTRL1)
+
+static iomux_v3_cfg_t const nand_pads[] = {
+   MX6_PAD_NAND_DATA00__RAWNAND_DATA00 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA01__RAWNAND_DATA01 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA02__RAWNAND_DATA02 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA03__RAWNAND_DATA03 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA04__RAWNAND_DATA04 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA05__RAWNAND_DATA05 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA06__RAWNAND_DATA06 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA07__RAWNAND_DATA07 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_CLE__RAWNAND_CLE | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_ALE__RAWNAND_ALE | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_CE0_B__RAWNAND_CE0_B | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_RE_B__RAWNAND_RE_B | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_WE_B__RAWNAND_WE_B | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_WP_B__RAWNAND_WP_B | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_READY_B__RAWNAND_READY_B | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+};
+
+static void setup_gpmi_nand(void)
+{
+   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+   /* config gpmi nand iomux */
+   imx_iomux_v3_setup_multiple_pads(nand_pads, ARRAY_SIZE(nand_pads));
+
+   clrbits_le32(_ccm->CCGR4,
+MXC_CCM_CCGR4_RAWNAND_U_BCH_INPUT_APB_MASK |
+MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_BCH_MASK |
+MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_MASK |
+MXC_CCM_CCGR4_RAWNAND_U_GPMI_INPUT_APB_MASK |
+MXC_CCM_CCGR4_PL301_MX6QPER1_BCH_MASK);
+
+   /*
+* config gpmi and bch clock to 100 MHz
+* bch/gpmi select PLL2 PFD2 400M
+* 100M = 400M / 4
+*/
+   clrbits_le32(_ccm->cscmr1,
+MXC_CCM_CSCMR1_BCH_CLK_SEL |
+MXC_CCM_CSCMR1_GPMI_CLK_SEL);
+   clrsetbits_le32(_ccm->cscdr1,
+   MXC_CCM_CSCDR1_BCH_PODF_MASK |
+   MXC_CCM_CSCDR1_GPMI_PODF_MASK,
+   (3 << MXC_CCM_CSCDR1_BCH_PODF_OFFSET) |
+   (3 << MXC_CCM_CSCDR1_GPMI_PODF_OFFSET));
+
+   /* enable gpmi and bch clock gating */
+   setbits_le32(_ccm->CCGR4,
+MXC_CCM_CCGR4_RAWNAND_U_BCH_INPUT_APB_MASK |
+MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_BCH_MASK |
+MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_MASK |
+MXC_CCM_CCGR4_RAWNAND_U_GPMI_INPUT_APB_MASK |
+MXC_CCM_CCGR4_PL301_MX6QPER1_BCH_MASK);
+
+   /* enable apbh clock gating */
+   setbits_le32(_ccm->CCGR0, MXC_CCM_CCGR0_APBHDMA_MASK);
+}
+#endif /* CONFIG_NAND_MXS */
+
 int board_init(void)
 {
/* Address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
 
+#ifdef CONFIG_NAND_MXS
+   setup_gpmi_nand();
+#endif
+
return 0;
 }
 
diff --git a/configs/imx6ul_geam_nand_defconfig 
b/configs/imx6ul_geam_nand_defconfig
new file mode 100644
index 000..b7a44c7
--- /dev/null
+++ 

[U-Boot] [PATCH v4 08/16] arm: imx6q: Add Engicam i.CoreM6 Quad/Dual RQS Starter Kit initial support

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Boot from MMC:
-
U-Boot SPL 2016.11-rc2-g217bd8e-dirty (Nov 08 2016 - 22:59:44)
Trying to boot from MMC1

U-Boot 2016.11-rc2-g217bd8e-dirty (Nov 08 2016 - 22:59:44 +0530)

CPU:   Freescale i.MX6D rev1.2 at 792 MHz
Reset cause: POR
Model: Engicam i.CoreM6 Quad/Dual RQS Starter Kit
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   CPU Net Initialization Failed
No ethernet found.
Hit any key to stop autoboot:  0
icorem6qdl-rqs>

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig  |  11 +
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/imx6q-icore-rqs.dts|  50 
 arch/arm/dts/imx6qdl-icore-rqs.dtsi |  83 +++
 board/engicam/icorem6_rqs/Kconfig   |  12 +
 board/engicam/icorem6_rqs/MAINTAINERS   |   6 +
 board/engicam/icorem6_rqs/Makefile  |   6 +
 board/engicam/icorem6_rqs/README|  30 +++
 board/engicam/icorem6_rqs/icorem6_rqs.c | 399 
 configs/imx6q_icore_rqs_mmc_defconfig   |  38 +++
 include/configs/imx6qdl_icore_rqs.h | 124 ++
 11 files changed, 760 insertions(+)
 create mode 100644 arch/arm/dts/imx6q-icore-rqs.dts
 create mode 100644 arch/arm/dts/imx6qdl-icore-rqs.dtsi
 create mode 100644 board/engicam/icorem6_rqs/Kconfig
 create mode 100644 board/engicam/icorem6_rqs/MAINTAINERS
 create mode 100644 board/engicam/icorem6_rqs/Makefile
 create mode 100644 board/engicam/icorem6_rqs/README
 create mode 100644 board/engicam/icorem6_rqs/icorem6_rqs.c
 create mode 100644 configs/imx6q_icore_rqs_mmc_defconfig
 create mode 100644 include/configs/imx6qdl_icore_rqs.h

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index bbdb5a1..a9403bf 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -115,6 +115,16 @@ config TARGET_MX6Q_ICORE
select DM_THERMAL
select SUPPORT_SPL
 
+config TARGET_MX6Q_ICORE_RQS
+   bool "Support Engicam i.Core RQS"
+   select MX6QDL
+   select OF_CONTROL
+   select DM
+   select DM_GPIO
+   select DM_MMC
+   select DM_THERMAL
+   select SUPPORT_SPL
+
 config TARGET_MX6QSABREAUTO
bool "mx6qsabreauto"
select DM
@@ -268,6 +278,7 @@ source "board/el/el6x/Kconfig"
 source "board/embest/mx6boards/Kconfig"
 source "board/engicam/geam6ul/Kconfig"
 source "board/engicam/icorem6/Kconfig"
+source "board/engicam/icorem6_rqs/Kconfig"
 source "board/freescale/mx6qarm2/Kconfig"
 source "board/freescale/mx6qsabreauto/Kconfig"
 source "board/freescale/mx6sabresd/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 14eebe7..96e98c6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -292,6 +292,7 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
 dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6dl-icore.dtb \
imx6q-icore.dtb \
+   imx6q-icore-rqs.dtb \
imx6ul-geam-kit.dtb
 
 dtb-$(CONFIG_MX7) += imx7-colibri.dtb
diff --git a/arch/arm/dts/imx6q-icore-rqs.dts b/arch/arm/dts/imx6q-icore-rqs.dts
new file mode 100644
index 000..9fa6ba0
--- /dev/null
+++ b/arch/arm/dts/imx6q-icore-rqs.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2015 Amarula Solutions B.V.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES

[U-Boot] [PATCH v4 03/16] arm: dts: imx6ul-geam: Add I2C nodes

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add I2C nodes for Engicam GEAM6UL module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6ul-geam-kit.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/dts/imx6ul-geam-kit.dts b/arch/arm/dts/imx6ul-geam-kit.dts
index a039b6d..3672b02 100644
--- a/arch/arm/dts/imx6ul-geam-kit.dts
+++ b/arch/arm/dts/imx6ul-geam-kit.dts
@@ -59,6 +59,20 @@
};
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1>;
+   status = "okay";
+};
+
+ {
+   clock_frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
@@ -77,6 +91,20 @@
 };
 
  {
+   pinctrl_i2c1: i2c1grp {
+   fsl,pins = <
+   MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+   MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+   >;
+   };
+
+   pinctrl_i2c2: i2c2grp {
+   fsl,pins = <
+   MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+   MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+   >;
+   };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
-- 
1.9.1

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


[U-Boot] [PATCH v4 01/16] arm: dts: Add devicetree for i.MX6UL

2016-12-13 Thread Jagan Teki
From: Jagan Teki 

Add i.MX6UL dtsi support from Linux.

Here is the last commit:
"ARM: dts: add gpio-ranges property to iMX GPIO controllers"
(sha1: bb728d662bed0fe91b152550e640cb3f6caa972c)

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6ul.dtsi | 942 +++
 include/dt-bindings/clock/imx6ul-clock.h |   1 +
 2 files changed, 943 insertions(+)
 create mode 100644 arch/arm/dts/imx6ul.dtsi

diff --git a/arch/arm/dts/imx6ul.dtsi b/arch/arm/dts/imx6ul.dtsi
new file mode 100644
index 000..c5c05fd
--- /dev/null
+++ b/arch/arm/dts/imx6ul.dtsi
@@ -0,0 +1,942 @@
+/*
+ * Copyright 2015 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "imx6ul-pinfunc.h"
+#include "skeleton.dtsi"
+
+/ {
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   gpio3 = 
+   gpio4 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   mmc0 = 
+   mmc1 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   serial5 = 
+   serial6 = 
+   serial7 = 
+   sai1 = 
+   sai2 = 
+   sai3 = 
+   spi0 = 
+   spi1 = 
+   spi2 = 
+   spi3 = 
+   usbphy0 = 
+   usbphy1 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0>;
+   clock-latency = <61036>; /* two CLK32 periods */
+   operating-points = <
+   /* kHz  uV */
+   528000  1175000
+   396000  1025000
+   198000  95
+   >;
+   fsl,soc-operating-points = <
+   /* KHz  uV */
+   528000  1175000
+   396000  1175000
+   198000  1175000
+   >;
+   clocks = < IMX6UL_CLK_ARM>,
+< IMX6UL_CLK_PLL2_BUS>,
+< IMX6UL_CLK_PLL2_PFD2>,
+< IMX6UL_CA7_SECONDARY_SEL>,
+< IMX6UL_CLK_STEP>,
+< IMX6UL_CLK_PLL1_SW>,
+< IMX6UL_CLK_PLL1_SYS>,
+< IMX6UL_PLL1_BYPASS>,
+< IMX6UL_CLK_PLL1>,
+< IMX6UL_PLL1_BYPASS_SRC>,
+< IMX6UL_CLK_OSC>;
+   clock-names = "arm", "pll2_bus",  "pll2_pfd2_396m",
+ "secondary_sel", "step", "pll1_sw",
+ "pll1_sys", "pll1_bypass", "pll1",
+ "pll1_bypass_src", "osc";
+   arm-supply = <_arm>;
+   soc-supply = <_soc>;
+   };
+   };
+
+   intc: interrupt-controller@00a01000 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x00a01000 0x1000>,
+ <0x00a02000 0x1000>,
+ <0x00a04000 0x2000>,
+ <0x00a06000 0x2000>;
+   };
+
+   ckil: clock-cli {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "ckil";
+   };
+
+   osc: clock-osc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   clock-output-names = "osc";
+   };
+
+   ipp_di0: clock-di0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "ipp_di0";
+   };
+
+   ipp_di1: clock-di1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names 

Re: [U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

2016-12-13 Thread Chen-Yu Tsai
On Tue, Dec 13, 2016 at 11:40 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Tue, Dec 13, 2016 at 01:36:29AM +0100, Jernej Skrabec wrote:
>> This patch adds support for hdmi output. It is designed in the same
>> way as video driver for older Allwinner SoCs.
>>
>> First it checks if monitor is attached. If it is, recommended
>> timings are read from EDID. After that, DE2, TCON and HDMI are
>> configured according to this timings.
>>
>> 32MB of RAM is used for framebuffer. This is just enough to support
>> 4K resolution.
>>
>> SimpleFB is also supported by this driver.
>>
>> Signed-off-by: Jernej Skrabec 
>
> From the linux discussion, I recall that you said that the TCON was
> still the same, and the HDMI was something that could be shared with
> the Rockchip implementation. Did you look into sharing the TCON code
> (for example using a small "library" to share the functions) and to
> reuse Rockchip's HDMI code?

I second the first proposal. The TCON structure has not changed since
the A10. Allwinner just removed the unused channels. Channel 1 is
removed from the first TCON, and channel 0 is removed from the second
TCON. So Allwinner is more or less committing to a static mapping for
the display pipeline outputs.

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


Re: [U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

2016-12-13 Thread Maxime Ripard
Hi,

On Tue, Dec 13, 2016 at 01:36:29AM +0100, Jernej Skrabec wrote:
> This patch adds support for hdmi output. It is designed in the same
> way as video driver for older Allwinner SoCs.
> 
> First it checks if monitor is attached. If it is, recommended
> timings are read from EDID. After that, DE2, TCON and HDMI are
> configured according to this timings.
> 
> 32MB of RAM is used for framebuffer. This is just enough to support
> 4K resolution.
> 
> SimpleFB is also supported by this driver.
> 
> Signed-off-by: Jernej Skrabec 

From the linux discussion, I recall that you said that the TCON was
still the same, and the HDMI was something that could be shared with
the Rockchip implementation. Did you look into sharing the TCON code
(for example using a small "library" to share the functions) and to
reuse Rockchip's HDMI code?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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


Re: [U-Boot] [RFC PATCH 0/3] spl: Add D-cache support

2016-12-13 Thread Tom Rini
On Tue, Dec 13, 2016 at 08:48:55PM +0530, Lokesh Vutla wrote:
> 
> 
> On Tuesday 13 December 2016 05:44 PM, Tom Rini wrote:
> > On Mon, Dec 12, 2016 at 03:22:50PM +0530, Lokesh Vutla wrote:
> >> Hi Tom,
> >>
> >> On Monday 28 November 2016 03:04 PM, Lokesh Vutla wrote:
> >>> This series tries to add D-cache support in spl in order to reduce boot 
> >>> time
> >>> either in 2stage boot or Falcon Boot.
> >>
> >> I hope there are no further comments on this series. Do you want me to
> >> re post this series or this is good to go?
> > 
> > This breaks building on a few platforms:
> 
> I am kind of expecting for that :)
> 
> > https://travis-ci.org/trini/u-boot/jobs/183441104
> > https://travis-ci.org/trini/u-boot/jobs/183441159
> 
> These errors are mostly saying that SPL image is too big.

Right.  But they need to build still.

> > https://travis-ci.org/trini/u-boot/jobs/183441171
> 
> Looks like I did not care about armv8 platforms. Ill take a look at this.
> 
> > 
> > And break booting on omap4_panda:
> > 20:02:33 U-Boot SPL 2017.01-rc1-00068-g8ae0906 (Dec 12 2016 - 19:11:20)
> > 20:02:33 OMAP4460-GP ES1.1
> > 20:02:33 Trying to boot from MMC1SPL: Please implement spl_start_uboot() 
> > for your board
> > 20:02:33 SPL: Direct Linux boot not active!
> > 20:02:33 reading u-boot.img
> > 20:02:33 reading u-boot.img
> > [ hangs here ]
> 
> hmm...ill dig more into this.

Thanks!

-- 
Tom


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


Re: [U-Boot] [RFC PATCH 0/3] spl: Add D-cache support

2016-12-13 Thread Lokesh Vutla


On Tuesday 13 December 2016 05:44 PM, Tom Rini wrote:
> On Mon, Dec 12, 2016 at 03:22:50PM +0530, Lokesh Vutla wrote:
>> Hi Tom,
>>
>> On Monday 28 November 2016 03:04 PM, Lokesh Vutla wrote:
>>> This series tries to add D-cache support in spl in order to reduce boot time
>>> either in 2stage boot or Falcon Boot.
>>
>> I hope there are no further comments on this series. Do you want me to
>> re post this series or this is good to go?
> 
> This breaks building on a few platforms:

I am kind of expecting for that :)

> https://travis-ci.org/trini/u-boot/jobs/183441104
> https://travis-ci.org/trini/u-boot/jobs/183441159

These errors are mostly saying that SPL image is too big.

> https://travis-ci.org/trini/u-boot/jobs/183441171

Looks like I did not care about armv8 platforms. Ill take a look at this.

> 
> And break booting on omap4_panda:
> 20:02:33 U-Boot SPL 2017.01-rc1-00068-g8ae0906 (Dec 12 2016 - 19:11:20)
> 20:02:33 OMAP4460-GP ES1.1
> 20:02:33 Trying to boot from MMC1SPL: Please implement spl_start_uboot() for 
> your board
> 20:02:33 SPL: Direct Linux boot not active!
> 20:02:33 reading u-boot.img
> 20:02:33 reading u-boot.img
> [ hangs here ]

hmm...ill dig more into this.

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


Re: [U-Boot] [RFC PATCH 1/3] sunxi: Add clocks for DE2/HDMI/TCON

2016-12-13 Thread Maxime Ripard
Hi,

First off, thanks a lot for working on this.

On Tue, Dec 13, 2016 at 01:36:28AM +0100, Jernej Skrabec wrote:
> This is needed for HDMI support, which will be added later.
> 
> Signed-off-by: Jernej Skrabec 
> ---
> 
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 43 
> +++
>  arch/arm/mach-sunxi/clock_sun6i.c | 28 +
>  2 files changed, 71 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index be9fcfd..c19c200 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -67,12 +67,20 @@ struct sunxi_ccm_reg {
>   u32 dram_pll_cfg;   /* 0xf8 PLL_DDR cfg register, A33 only */
>   u32 mbus_reset; /* 0xfc MBUS reset control, A33 only */
>   u32 dram_clk_gate;  /* 0x100 DRAM module gating */
> +#ifdef CONFIG_MACH_SUN8I_H3
> + u32 de_clk_cfg; /* 0x104 DE module clock */
> +#else
>   u32 be0_clk_cfg;/* 0x104 BE0 module clock */
> +#endif
>   u32 be1_clk_cfg;/* 0x108 BE1 module clock */
>   u32 fe0_clk_cfg;/* 0x10c FE0 module clock */
>   u32 fe1_clk_cfg;/* 0x110 FE1 module clock */
>   u32 mp_clk_cfg; /* 0x114 MP module clock */
> +#ifdef CONFIG_MACH_SUN8I_H3
> + u32 tcon0_clk_cfg;  /* 0x118 TCON0 module clock */
> +#else
>   u32 lcd0_ch0_clk_cfg;   /* 0x118 LCD0 CH0 module clock */
> +#endif
>   u32 lcd1_ch0_clk_cfg;   /* 0x11c LCD1 CH0 module clock */
>   u32 reserved14[3];
>   u32 lcd0_ch1_clk_cfg;   /* 0x12c LCD0 CH1 module clock */
> @@ -85,7 +93,11 @@ struct sunxi_ccm_reg {
>   u32 dmic_clk_cfg;   /* 0x148 Digital Mic module clock*/
>   u32 reserved15;
>   u32 hdmi_clk_cfg;   /* 0x150 HDMI module clock */
> +#ifdef CONFIG_MACH_SUN8I_H3
> + u32 hdmi_slow_clk_cfg;  /* 0x154 HDMI slow module clock */
> +#else
>   u32 ps_clk_cfg; /* 0x154 PS module clock */
> +#endif
>   u32 mtc_clk_cfg;/* 0x158 MTC module clock */
>   u32 mbus0_clk_cfg;  /* 0x15c MBUS0 module clock */
>   u32 mbus1_clk_cfg;  /* 0x160 MBUS1 module clock */
> @@ -220,6 +232,15 @@ struct sunxi_ccm_reg {
>  #define CCM_MIPI_PLL_CTRL_LDO_EN (0x3 << 22)
>  #define CCM_MIPI_PLL_CTRL_EN (0x1 << 31)
>  
> +#define CCM_PLL10_CTRL_M_SHIFT   0
> +#define CCM_PLL10_CTRL_M_MASK(0xf << CCM_PLL10_CTRL_M_SHIFT)
> +#define CCM_PLL10_CTRL_M(n)  n) - 1) & 0xf) << 0)
> +#define CCM_PLL10_CTRL_N_SHIFT   8
> +#define CCM_PLL10_CTRL_N_MASK(0x7f << CCM_PLL10_CTRL_N_SHIFT)
> +#define CCM_PLL10_CTRL_N(n)  n) - 1) & 0x7f) << 8)
> +#define CCM_PLL10_CTRL_INTEGER_MODE  (0x1 << 24)
> +#define CCM_PLL10_CTRL_EN(0x1 << 31)
> +
>  #define CCM_PLL11_CTRL_N(n)  n) - 1) & 0x3f) << 8)
>  #define CCM_PLL11_CTRL_SIGMA_DELTA_EN(0x1 << 24)
>  #define CCM_PLL11_CTRL_UPD   (0x1 << 30)
> @@ -271,9 +292,12 @@ struct sunxi_ccm_reg {
>  #define AHB_GATE_OFFSET_DRC0 25
>  #define AHB_GATE_OFFSET_DE_FE0   14
>  #define AHB_GATE_OFFSET_DE_BE0   12
> +#define AHB_GATE_OFFSET_DE   12
>  #define AHB_GATE_OFFSET_HDMI 11
>  #define AHB_GATE_OFFSET_LCD1 5
>  #define AHB_GATE_OFFSET_LCD0 4
> +#define AHB_GATE_OFFSET_TCON14
> +#define AHB_GATE_OFFSET_TCON03

Maybe having some ifdef here would help, only to differentiate between
the DE1 and DE2 cases that would require different defines here.

Note that it also applies to the rest of that patch.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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


Re: [U-Boot] [PATCH v2] ARM: dt: zynq: Add labels to cpu nodes to allow overriding OPPs.

2016-12-13 Thread Michal Simek
On 12.12.2016 17:48, Moritz Fischer wrote:
> By adding labels to the cpu nodes in the dtsi, a dts that
> includes it can change the OPPs by referencing the cpu0
> through the label.
> 
> [Based on linux (400b6a0cbef55d1ae32808eaa1ef1c28820bf6ac)]
> Signed-off-by: Moritz Fischer 
> Cc: Michal Simek 
> Cc: u-boot@lists.denx.de
> ---
> 
> Ok, since I fatfingered v1 ... this one with right subject
> prefix, and only one patch in 'series'.
> 
> Changes from v1: None
> 
> Sorry 'bout the noise,
> 
> Moritz
> 
> ---
>  arch/arm/dts/zynq-7000.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
> index 6df0329..668f54e 100644
> --- a/arch/arm/dts/zynq-7000.dtsi
> +++ b/arch/arm/dts/zynq-7000.dtsi
> @@ -16,7 +16,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
> - cpu@0 {
> + cpu0: cpu@0 {
>   compatible = "arm,cortex-a9";
>   device_type = "cpu";
>   reg = <0>;
> @@ -30,7 +30,7 @@
>   >;
>   };
>  
> - cpu@1 {
> + cpu1: cpu@1 {
>   compatible = "arm,cortex-a9";
>   device_type = "cpu";
>   reg = <1>;
> 

Applied.

Thanks,
Michal


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


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

2016-12-13 Thread Måns Rullgård
Joel Stanley  writes:

> Hello Tom,
>
> On Sat, Dec 10, 2016 at 12:53 AM, Tom Rini  wrote:
>>> -LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>>> +# Avoid Not enough room for program headers on binutils 2.28 onwards.
>>> +# Flag was introduced in 2.26
>>> +LDFLAGS_u-boot += $(LDFLAGS_FINAL) \
>>> + $(call ld-ifversion, -ge, 2260, --no-dynamic-linker)
>>
>> This breaks on things like:
>> $ arm-none-eabi-ld --version
>> GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150921
>
> The flag will only be added when the version is >= 2.26. Which part of
> that version string will break the test?
>
>> so please use ld-option instead to add this when supported, thanks!
>
> If you'd just prefer ld-option over ld-ifversion then I can send a
> different patch.

Always test for the actual thing you need whenever possible.  Version
checks are fragile and should be a last resort.  Consider what would
happen if someone backported that functionality to an older binutils
version.  Going by version number alone, the flag would not be used and
the build would fail.

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 00/13] imx6: icorem6: Add dm-eth, framebuffer and I2C support

2016-12-13 Thread Jagan Teki
On Wed, Dec 7, 2016 at 5:01 PM, Jagan Teki  wrote:
> Hi Stefano,
>
> On Tue, Dec 6, 2016 at 12:00 AM, Jagan Teki  wrote:
>> From: Jagan Teki 
>>
>> This series support framebuffer and I2C on top of u-boot-imx.git with
>> latest u-boot.git merge.
>>
>> fec_mxc dm driver on previous version series trigger an issues with
>> when DM_ETH not-defined so, this series have fixes for non-dm builds
>> as well.
>>
>> Changes for v3:
>> - Fix fec_mxc driver to build for non-dm configs as well.
>> - Fix VIDEO_IPV3 Kconfig entry not to make default.
>>
>> Changes for v2:
>> - Rebase on u-boot-imx.git and u-boot.git
>>
>> Jagan Teki (13):
>>   net: fec_mxc: Remove unneeded eth_device arg from fec_get_hwaddr
>>   net: fec_mxc: Convert into driver model
>>   net: fec_mxc: Driver cleanups
>>   dm: net: fec: Add .read_rom_hwaddr
>>   ARM: dts: imx6qdl-icore: Add FEC support
>>   icorem6: Use CONFIG_DM_ETH support
>>   video: Kconfig: Add VIDEO_IPV3 entry
>>   imx6: icorem6: Add framebuffer support
>>   imx6: icorem6: Add custom splashscreen support
>>   i2c: Kconfig: Add SYS_I2C_MXC entry
>>   i2c: mxc: Print hex instead of decimal for bus address
>>   i2c: mxc: Make 'no gpio pinctrl state' print as debug
>>   imx6: icorem6: Add I2C support
>
> Can you apply these, if it's OK?

Any help?



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


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

2016-12-13 Thread Tom Rini
On Tue, Dec 13, 2016 at 03:31:24PM +1030, Joel Stanley wrote:
> Hello Tom,
> 
> On Sat, Dec 10, 2016 at 12:53 AM, Tom Rini  wrote:
> >> -LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> >> +# Avoid Not enough room for program headers on binutils 2.28 onwards.
> >> +# Flag was introduced in 2.26
> >> +LDFLAGS_u-boot += $(LDFLAGS_FINAL) \
> >> + $(call ld-ifversion, -ge, 2260, --no-dynamic-linker)
> >
> > This breaks on things like:
> > $ arm-none-eabi-ld --version
> > GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150921
> 
> The flag will only be added when the version is >= 2.26. Which part of
> that version string will break the test?

The whole of the string breaks the test.  It comes out to 2037492100, is
greater than is true, and tries to pass the flag which isn't know about
in that version and fails.  Note that we're slightly behind the Linux
kernel version of the ld-version script, but dropping that one in (which
does have a bugfix) gives 22400 for the version.  Perhaps it would
give 22600 or similar instead for what you've got and we need to
update ld-version.sh in order to use this patch as-is?

-- 
Tom


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


Re: [U-Boot] [RFC PATCH 0/3] spl: Add D-cache support

2016-12-13 Thread Tom Rini
On Mon, Dec 12, 2016 at 03:22:50PM +0530, Lokesh Vutla wrote:
> Hi Tom,
> 
> On Monday 28 November 2016 03:04 PM, Lokesh Vutla wrote:
> > This series tries to add D-cache support in spl in order to reduce boot time
> > either in 2stage boot or Falcon Boot.
> 
> I hope there are no further comments on this series. Do you want me to
> re post this series or this is good to go?

This breaks building on a few platforms:
https://travis-ci.org/trini/u-boot/jobs/183441104
https://travis-ci.org/trini/u-boot/jobs/183441159
https://travis-ci.org/trini/u-boot/jobs/183441171

And break booting on omap4_panda:
20:02:33 U-Boot SPL 2017.01-rc1-00068-g8ae0906 (Dec 12 2016 - 19:11:20)
20:02:33 OMAP4460-GP ES1.1
20:02:33 Trying to boot from MMC1SPL: Please implement spl_start_uboot() for 
your board
20:02:33 SPL: Direct Linux boot not active!
20:02:33 reading u-boot.img
20:02:33 reading u-boot.img
[ hangs here ]

-- 
Tom


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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-13 Thread Igor Grinberg
On 12/13/16 13:12, Michal Simek wrote:
> On 13.12.2016 09:56, Igor Grinberg wrote:
>> On 12/12/16 14:05, Mike Looijmans wrote:
>>> On 12-12-16 09:18, Michal Simek wrote:
 On 12.12.2016 09:05, Igor Grinberg wrote:
> On 12/12/16 09:13, Nathan Rossi wrote:
>> On 12 December 2016 at 03:11, Igor Grinberg  
>> wrote:
>>> dropping the list for this one as the question seems to me irrelevant 
>>> to your patch set.
>>>
>>> On 12/11/16 18:47, Nathan Rossi wrote:
 On 12 December 2016 at 01:08, Igor Grinberg  
 wrote:
> Hi Nathan,
>
> On 12/11/16 15:58, Nathan Rossi wrote:
>> This series adds two functions for handling the memory bank decoding 
>> and
>> initialization of global data for use by boards in their dram_init 
>> and
>> dram_init_banksize functions.
>
> I might have missed some discussions on this meter,
> can you please provide the use cases for this?
> IMO, the bootloader's job is to initialize the DRAM, detect its size, 
> and pass
> the detected DRAM configuration on to an OS.

 Hi Igor,

 I do not think there have been any discussions on this (at least none
 that I am aware of).

 Some boards (like Zynq and ZynqMP ones) are using
 CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is available
 (since detection is not possible).
>>>
>>> May I ask why is detection not possible on these boards (may be SoCs)?
>>
>> That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
>> of cases are used in boards which have fixed memory device setups
>> (without any SPD or equivalent).
>
> Ok. That is understood. Yet, it does not explain why the detection
> cannot be done.. For example, you know which memory device setups you
> _can_ have on the board, so the detection is just to figure out which
> one is assembled. We are doing this on i.MXes, OMAPs, PXAs, and others.
>
> I was working on many ARM boards w/o SPD and still we almost always 
> develop
> a detection mechanism which has some assumptions and knowledge of the 
> board
> but it is much better then using some static data like compiled in or a 
> dtb.
>
> Have you considered a detection mechanism at all?

 If you look at my previous email as you see that topic.nl is using this.

 But the question is if this will work with all cases or just for
 particular configuration. All zynq/zynqmp boards requires initial
 setting which is created in Xilinx design tools. Export for these uniq
 configurations are in ps7_init* or psu_init* files where DDR
 configuration is part of this.

 Devices contain various configurations for various memory types. Also
 there is an option to add memory controller to programmable logic and
 use it.
>>>
>>> And the static memory controller can probably also be used to drive SRAM...
>>>
>>> But you could combine the two. The devicetree could set up the area's to 
>>> search, and then a detection routine to check
>  what's really there. This has the added value of a quick test that the
> memory actually works before starting to use it.
>>
>> That's exactly the point I was trying to show.
> 
> No problem with this but for me this is generic configuration option.
> It means this should be covered by Kconfig to be selected for specific
> platform. This code should go to common folder not to board folder or
> arm-mach folder.

Well, if it is generic enough it really should.

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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-13 Thread Igor Grinberg
On 12/13/16 13:07, Michal Simek wrote:
> On 13.12.2016 09:53, Igor Grinberg wrote:
>> On 12/12/16 13:56, Michal Simek wrote:
>>> On 12.12.2016 12:10, Igor Grinberg wrote:
 On 12/12/16 11:03, Michal Simek wrote:
> On 12.12.2016 09:54, Igor Grinberg wrote:
>> On 12/12/16 10:27, Michal Simek wrote:
>>> On 12.12.2016 09:24, Igor Grinberg wrote:
 On 12/12/16 10:02, Michal Simek wrote:
> On 12.12.2016 08:13, Nathan Rossi wrote:
>> On 12 December 2016 at 03:11, Igor Grinberg 
>>  wrote:
>>> dropping the list for this one as the question seems to me 
>>> irrelevant to your patch set.
>>>
>>> On 12/11/16 18:47, Nathan Rossi wrote:
 On 12 December 2016 at 01:08, Igor Grinberg 
  wrote:
> Hi Nathan,
>
> On 12/11/16 15:58, Nathan Rossi wrote:
>> This series adds two functions for handling the memory bank 
>> decoding and
>> initialization of global data for use by boards in their 
>> dram_init and
>> dram_init_banksize functions.
>
> I might have missed some discussions on this meter,
> can you please provide the use cases for this?
> IMO, the bootloader's job is to initialize the DRAM, detect its 
> size, and pass
> the detected DRAM configuration on to an OS.

 Hi Igor,

 I do not think there have been any discussions on this (at least 
 none
 that I am aware of).

 Some boards (like Zynq and ZynqMP ones) are using
 CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is 
 available
 (since detection is not possible).
>>>
>>> May I ask why is detection not possible on these boards (may be 
>>> SoCs)?
>>
>> That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
>> of cases are used in boards which have fixed memory device setups
>> (without any SPD or equivalent).
>
> For example zcu102 zynqmp development board is using modules with SPD 
> on
> it but if you look at generic SPD support then you will find out that
> FSL(drivers/ddr/fsl) is one of the major platform which is using it 
> for
> ddr size detection.
> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
> devices need to be configured at build time or at run time by DTB.
>
> There is also topic.nl boards which contain ddr configuration the same
> for different ddr sizes and Mike sent this patch to get it work
> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html

 That's exactly my point. I think Mike's patch does a way better job
 detecting at run time than any compiled in or a DT based pseudo 
 detection...

>
> Anyway in general there are some ways how to configure DDR size
> - build time setup (CONFIG_SYS_SDRAM*)
> - run time setup
>   - ddr detection
>   - via SPD (like FSL)
>   - via algorithm (like topic.nl)
>   - configuration
>   - read DTB
>
> Nathan's path is trying to address last run time DTB configuration
> method to be shared across platforms because similar stuff Uniphier is
> using too. And it doesn't make sense to copy that functions everywhere
> that's why this should go core parts.

 Yep. That's exactly what I thought. I see Nathan's patch set as an
 improvement of the current situation anyway.

 Also I think Mike's patch does a much better job on this.

>>>
>>> Just keep in your mind just in case that you know that your
>>> configuration supports it. If you don't have DDR connected to hard block
>>> and you use ddr to PL you don't even know where to look for DDR.
>>> And with arm64 it is pretty huge space.
>>
>> I see this as exactly the type of information that should be provided by
>> the board code or a dtb.
>
> I tend to remove all board files for zynq/zynqmp targets. Will see how
> we can do it in future.

 This is not really related to current thread...
>>>
>>> not directly but there is a connection.
>>>
 I'm not sure how this can be done... We're in a bootloader world here...
 It should be board specific by definition...
 There should be board specific code (not static data) somewhere, and
 I think we had agreed a year or so ago... on this meter.
 I think if you go this way, we will end up having board specific middleware
 all around... and lots of tools for 

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-13 Thread Michal Simek
On 13.12.2016 09:56, Igor Grinberg wrote:
> On 12/12/16 14:05, Mike Looijmans wrote:
>> On 12-12-16 09:18, Michal Simek wrote:
>>> On 12.12.2016 09:05, Igor Grinberg wrote:
 On 12/12/16 09:13, Nathan Rossi wrote:
> On 12 December 2016 at 03:11, Igor Grinberg  
> wrote:
>> dropping the list for this one as the question seems to me irrelevant to 
>> your patch set.
>>
>> On 12/11/16 18:47, Nathan Rossi wrote:
>>> On 12 December 2016 at 01:08, Igor Grinberg  
>>> wrote:
 Hi Nathan,

 On 12/11/16 15:58, Nathan Rossi wrote:
> This series adds two functions for handling the memory bank decoding 
> and
> initialization of global data for use by boards in their dram_init and
> dram_init_banksize functions.

 I might have missed some discussions on this meter,
 can you please provide the use cases for this?
 IMO, the bootloader's job is to initialize the DRAM, detect its size, 
 and pass
 the detected DRAM configuration on to an OS.
>>>
>>> Hi Igor,
>>>
>>> I do not think there have been any discussions on this (at least none
>>> that I am aware of).
>>>
>>> Some boards (like Zynq and ZynqMP ones) are using
>>> CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is available
>>> (since detection is not possible).
>>
>> May I ask why is detection not possible on these boards (may be SoCs)?
>
> That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
> of cases are used in boards which have fixed memory device setups
> (without any SPD or equivalent).

 Ok. That is understood. Yet, it does not explain why the detection
 cannot be done.. For example, you know which memory device setups you
 _can_ have on the board, so the detection is just to figure out which
 one is assembled. We are doing this on i.MXes, OMAPs, PXAs, and others.

 I was working on many ARM boards w/o SPD and still we almost always develop
 a detection mechanism which has some assumptions and knowledge of the board
 but it is much better then using some static data like compiled in or a 
 dtb.

 Have you considered a detection mechanism at all?
>>>
>>> If you look at my previous email as you see that topic.nl is using this.
>>>
>>> But the question is if this will work with all cases or just for
>>> particular configuration. All zynq/zynqmp boards requires initial
>>> setting which is created in Xilinx design tools. Export for these uniq
>>> configurations are in ps7_init* or psu_init* files where DDR
>>> configuration is part of this.
>>>
>>> Devices contain various configurations for various memory types. Also
>>> there is an option to add memory controller to programmable logic and
>>> use it.
>>
>> And the static memory controller can probably also be used to drive SRAM...
>>
>> But you could combine the two. The devicetree could set up the area's to 
>> search, and then a detection routine to check
 what's really there. This has the added value of a quick test that the
memory actually works before starting to use it.
> 
> That's exactly the point I was trying to show.

No problem with this but for me this is generic configuration option.
It means this should be covered by Kconfig to be selected for specific
platform. This code should go to common folder not to board folder or
arm-mach folder.

Thanks,
Michal


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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-13 Thread Michal Simek
On 13.12.2016 09:53, Igor Grinberg wrote:
> On 12/12/16 13:56, Michal Simek wrote:
>> On 12.12.2016 12:10, Igor Grinberg wrote:
>>> On 12/12/16 11:03, Michal Simek wrote:
 On 12.12.2016 09:54, Igor Grinberg wrote:
> On 12/12/16 10:27, Michal Simek wrote:
>> On 12.12.2016 09:24, Igor Grinberg wrote:
>>> On 12/12/16 10:02, Michal Simek wrote:
 On 12.12.2016 08:13, Nathan Rossi wrote:
> On 12 December 2016 at 03:11, Igor Grinberg  
> wrote:
>> dropping the list for this one as the question seems to me 
>> irrelevant to your patch set.
>>
>> On 12/11/16 18:47, Nathan Rossi wrote:
>>> On 12 December 2016 at 01:08, Igor Grinberg 
>>>  wrote:
 Hi Nathan,

 On 12/11/16 15:58, Nathan Rossi wrote:
> This series adds two functions for handling the memory bank 
> decoding and
> initialization of global data for use by boards in their 
> dram_init and
> dram_init_banksize functions.

 I might have missed some discussions on this meter,
 can you please provide the use cases for this?
 IMO, the bootloader's job is to initialize the DRAM, detect its 
 size, and pass
 the detected DRAM configuration on to an OS.
>>>
>>> Hi Igor,
>>>
>>> I do not think there have been any discussions on this (at least 
>>> none
>>> that I am aware of).
>>>
>>> Some boards (like Zynq and ZynqMP ones) are using
>>> CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is 
>>> available
>>> (since detection is not possible).
>>
>> May I ask why is detection not possible on these boards (may be 
>> SoCs)?
>
> That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
> of cases are used in boards which have fixed memory device setups
> (without any SPD or equivalent).

 For example zcu102 zynqmp development board is using modules with SPD 
 on
 it but if you look at generic SPD support then you will find out that
 FSL(drivers/ddr/fsl) is one of the major platform which is using it for
 ddr size detection.
 Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
 devices need to be configured at build time or at run time by DTB.

 There is also topic.nl boards which contain ddr configuration the same
 for different ddr sizes and Mike sent this patch to get it work
 http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>>>
>>> That's exactly my point. I think Mike's patch does a way better job
>>> detecting at run time than any compiled in or a DT based pseudo 
>>> detection...
>>>

 Anyway in general there are some ways how to configure DDR size
 - build time setup (CONFIG_SYS_SDRAM*)
 - run time setup
- ddr detection
- via SPD (like FSL)
- via algorithm (like topic.nl)
- configuration
- read DTB

 Nathan's path is trying to address last run time DTB configuration
 method to be shared across platforms because similar stuff Uniphier is
 using too. And it doesn't make sense to copy that functions everywhere
 that's why this should go core parts.
>>>
>>> Yep. That's exactly what I thought. I see Nathan's patch set as an
>>> improvement of the current situation anyway.
>>>
>>> Also I think Mike's patch does a much better job on this.
>>>
>>
>> Just keep in your mind just in case that you know that your
>> configuration supports it. If you don't have DDR connected to hard block
>> and you use ddr to PL you don't even know where to look for DDR.
>> And with arm64 it is pretty huge space.
>
> I see this as exactly the type of information that should be provided by
> the board code or a dtb.

 I tend to remove all board files for zynq/zynqmp targets. Will see how
 we can do it in future.
>>>
>>> This is not really related to current thread...
>>
>> not directly but there is a connection.
>>
>>> I'm not sure how this can be done... We're in a bootloader world here...
>>> It should be board specific by definition...
>>> There should be board specific code (not static data) somewhere, and
>>> I think we had agreed a year or so ago... on this meter.
>>> I think if you go this way, we will end up having board specific middleware
>>> all around... and lots of tools for changing the static data (e.g. dtbs).
>>
>> Look at microblaze. I am not accepting any board to be added for it
>> because every configuration is different.
> 
> 

[U-Boot] [PATCH] armv8/fsl_lsch2: Add the OCRAM initialization

2016-12-13 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Clear the content to zero and the ECC error bit of OCRAM1/2.

The OCRAM must be initialized to ZERO by the unit of 8-Byte before
accessing it, or else it will generate ECC error. And the IBR has
accessed the OCRAM before this initialization, so the ECC error
status bit should to be cleared.

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Pratiyush Srivastava 
Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  | 37 +++
 arch/arm/include/asm/arch-fsl-layerscape/config.h |  3 ++
 2 files changed, 40 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index e5916ee..d74e749 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -245,10 +245,47 @@ ENTRY(lowlevel_init)
isb
 #endif
 
+#if defined(CONFIG_FSL_LSCH2) && !defined(CONFIG_SPL_BUILD)
+   bl  fsl_ocram_init
+#endif
+
mov lr, x29 /* Restore LR */
ret
 ENDPROC(lowlevel_init)
 
+#if defined(CONFIG_FSL_LSCH2) && !defined(CONFIG_SPL_BUILD)
+ENTRY(fsl_ocram_init)
+   mov x28, lr /* Save LR */
+   bl  fsl_clear_ocram
+   bl  fsl_ocram_clear_ecc_err
+   mov lr, x28 /* Restore LR */
+   ret
+ENDPROC(fsl_ocram_init)
+
+ENTRY(fsl_clear_ocram)
+/* Clear OCRAM */
+   ldr x0, =CONFIG_SYS_FSL_OCRAM_BASE
+   ldr x1, =(CONFIG_SYS_FSL_OCRAM_BASE + CONFIG_SYS_FSL_OCRAM_SIZE)
+   mov x2, #0
+clear_loop:
+   str x2, [x0]
+   add x0, x0, #8
+   cmp x0, x1
+   b.loclear_loop
+   ret
+ENDPROC(fsl_clear_ocram)
+
+ENTRY(fsl_ocram_clear_ecc_err)
+   /* OCRAM1/2 ECC status bit */
+   mov w1, #0x60
+   ldr x0, =DCSR_DCFG_SBEESR2
+   str w1, [x0]
+   ldr x0, =DCSR_DCFG_MBEESR2
+   str w1, [x0]
+   ret
+ENDPROC(fsl_ocram_init)
+#endif
+
 #ifdef CONFIG_FSL_LSCH3
 hnf_pstate_poll:
/* x0 has the desired status, return 0 for success, 1 for timeout
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index ce6233d..021dd19 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -164,6 +164,9 @@
 #define CONFIG_SYS_FSL_OCRAM_SIZE  0x0020 /* 2M */
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0x0100
 
+#define DCSR_DCFG_SBEESR2  0x20140534
+#define DCSR_DCFG_MBEESR2  0x20140544
+
 #define CONFIG_SYS_FSL_CCSR_SCFG_BE
 #define CONFIG_SYS_FSL_ESDHC_BE
 #define CONFIG_SYS_FSL_WDOG_BE
-- 
2.1.0.27.g96db324

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


[U-Boot] [RFC PATCH 3/3] sunxi: Enable H3 video driver in defconfigs

2016-12-13 Thread Jernej Skrabec
Signed-off-by: Jernej Skrabec 
---

 configs/orangepi_2_defconfig   | 1 +
 configs/orangepi_lite_defconfig| 1 +
 configs/orangepi_one_defconfig | 1 +
 configs/orangepi_pc_defconfig  | 1 +
 configs/orangepi_pc_plus_defconfig | 1 +
 configs/orangepi_plus2e_defconfig  | 1 +
 configs/orangepi_plus_defconfig| 1 +
 7 files changed, 7 insertions(+)

diff --git a/configs/orangepi_2_defconfig b/configs/orangepi_2_defconfig
index 4727aca..dea819d 100644
--- a/configs/orangepi_2_defconfig
+++ b/configs/orangepi_2_defconfig
@@ -16,3 +16,4 @@ CONFIG_SPL=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_SY8106A_POWER=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
diff --git a/configs/orangepi_lite_defconfig b/configs/orangepi_lite_defconfig
index 8545835..8801825 100644
--- a/configs/orangepi_lite_defconfig
+++ b/configs/orangepi_lite_defconfig
@@ -12,3 +12,4 @@ CONFIG_SPL=y
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
diff --git a/configs/orangepi_one_defconfig b/configs/orangepi_one_defconfig
index 01b4ece..fc72a96 100644
--- a/configs/orangepi_one_defconfig
+++ b/configs/orangepi_one_defconfig
@@ -13,3 +13,4 @@ CONFIG_SPL=y
 # CONFIG_CMD_FPGA is not set
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
diff --git a/configs/orangepi_pc_defconfig b/configs/orangepi_pc_defconfig
index 910d68e..e0b579d 100644
--- a/configs/orangepi_pc_defconfig
+++ b/configs/orangepi_pc_defconfig
@@ -15,3 +15,4 @@ CONFIG_SPL=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_SY8106A_POWER=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
diff --git a/configs/orangepi_pc_plus_defconfig 
b/configs/orangepi_pc_plus_defconfig
index f43682b..9b8d407 100644
--- a/configs/orangepi_pc_plus_defconfig
+++ b/configs/orangepi_pc_plus_defconfig
@@ -16,3 +16,4 @@ CONFIG_SPL=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_SY8106A_POWER=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
diff --git a/configs/orangepi_plus2e_defconfig 
b/configs/orangepi_plus2e_defconfig
index df05d37..0eb9466 100644
--- a/configs/orangepi_plus2e_defconfig
+++ b/configs/orangepi_plus2e_defconfig
@@ -17,3 +17,4 @@ CONFIG_SPL=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_SY8106A_POWER=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
diff --git a/configs/orangepi_plus_defconfig b/configs/orangepi_plus_defconfig
index bf88fef..c773ef2 100644
--- a/configs/orangepi_plus_defconfig
+++ b/configs/orangepi_plus_defconfig
@@ -18,3 +18,4 @@ CONFIG_SPL=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_SY8106A_POWER=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_VIDEO=y
-- 
2.10.2

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


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

2016-12-13 Thread Joel Stanley
Hello Tom,

On Sat, Dec 10, 2016 at 12:53 AM, Tom Rini  wrote:
>> -LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>> +# Avoid Not enough room for program headers on binutils 2.28 onwards.
>> +# Flag was introduced in 2.26
>> +LDFLAGS_u-boot += $(LDFLAGS_FINAL) \
>> + $(call ld-ifversion, -ge, 2260, --no-dynamic-linker)
>
> This breaks on things like:
> $ arm-none-eabi-ld --version
> GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150921

The flag will only be added when the version is >= 2.26. Which part of
that version string will break the test?

> so please use ld-option instead to add this when supported, thanks!

If you'd just prefer ld-option over ld-ifversion then I can send a
different patch.

Cheers,

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


[U-Boot] [RFC PATCH 1/3] sunxi: Add clocks for DE2/HDMI/TCON

2016-12-13 Thread Jernej Skrabec
This is needed for HDMI support, which will be added later.

Signed-off-by: Jernej Skrabec 
---

 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 43 +++
 arch/arm/mach-sunxi/clock_sun6i.c | 28 +
 2 files changed, 71 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index be9fcfd..c19c200 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -67,12 +67,20 @@ struct sunxi_ccm_reg {
u32 dram_pll_cfg;   /* 0xf8 PLL_DDR cfg register, A33 only */
u32 mbus_reset; /* 0xfc MBUS reset control, A33 only */
u32 dram_clk_gate;  /* 0x100 DRAM module gating */
+#ifdef CONFIG_MACH_SUN8I_H3
+   u32 de_clk_cfg; /* 0x104 DE module clock */
+#else
u32 be0_clk_cfg;/* 0x104 BE0 module clock */
+#endif
u32 be1_clk_cfg;/* 0x108 BE1 module clock */
u32 fe0_clk_cfg;/* 0x10c FE0 module clock */
u32 fe1_clk_cfg;/* 0x110 FE1 module clock */
u32 mp_clk_cfg; /* 0x114 MP module clock */
+#ifdef CONFIG_MACH_SUN8I_H3
+   u32 tcon0_clk_cfg;  /* 0x118 TCON0 module clock */
+#else
u32 lcd0_ch0_clk_cfg;   /* 0x118 LCD0 CH0 module clock */
+#endif
u32 lcd1_ch0_clk_cfg;   /* 0x11c LCD1 CH0 module clock */
u32 reserved14[3];
u32 lcd0_ch1_clk_cfg;   /* 0x12c LCD0 CH1 module clock */
@@ -85,7 +93,11 @@ struct sunxi_ccm_reg {
u32 dmic_clk_cfg;   /* 0x148 Digital Mic module clock*/
u32 reserved15;
u32 hdmi_clk_cfg;   /* 0x150 HDMI module clock */
+#ifdef CONFIG_MACH_SUN8I_H3
+   u32 hdmi_slow_clk_cfg;  /* 0x154 HDMI slow module clock */
+#else
u32 ps_clk_cfg; /* 0x154 PS module clock */
+#endif
u32 mtc_clk_cfg;/* 0x158 MTC module clock */
u32 mbus0_clk_cfg;  /* 0x15c MBUS0 module clock */
u32 mbus1_clk_cfg;  /* 0x160 MBUS1 module clock */
@@ -220,6 +232,15 @@ struct sunxi_ccm_reg {
 #define CCM_MIPI_PLL_CTRL_LDO_EN   (0x3 << 22)
 #define CCM_MIPI_PLL_CTRL_EN   (0x1 << 31)
 
+#define CCM_PLL10_CTRL_M_SHIFT 0
+#define CCM_PLL10_CTRL_M_MASK  (0xf << CCM_PLL10_CTRL_M_SHIFT)
+#define CCM_PLL10_CTRL_M(n)n) - 1) & 0xf) << 0)
+#define CCM_PLL10_CTRL_N_SHIFT 8
+#define CCM_PLL10_CTRL_N_MASK  (0x7f << CCM_PLL10_CTRL_N_SHIFT)
+#define CCM_PLL10_CTRL_N(n)n) - 1) & 0x7f) << 8)
+#define CCM_PLL10_CTRL_INTEGER_MODE(0x1 << 24)
+#define CCM_PLL10_CTRL_EN  (0x1 << 31)
+
 #define CCM_PLL11_CTRL_N(n)n) - 1) & 0x3f) << 8)
 #define CCM_PLL11_CTRL_SIGMA_DELTA_EN  (0x1 << 24)
 #define CCM_PLL11_CTRL_UPD (0x1 << 30)
@@ -271,9 +292,12 @@ struct sunxi_ccm_reg {
 #define AHB_GATE_OFFSET_DRC0   25
 #define AHB_GATE_OFFSET_DE_FE0 14
 #define AHB_GATE_OFFSET_DE_BE0 12
+#define AHB_GATE_OFFSET_DE 12
 #define AHB_GATE_OFFSET_HDMI   11
 #define AHB_GATE_OFFSET_LCD1   5
 #define AHB_GATE_OFFSET_LCD0   4
+#define AHB_GATE_OFFSET_TCON1  4
+#define AHB_GATE_OFFSET_TCON0  3
 
 #define CCM_MMC_CTRL_M(x)  ((x) - 1)
 #define CCM_MMC_CTRL_OCLK_DLY(x)   ((x) << 8)
@@ -346,6 +370,9 @@ struct sunxi_ccm_reg {
 #define CCM_LCD_CH0_CTRL_RST   0
 #define CCM_LCD_CH0_CTRL_GATE  (0x1 << 31)
 
+#define CCM_TCON0_CTRL_GATE(0x1 << 31)
+#define CCM_TCON0_CTRL_M(n)n) - 1) & 0xf) << 0)
+
 #define CCM_LCD_CH1_CTRL_M(n)  n) - 1) & 0xf) << 0)
 #define CCM_LCD_CH1_CTRL_HALF_SCLK10 /* no seperate sclk1 & 2 on sun6i */
 #define CCM_LCD_CH1_CTRL_PLL3  (0 << 24)
@@ -355,6 +382,7 @@ struct sunxi_ccm_reg {
 #define CCM_LCD_CH1_CTRL_GATE  (0x1 << 31)
 
 #define CCM_HDMI_CTRL_M(n) n) - 1) & 0xf) << 0)
+#define CCM_HDMI_CTRL_M_MASK   (0xf << 0)
 #define CCM_HDMI_CTRL_PLL_MASK (3 << 24)
 #define CCM_HDMI_CTRL_PLL3 (0 << 24)
 #define CCM_HDMI_CTRL_PLL7 (1 << 24)
@@ -363,6 +391,8 @@ struct sunxi_ccm_reg {
 #define CCM_HDMI_CTRL_DDC_GATE (0x1 << 30)
 #define CCM_HDMI_CTRL_GATE (0x1 << 31)
 
+#define CCM_HDMI_SLOW_CTRL_DDC_GATE(1 << 31)
+
 #if defined(CONFIG_MACH_SUN50I)
 #define MBUS_CLK_DEFAULT   0x8102 /* PLL6x2 / 3 */
 #elif defined(CONFIG_MACH_SUN8I)
@@ -390,9 +420,13 @@ struct sunxi_ccm_reg {
 #define AHB_RESET_OFFSET_DRC0  25
 #define AHB_RESET_OFFSET_DE_FE014
 #define AHB_RESET_OFFSET_DE_BE012
+#define AHB_RESET_OFFSET_DE12
 #define AHB_RESET_OFFSET_HDMI  11
+#define AHB_RESET_OFFSET_HDMI2 10
 #define AHB_RESET_OFFSET_LCD1  5
 #define AHB_RESET_OFFSET_LCD0  4
+#define AHB_RESET_OFFSET_TCON1   

[U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

2016-12-13 Thread Jernej Skrabec
This patch adds support for hdmi output. It is designed in the same
way as video driver for older Allwinner SoCs.

First it checks if monitor is attached. If it is, recommended
timings are read from EDID. After that, DE2, TCON and HDMI are
configured according to this timings.

32MB of RAM is used for framebuffer. This is just enough to support
4K resolution.

SimpleFB is also supported by this driver.

Signed-off-by: Jernej Skrabec 
---

 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |8 +
 arch/arm/include/asm/arch-sunxi/display2.h  |  377 ++
 board/sunxi/Kconfig |4 +-
 drivers/video/Makefile  |1 +
 drivers/video/sunxi_display2.c  | 1037 +++
 include/configs/sunxi-common.h  |   17 +-
 scripts/config_whitelist.txt|1 +
 7 files changed, 1438 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/display2.h
 create mode 100644 drivers/video/sunxi_display2.c

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 7232f6d..9df6212 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -18,6 +18,8 @@
 #define SUNXI_SRAM_D_BASE  0x0001  /* 4 kiB */
 #define SUNXI_SRAM_B_BASE  0x0002  /* 64 kiB (secure) */
 
+#define SUNXI_DE2_BASE 0x0100
+
 #ifdef CONFIG_MACH_SUN8I_A83T
 #define SUNXI_CPUCFG_BASE  0x0170
 #endif
@@ -46,7 +48,9 @@
 #define SUNXI_USB1_BASE0x01c14000
 #endif
 #define SUNXI_SS_BASE  0x01c15000
+#ifndef CONFIG_MACH_SUN8I_H3
 #define SUNXI_HDMI_BASE0x01c16000
+#endif
 #define SUNXI_SPI2_BASE0x01c17000
 #define SUNXI_SATA_BASE0x01c18000
 #ifdef CONFIG_SUNXI_GEN_SUN4I
@@ -163,6 +167,10 @@ defined(CONFIG_MACH_SUN50I)
 #define SUNXI_MP_BASE  0x01e8
 #define SUNXI_AVG_BASE 0x01ea
 
+#ifdef CONFIG_MACH_SUN8I_H3
+#define SUNXI_HDMI_BASE0x01ee
+#endif
+
 #define SUNXI_RTC_BASE 0x01f0
 #define SUNXI_PRCM_BASE0x01f01400
 
diff --git a/arch/arm/include/asm/arch-sunxi/display2.h 
b/arch/arm/include/asm/arch-sunxi/display2.h
new file mode 100644
index 000..b1d99d7
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/display2.h
@@ -0,0 +1,377 @@
+/*
+ * Sunxi platform display controller register and constant defines
+ *
+ * (C) Copyright 2016 Jernej Skrabec 
+ *
+ * Based on Linux DRM driver defines:
+ * Copyright (C) 2016 Jean-Francois Moine 
+ * Copyright (c) 2016 Allwinnertech Co., Ltd.
+ *
+ * Based on display.h:
+ * (C) Copyright 2014 Hans de Goede 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_DISPLAY2_H
+#define _SUNXI_DISPLAY2_H
+
+struct sunxi_lcdc_reg {
+   u32 ctrl;   /* 0x00 */
+   u32 int0;   /* 0x04 */
+   u32 int1;   /* 0x08 */
+   u8 res0[0x04];  /* 0x0c */
+   u32 tcon0_frm_ctrl; /* 0x10 */
+   u32 tcon0_frm_seed[6];  /* 0x14 */
+   u32 tcon0_frm_table[4]; /* 0x2c */
+   u8 res1[4]; /* 0x3c */
+   u32 tcon0_ctrl; /* 0x40 */
+   u32 tcon0_dclk; /* 0x44 */
+   u32 tcon0_timing_active;/* 0x48 */
+   u32 tcon0_timing_h; /* 0x4c */
+   u32 tcon0_timing_v; /* 0x50 */
+   u32 tcon0_timing_sync;  /* 0x54 */
+   u32 tcon0_hv_intf;  /* 0x58 */
+   u8 res2[0x04];  /* 0x5c */
+   u32 tcon0_cpu_intf; /* 0x60 */
+   u32 tcon0_cpu_wr_dat;   /* 0x64 */
+   u32 tcon0_cpu_rd_dat0;  /* 0x68 */
+   u32 tcon0_cpu_rd_dat1;  /* 0x6c */
+   u32 tcon0_ttl_timing0;  /* 0x70 */
+   u32 tcon0_ttl_timing1;  /* 0x74 */
+   u32 tcon0_ttl_timing2;  /* 0x78 */
+   u32 tcon0_ttl_timing3;  /* 0x7c */
+   u32 tcon0_ttl_timing4;  /* 0x80 */
+   u32 tcon0_lvds_intf;/* 0x84 */
+   u32 tcon0_io_polarity;  /* 0x88 */
+   u32 tcon0_io_tristate;  /* 0x8c */
+   u32 tcon1_ctrl; /* 0x90 */
+   u32 tcon1_timing_source;/* 0x94 */
+   u32 tcon1_timing_scale; /* 0x98 */
+   u32 tcon1_timing_out;   /* 0x9c */
+   u32 tcon1_timing_h; /* 0xa0 */
+   u32 tcon1_timing_v; /* 0xa4 */
+   u32 tcon1_timing_sync;  /* 0xa8 */
+   u8 res3[0x44];  /* 0xac */
+   u32 tcon1_io_polarity;  /* 0xf0 */
+   u32 tcon1_io_tristate; 

[U-Boot] [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-13 Thread Jernej Skrabec
This patch series add support for HDMI output. Support for other,
newer, SoCs, which also uses DE2 and same or similar HDMI controller
and PHY can be easily added later (A83T/A64/H5/R40). Current driver
can also be easily extended with TV out support, just like video
driver for older Allwinner SoCs.

While driver works, I would like to get few opinions first.
- From what I understand, drivers which supports DT are preferred.
  Would it be better to rewrite this driver to support device tree?
- TCON code is currently exactly the same as in driver for older
  SoCs. Should I split it out into shared module? Also TV out code
  seems to be similar, but I didn't manage to confirm that it works
  as-is on H3.
- A80 SoC is mix of older display engine and newer HDMI controller,
  so it doesn't really work with either of sunxi video drivers. Two
  solutions I see here are either combine both driver into one massive
  display driver or, much better, split everything by components
  (TCON/DE/DE2/HDMI/TV) and instantiate compatible ones. I guess this
  is not much different than adding support for DT in drivers. Note
  that I don't have any A80 board, I'm just thinking ahead.

Best regards,
Jernej Skrabec


Jernej Skrabec (3):
  sunxi: Add clocks for DE2/HDMI/TCON
  sunxi: video: Add video driver for H3 SoC
  sunxi: Enable H3 video driver in defconfigs

 arch/arm/include/asm/arch-sunxi/clock_sun6i.h |   43 +
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |8 +
 arch/arm/include/asm/arch-sunxi/display2.h|  377 +
 arch/arm/mach-sunxi/clock_sun6i.c |   28 +
 board/sunxi/Kconfig   |4 +-
 configs/orangepi_2_defconfig  |1 +
 configs/orangepi_lite_defconfig   |1 +
 configs/orangepi_one_defconfig|1 +
 configs/orangepi_pc_defconfig |1 +
 configs/orangepi_pc_plus_defconfig|1 +
 configs/orangepi_plus2e_defconfig |1 +
 configs/orangepi_plus_defconfig   |1 +
 drivers/video/Makefile|1 +
 drivers/video/sunxi_display2.c| 1037 +
 include/configs/sunxi-common.h|   17 +-
 scripts/config_whitelist.txt  |1 +
 16 files changed, 1516 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/display2.h
 create mode 100644 drivers/video/sunxi_display2.c

-- 
2.10.2

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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-13 Thread Igor Grinberg
On 12/12/16 14:05, Mike Looijmans wrote:
> On 12-12-16 09:18, Michal Simek wrote:
>> On 12.12.2016 09:05, Igor Grinberg wrote:
>>> On 12/12/16 09:13, Nathan Rossi wrote:
 On 12 December 2016 at 03:11, Igor Grinberg  
 wrote:
> dropping the list for this one as the question seems to me irrelevant to 
> your patch set.
>
> On 12/11/16 18:47, Nathan Rossi wrote:
>> On 12 December 2016 at 01:08, Igor Grinberg  
>> wrote:
>>> Hi Nathan,
>>>
>>> On 12/11/16 15:58, Nathan Rossi wrote:
 This series adds two functions for handling the memory bank decoding 
 and
 initialization of global data for use by boards in their dram_init and
 dram_init_banksize functions.
>>>
>>> I might have missed some discussions on this meter,
>>> can you please provide the use cases for this?
>>> IMO, the bootloader's job is to initialize the DRAM, detect its size, 
>>> and pass
>>> the detected DRAM configuration on to an OS.
>>
>> Hi Igor,
>>
>> I do not think there have been any discussions on this (at least none
>> that I am aware of).
>>
>> Some boards (like Zynq and ZynqMP ones) are using
>> CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is available
>> (since detection is not possible).
>
> May I ask why is detection not possible on these boards (may be SoCs)?

 That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
 of cases are used in boards which have fixed memory device setups
 (without any SPD or equivalent).
>>>
>>> Ok. That is understood. Yet, it does not explain why the detection
>>> cannot be done.. For example, you know which memory device setups you
>>> _can_ have on the board, so the detection is just to figure out which
>>> one is assembled. We are doing this on i.MXes, OMAPs, PXAs, and others.
>>>
>>> I was working on many ARM boards w/o SPD and still we almost always develop
>>> a detection mechanism which has some assumptions and knowledge of the board
>>> but it is much better then using some static data like compiled in or a dtb.
>>>
>>> Have you considered a detection mechanism at all?
>>
>> If you look at my previous email as you see that topic.nl is using this.
>>
>> But the question is if this will work with all cases or just for
>> particular configuration. All zynq/zynqmp boards requires initial
>> setting which is created in Xilinx design tools. Export for these uniq
>> configurations are in ps7_init* or psu_init* files where DDR
>> configuration is part of this.
>>
>> Devices contain various configurations for various memory types. Also
>> there is an option to add memory controller to programmable logic and
>> use it.
> 
> And the static memory controller can probably also be used to drive SRAM...
> 
> But you could combine the two. The devicetree could set up the area's to 
> search, and then a detection routine to check what's really there. This has 
> the added value of a quick test that the memory actually works before 
> starting to use it.

That's exactly the point I was trying to show.
Thanks Mike.


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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-13 Thread Igor Grinberg
On 12/12/16 13:56, Michal Simek wrote:
> On 12.12.2016 12:10, Igor Grinberg wrote:
>> On 12/12/16 11:03, Michal Simek wrote:
>>> On 12.12.2016 09:54, Igor Grinberg wrote:
 On 12/12/16 10:27, Michal Simek wrote:
> On 12.12.2016 09:24, Igor Grinberg wrote:
>> On 12/12/16 10:02, Michal Simek wrote:
>>> On 12.12.2016 08:13, Nathan Rossi wrote:
 On 12 December 2016 at 03:11, Igor Grinberg  
 wrote:
> dropping the list for this one as the question seems to me irrelevant 
> to your patch set.
>
> On 12/11/16 18:47, Nathan Rossi wrote:
>> On 12 December 2016 at 01:08, Igor Grinberg 
>>  wrote:
>>> Hi Nathan,
>>>
>>> On 12/11/16 15:58, Nathan Rossi wrote:
 This series adds two functions for handling the memory bank 
 decoding and
 initialization of global data for use by boards in their dram_init 
 and
 dram_init_banksize functions.
>>>
>>> I might have missed some discussions on this meter,
>>> can you please provide the use cases for this?
>>> IMO, the bootloader's job is to initialize the DRAM, detect its 
>>> size, and pass
>>> the detected DRAM configuration on to an OS.
>>
>> Hi Igor,
>>
>> I do not think there have been any discussions on this (at least none
>> that I am aware of).
>>
>> Some boards (like Zynq and ZynqMP ones) are using
>> CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is 
>> available
>> (since detection is not possible).
>
> May I ask why is detection not possible on these boards (may be SoCs)?

 That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
 of cases are used in boards which have fixed memory device setups
 (without any SPD or equivalent).
>>>
>>> For example zcu102 zynqmp development board is using modules with SPD on
>>> it but if you look at generic SPD support then you will find out that
>>> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
>>> ddr size detection.
>>> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
>>> devices need to be configured at build time or at run time by DTB.
>>>
>>> There is also topic.nl boards which contain ddr configuration the same
>>> for different ddr sizes and Mike sent this patch to get it work
>>> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>>
>> That's exactly my point. I think Mike's patch does a way better job
>> detecting at run time than any compiled in or a DT based pseudo 
>> detection...
>>
>>>
>>> Anyway in general there are some ways how to configure DDR size
>>> - build time setup (CONFIG_SYS_SDRAM*)
>>> - run time setup
>>> - ddr detection
>>> - via SPD (like FSL)
>>> - via algorithm (like topic.nl)
>>> - configuration
>>> - read DTB
>>>
>>> Nathan's path is trying to address last run time DTB configuration
>>> method to be shared across platforms because similar stuff Uniphier is
>>> using too. And it doesn't make sense to copy that functions everywhere
>>> that's why this should go core parts.
>>
>> Yep. That's exactly what I thought. I see Nathan's patch set as an
>> improvement of the current situation anyway.
>>
>> Also I think Mike's patch does a much better job on this.
>>
>
> Just keep in your mind just in case that you know that your
> configuration supports it. If you don't have DDR connected to hard block
> and you use ddr to PL you don't even know where to look for DDR.
> And with arm64 it is pretty huge space.

 I see this as exactly the type of information that should be provided by
 the board code or a dtb.
>>>
>>> I tend to remove all board files for zynq/zynqmp targets. Will see how
>>> we can do it in future.
>>
>> This is not really related to current thread...
> 
> not directly but there is a connection.
> 
>> I'm not sure how this can be done... We're in a bootloader world here...
>> It should be board specific by definition...
>> There should be board specific code (not static data) somewhere, and
>> I think we had agreed a year or so ago... on this meter.
>> I think if you go this way, we will end up having board specific middleware
>> all around... and lots of tools for changing the static data (e.g. dtbs).
> 
> Look at microblaze. I am not accepting any board to be added for it
> because every configuration is different.

I'm not sure I get your point.

> The same can be done for
> zynq/zynqmp boards when we move stuff to DM.
> Then for supporting new platform you don't need to create folder in
> 

[U-Boot] [RFC PATCH] mmc: mmc-uclass: use the fixed devnum with aliase node

2016-12-13 Thread Jaehoon Chung
If there are aliase nodes as "mmc", use the devnum as aliase index
number.
This patch is for fixing a problem of Exynos4 series.
Problem is the below thing.

Current legacy mode:
EXYNOS DWMMC: 0, SAMSUNG SDHCI: 1

After using DM:
SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1

Dev index is swapped.
Then u-boot can't find the kernel image..because it is already set to 0 as 
mmcdev.
If change from legacy to DM, also needs to touch all exynos4 config file.
For using simply, just supporting the fixed devnum with aliase node is better 
than it.

Usage:
alaise {

mmc0 =  /* eMMC */
mmc1 =  /* SD */
...
}

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/mmc-uclass.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 2fe5d61..a6c8458 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -13,6 +13,8 @@
 #include 
 #include "mmc_private.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #ifdef CONFIG_DM_MMC_OPS
 int dm_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
struct mmc_data *data)
@@ -192,10 +194,13 @@ int mmc_bind(struct udevice *dev, struct mmc *mmc, const 
struct mmc_config *cfg)
 {
struct blk_desc *bdesc;
struct udevice *bdev;
-   int ret;
+   int ret, devnum = -1;
+
+   /* Use the fixed index with aliase node's index */
+   fdtdec_get_alias_seq(gd->fdt_blob, "mmc", dev->of_offset, );
 
-   ret = blk_create_devicef(dev, "mmc_blk", "blk", IF_TYPE_MMC, -1, 512,
-0, );
+   ret = blk_create_devicef(dev, "mmc_blk", "blk", IF_TYPE_MMC,
+   devnum, 512, 0, );
if (ret) {
debug("Cannot create block device\n");
return ret;
-- 
2.10.2

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