Re: [U-Boot] [PATCH 5/5] arm/rpi: Enable dcache

[Stephen Warren]

On 07/04/2015 03:48 AM, Alexander Stein wrote:
> Now that mailbox driver supports cache flush and invalidation, we can
> enable dcache.

Did you also test that HDMI output doesn't show any issues after this
change? I think there's already cache-flushing in the LCD console code,
so it should be fine, but best to check.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw mailbox

[Stephen Warren]

On 07/04/2015 03:48 AM, Alexander Stein wrote:
> When using dcache the setup data for the mailbox must be actually written
> into memory before calling into firmware. Thus flush and invalidate the
> memory.

> diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c

> + flush_dcache_range((unsigned long)buffer,
> +(unsigned long)((void *)buffer +
> +buffer->buf_size));
> + invalidate_dcache_range((unsigned long)buffer,
> + (unsigned long)((void *)buffer +
> + buffer->buf_size));
>   ret = bcm2835_mbox_call_raw(chan, phys_to_bus((u32)buffer), &rbuffer);
>   if (ret)
>   return ret;

I'm not sure of the details of ARMv6 memory pre-fetching, so perhaps
this doesn't matter. However, I think it'd be best if this code did:

flush cache
execute mailbox operation
invalidate cache
use results

... rather than doing the invalidate before executing the mailbox
operation. This change would guarantee that the invalidate happens after
the VideoCore has written the response into RAM, and hence guarantees
that the invalidate will cause the response to be picked up.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] arm1176/cpu: Add icache and dcache support

[Stephen Warren]

On 07/04/2015 03:48 AM, Alexander Stein wrote:
> The code is copied 1:1 from arm1136 which uses the same cp15 registers.

Same comment here. Perhaps create a cache-armv6.c (or whatever name is
appropriate; I'm not sure if ARMv6 mandates caches work this way, or if
ARM11 is a better name, or ...?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] arm1176/cpu: Align cache flushing addresses to cacheline size

[Stephen Warren]

On 07/04/2015 03:48 AM, Alexander Stein wrote:
> cache flushing addresses must be cacheline size aligned, so mask the
> start and stop address appropriately.

As mentioned elsewhere, NAK.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] arm1176/cpu: Match cache_flush to arm1136

[Stephen Warren]

On 07/04/2015 03:48 AM, Alexander Stein wrote:
> This is effectively the same code but it also does a clean cache before
> invalidating and doing a memory barrier.

Is it possible to share this function with arm1136 rather than
cut/pasting it? I guess it's pretty small so not a huge deal, but still.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1

[Stephen Warren]

On 07/04/2015 03:48 AM, Alexander Stein wrote:
> This patchset enables dcache support for Raspberry Pi 1.
> First the cache support code was made similar to existing arm1136 code.
> The invalidate and flush functions were inprovoed to accept also non-cacheline
> aligned addresses. This reduces the cacheline size knowledge from generic
> code.

As mentioned in some other responses, client code must be aware of the
cacheline size, so the cache management code shouldn't try to handle
misaligned requests, but should error out.

BTW, ALLOC_ALIGN_BUFFER() is probably what you need to fix any
misbehaved client code.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] scripts: RPi 2: only 1 out of 4 CPUs brought up

[Stephen Warren]

On 06/30/2015 05:56 AM, Jonas Jensen wrote:
> Hello,
> 
> I have found the following issue with RPi 2:
> 
> Only 1 CPU is brought up when the kernel is started from script (see [1]).
> 
> All 4 CPUs are brought up if started "manually" typing in environment
> variables from said script (see [2]).

I suspect it's a fluke that it works when you run things manually/slowly.

I /think/ that before the binary FW starts U-Boot (or whatever it
boots), it releases all 4 CPUs from reset, and CPU1..n all end up
running a tiny piece of code ("SMP pen") that just loops doing nothing
until some flag is set. All code that runs on CPU0 must be careful not
to corrupt that code or the flag it uses. However, U-Boot (and I expect
the upstream kernel) don't yet know about this, and hence
sometimes/often corrupt that SMP pen, resulting in strange behaviour.
I'm pretty sure I've seen all 4 CPUs start booting the Linux kernel in
parallel before.

In summary, I know there are issues in this area when using U-Boot. I
don't know of any fix at present. Either U-Boot must hard-code some
reserved memory regions, or perhaps the binary FW has some way of
informing SW where the SMP pen region is, and U-Boot needs to learn how
to find/interpret that information (and pass it to the kernel via
/memreserve/ or similar in DT).

Eric, did you find out any more details on the SMP pen mechanism since I
last asked you about it?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc:fsl_esdhc invalidate dcache before read

[Peng Fan]

Hi Stefano,

On Fri, Jul 10, 2015 at 09:56:23AM +0200, Stefano Babic wrote:
>Hi Peng,
>
>
>I see this patch is now delegated to me. Then, I have no objections to
>merge it into u-boot-imx if Pantelis agree.
>
>
>On 25/06/2015 04:32, Peng Fan wrote:
>> DCIMVAC is upgraded to DCCIMVAC for the individual processor
>> (Cortex-A7) that the DCIMVAC is executed on.
>> 
>Can you better explain it ? What are the consequences of using DCCIMVAC
>into this driver ?

This is from 
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464f/DDI0464F_cortex_a7_mpcore_r0p5_trm.pdf

"
DCIMVAC means Data cache invalidate by MVA to PoC
DCCIMVAC means Data cache clean and invalidate line by MVA to PoC

DCIMVAC is upgraded to DCCIMVAC for the individual processor that the DCIMVAC
is executed on. Additionally, if the DCIMVAC is executed from a Non-secure
state other than Hyp mode without second state write permissions then the
DCIMVAC is upgraded to DCCIMVAC when broadcast to other processors or
broadcast on the ACE interface.
"
See page 4-9, Table 4-8 c7 register summary (continued).

>
>This driver is not only for i.MX. It runs on PowerPc, too. Do you tested
>this patch on PowerPC architecture, too ? Maybe someone else can do it ?

I do not have Powerpc board to test this patch.

York, do you have such a board or is this patch is ok for powerpc?

>
>> We should follow the linux dma follow. Before DMA read, first
>> invalidate dcache then after DMA read, invalidate dcache again.
>> 
>> With the DMA direction DMA_FROM_DEVICE, the dcache need be
>> invalidated again after the DMA completion. The reason is
>> that we need explicity make sure the dcache been invalidated
>> thus to get the DMA'ed memory correctly from the physical memory.
>> Any cache-line fill during the DMA operations such as the
>> pre-fetching can cause the DMA coherency issue, thus CPU get the stale data.
>> 
>> Signed-off-by: Peng Fan 
>> Signed-off-by: Ye.Li 
>> Signed-off-by: Nitin Garg 
>> Signed-off-by: Jason Liu 
>> ---
>>  drivers/mmc/fsl_esdhc.c | 8 
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
>> index c4719e6..0510bf0 100644
>> --- a/drivers/mmc/fsl_esdhc.c
>> +++ b/drivers/mmc/fsl_esdhc.c
>> @@ -341,6 +341,9 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
>> struct mmc_data *data)
>>  err = esdhc_setup_data(mmc, data);
>>  if(err)
>>  return err;
>> +
>> +if (data->flags & MMC_DATA_READ)
>> +check_and_invalidate_dcache_range(cmd, data);
>>  }
>>  
>>  /* Figure out the transfer arguments */
>> @@ -437,6 +440,11 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
>> struct mmc_data *data)
>>  }
>>  } while ((irqstat & DATA_COMPLETE) != DATA_COMPLETE);
>>  
>> +/*
>> + * Need invalidate the dcache here again to avoid any
>> + * cache-fill during the DMA operations such as the
>> + * speculative pre-fetching etc.
>> + */
>>  if (data->flags & MMC_DATA_READ)
>>  check_and_invalidate_dcache_range(cmd, data);
>>  #endif
>> 
>
>From my side it is ok.
>
>Reviewed-by: Stefano Babic 
>
>Best regards,
>Stefano Babic
>
>
>
>-- 
>=
>DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>=

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

[U-Boot] [PATCH V5 6/6] imx: mx6qpsabreauto: Add MX6QP SABREAUTO CPU3 board support

[Peng Fan]

1. Add DDR script for mx6qpsabreauto board.
2. On CPU3 board, enet RGMII tx clock is from internal PLL. Set the GPR5[9]
   and init the enet pll output to 125Mhz.
3. On CPU3 board, SW1ABC=VDDSOC_IN, SW2=VDDARM_IN.

Build target: mx6qpsabreauto_config

Boot Log:
U-Boot 2015.07-rc2-00071-gfd985ff (Jun 29 2015 - 22:10:55 +0800)

CPU:   Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 34C
Reset cause: POR
Board: MX6Q-Sabreauto revA
I2C:   ready
DRAM:  2 GiB
PMIC:  PFUZE100 ID=0x10
Flash: 32 MiB
NAND:  0 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0

Note:
In this patch, we still add a new config mx6qpsabreauto_config,
since SPL is not supported now, and IMX_CONFIG is needed at
build time, so add this config. Future, when SPL is converted,
this config can be removed.

Signed-off-by: Peng Fan 
Signed-off-by: Robin Gong 
Signed-off-by: Ye.Li 
Reviewed-by: Fabio Estevam 
---

Changes v5:
 none

Changes v4:
 Add Fabio's Reviewed-by

Changes v3:
 1. runtime setting DTB
 2. In this patch, we still add a new config mx6qpsabreauto_config,
since SPL is not supported now, and IMX_CONFIG is needed at
build time, so add this config. All the patches in this patch set
have been reworked with CONFIG_MX6QP removed to align
with runtime check, but this IMX_CONFIG is needed at build time.
Future, when SPL is converted, this config can be removed.

Changes v2:
  1. Remove unused macro in current upstream uboot.
  2. setup_fec, remove non 6qp code. Add comments for gpr setting.
  3. mx6qp.cfg is still same with v1. The settings is from IC and passed
 memory ddr stress test. Since we current have no plan to add SPL,
 so leave settings unchanged.

 board/freescale/mx6qsabreauto/mx6qp.cfg   | 145 ++
 board/freescale/mx6qsabreauto/mx6qsabreauto.c |  33 --
 configs/mx6qpsabreauto_defconfig  |   4 +
 include/configs/mx6sabre_common.h |   2 +
 4 files changed, 177 insertions(+), 7 deletions(-)
 create mode 100644 board/freescale/mx6qsabreauto/mx6qp.cfg
 create mode 100644 configs/mx6qpsabreauto_defconfig

diff --git a/board/freescale/mx6qsabreauto/mx6qp.cfg 
b/board/freescale/mx6qsabreauto/mx6qp.cfg
new file mode 100644
index 000..2298c77
--- /dev/null
+++ b/board/freescale/mx6qsabreauto/mx6qp.cfg
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Refer doc/README.imximage for more details about how-to configure
+ * and create imximage boot image
+ *
+ * The syntax is taken as close as possible with the kwbimage
+ */
+/* image version */
+
+#define __ASSEMBLY__
+#include 
+
+IMAGE_VERSION 2
+
+/*
+ * Boot Device : one of spi, sd, eimnor, nand, sata:
+ * spinor: flash_offset: 0x0400
+ * nand:   flash_offset: 0x0400
+ * sata:   flash_offset: 0x0400
+ * sd/mmc: flash_offset: 0x0400
+ * eimnor: flash_offset: 0x1000
+ */
+BOOT_FROM  sd
+
+/*
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ * Addr-type register length (1,2 or 4 bytes)
+ * Address   absolute address of the register
+ * value value to be stored in the register
+ */
+DATA 4 0x020e0798 0x000C
+DATA 4 0x020e0758 0x
+DATA 4 0x020e0588 0x0030
+DATA 4 0x020e0594 0x0030
+DATA 4 0x020e056c 0x0030
+DATA 4 0x020e0578 0x0030
+DATA 4 0x020e074c 0x0030
+DATA 4 0x020e057c 0x0030
+DATA 4 0x020e058c 0x
+DATA 4 0x020e059c 0x0030
+DATA 4 0x020e05a0 0x0030
+DATA 4 0x020e078c 0x0030
+DATA 4 0x020e0750 0x0002
+DATA 4 0x020e05a8 0x0030
+DATA 4 0x020e05b0 0x0030
+DATA 4 0x020e0524 0x0030
+DATA 4 0x020e051c 0x0030
+DATA 4 0x020e0518 0x0030
+DATA 4 0x020e050c 0x0030
+DATA 4 0x020e05b8 0x0030
+DATA 4 0x020e05c0 0x0030
+DATA 4 0x020e0774 0x0002
+DATA 4 0x020e0784 0x0030
+DATA 4 0x020e0788 0x0030
+DATA 4 0x020e0794 0x0030
+DATA 4 0x020e079c 0x0030
+DATA 4 0x020e07a0 0x0030
+DATA 4 0x020e07a4 0x0030
+DATA 4 0x020e07a8 0x0030
+DATA 4 0x020e0748 0x0030
+DATA 4 0x020e05ac 0x0030
+DATA 4 0x020e05b4 0x0030
+DATA 4 0x020e0528 0x0030
+DATA 4 0x020e0520 0x0030
+DATA 4 0x020e0514 0x0030
+DATA 4 0x020e0510 0x0030
+DATA 4 0x020e05bc 0x0030
+DATA 4 0x020e05c4 0x0030
+DATA 4 0x021b0800 0xa1390003
+DATA 4 0x021b080c 0x001b001e
+DATA 4 0x021b0810 0x002e0029
+DATA 4 0x021b480c 0x001b002a
+DATA 4 0x021b4810 0x0019002c
+DATA 4 0x021b083c 0x43240334
+DATA 4 0x021b0840 0x0324031a
+DATA 4 0x021b483c 0x43340344
+DATA 4 0x021b4840 0x03280276
+DATA 4 0x021b0848 0x44383A3E
+DATA 4 0x021b4848 0x3C3C3846
+DATA 4 0x021b0850 0x2e303230
+DATA 4 0x021b4850 0x38283E34
+DATA 4 

[U-Boot] [PATCH V5 4/6] imx: mx6qp Enable PRG clock for IPU

[Peng Fan]

The i.MX6DQP has a PRG module, need to enable its clock for using IPU.

Signed-off-by: Peng Fan 
Signed-off-by: Brown Oliver 
Signed-off-by: Ye.Li 
Reviewed-by: Fabio Estevam 
Acked-by: Stefano Babic 
---

Changes v5:
 Add Stefano's Acked-by

Changes v4:
 Take Fabio's suggestion, use setbits_le32. Add Fabio's Reviewed-by

Changes v3:
  Remove ipu qos settings

Changes v2:
  1. runtime check
  2. introduce ipu qos settings for better performance

 arch/arm/cpu/armv7/mx6/clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index cd4bfdd..3e94472 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -853,6 +853,11 @@ void enable_ipu_clock(void)
reg = readl(&mxc_ccm->CCGR3);
reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK;
writel(reg, &mxc_ccm->CCGR3);
+
+   if (is_mx6dqp()) {
+   setbits_le32(&mxc_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
+   setbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
+   }
 }
 #endif
 /***/
-- 
1.8.4


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

[U-Boot] [PATCH V5 2/6] imx: mx6: ccm: Change the clock settings for i.MX6QP

[Peng Fan]

Since i.MX6QP changes some CCM registers, so modify the clocks settings to
follow the hardware changes.

In c files, use runtime check and discard #ifdef.

Signed-off-by: Peng Fan 
Signed-off-by: Ye.Li 
Reviewed-by: Fabio Estevam 
Acked-by: Stefano Babic 
---

Changes v5:
 Add Stefano's Acked-by

Changes v4:
 Add Fabio's Reviewed-by

Changes v3:
 Move bit definition to crm_regs.h.

Changes v2:
  1. Remove #ifdef, but use runtime check
  2. A few bit definitions are introduced in c files, because to other platforms
 the macro will make compilation fail, also there are no other places refer
 the bit macro definitions.

 arch/arm/cpu/armv7/mx6/clock.c   | 30 +---
 arch/arm/cpu/armv7/mx6/soc.c |  5 +++-
 arch/arm/include/asm/arch-mx6/crm_regs.h | 48 +---
 3 files changed, 49 insertions(+), 34 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index b461898..cd4bfdd 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -310,10 +310,12 @@ static u32 get_ipg_per_clk(void)
u32 reg, perclk_podf;
 
reg = __raw_readl(&imx_ccm->cscmr1);
-#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
-   if (reg & MXC_CCM_CSCMR1_PER_CLK_SEL_MASK)
-   return MXC_HCLK; /* OSC 24Mhz */
-#endif
+   if (is_cpu_type(MXC_CPU_MX6SL) || is_cpu_type(MXC_CPU_MX6SX) ||
+   is_mx6dqp()) {
+   if (reg & MXC_CCM_CSCMR1_PER_CLK_SEL_MASK)
+   return MXC_HCLK; /* OSC 24Mhz */
+   }
+
perclk_podf = reg & MXC_CCM_CSCMR1_PERCLK_PODF_MASK;
 
return get_ipg_clk() / (perclk_podf + 1);
@@ -324,10 +326,13 @@ static u32 get_uart_clk(void)
u32 reg, uart_podf;
u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
reg = __raw_readl(&imx_ccm->cscdr1);
-#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
-   if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
-   freq = MXC_HCLK;
-#endif
+
+   if (is_cpu_type(MXC_CPU_MX6SL) || is_cpu_type(MXC_CPU_MX6SX) ||
+   is_mx6dqp()) {
+   if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
+   freq = MXC_HCLK;
+   }
+
reg &= MXC_CCM_CSCDR1_UART_CLK_PODF_MASK;
uart_podf = reg >> MXC_CCM_CSCDR1_UART_CLK_PODF_OFFSET;
 
@@ -339,8 +344,13 @@ static u32 get_cspi_clk(void)
u32 reg, cspi_podf;
 
reg = __raw_readl(&imx_ccm->cscdr2);
-   reg &= MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK;
-   cspi_podf = reg >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
+   cspi_podf = (reg & MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK) >>
+MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
+
+   if (is_mx6dqp()) {
+   if (reg & MXC_CCM_CSCDR2_ECSPI_CLK_SEL_MASK)
+   return MXC_HCLK / (cspi_podf + 1);
+   }
 
return  decode_pll(PLL_USBOTG, MXC_HCLK) / (8 * (cspi_podf + 1));
 }
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index d3a3b2e..e80c09c 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -342,9 +342,12 @@ static void set_ahb_rate(u32 val)
 static void clear_mmdc_ch_mask(void)
 {
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+   u32 reg;
+   reg = readl(&mxc_ccm->ccdr);
 
/* Clear MMDC channel mask */
-   writel(0, &mxc_ccm->ccdr);
+   reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
+   writel(reg, &mxc_ccm->ccdr);
 }
 
 static void init_bandgap(void)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 98415ac..7d9fe73 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -123,6 +123,8 @@ struct mxc_ccm_reg {
 /* Define the bits in register CCDR */
 #define MXC_CCM_CCDR_MMDC_CH1_HS_MASK  (1 << 16)
 #define MXC_CCM_CCDR_MMDC_CH0_HS_MASK  (1 << 17)
+/* Exists on i.MX6QP */
+#define MXC_CCM_CCDR_MMDC_CH1_AXI_ROOT_CG  (1 << 18)
 
 /* Define the bits in register CSR */
 #define MXC_CCM_CSR_COSC_READY (1 << 5)
@@ -195,10 +197,8 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CBCMR_GPU3D_SHADER_CLK_SEL_OFFSET  8
 #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_MASK  (0x3 << 4)
 #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_OFFSET4
-#ifndef CONFIG_MX6SX
-#define MXC_CCM_CBCMR_GPU3D_AXI_CLK_SEL(1 << 1)
-#define MXC_CCM_CBCMR_GPU2D_AXI_CLK_SEL(1 << 0)
-#endif
+/* Exists on i.MX6QP */
+#define MXC_CCM_CBCMR_PRE_CLK_SEL  (1 << 1)
 
 /* Define the bits in register CSCMR1 */
 #define MXC_CCM_CSCMR1_ACLK_EMI_SLOW_MASK  (0x3 << 29)
@@ -229,10 +229,10 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CSCMR1_QSPI1_CLK_SEL_MASK  (0x7 << 7)
 #define MXC_CCM_CSCMR1_QSPI1_CLK_SEL_OFFS

[U-Boot] [PATCH V5 5/6] imx: mx6sabresd/sabreauto runtime setting fdt_file

[Peng Fan]

Detect the SOC and board variant at runtime and change the dtb name,
but not hardcoding the fdt_file env variable.

Take the following patch as a reference.
Íd58699b157df75f1aa0b363ea9c21add21a0c
"mx6cuboxi: Load the correct 'fdtfile' variable"

Signed-off-by: Peng Fan 
Reviewed-by: Fabio Estevam 
Acked-by: Stefano Babic 
---

Changes v5:
 Add Stefano's Acked-by
Changes v4:
 Add Fabio's Reviewed-by
Changes v3:
 New patch
Changes v2:
 none

 board/freescale/mx6qsabreauto/mx6qsabreauto.c |  9 +
 board/freescale/mx6sabresd/mx6sabresd.c   | 10 ++
 include/configs/mx6qsabreauto.h   |  5 -
 include/configs/mx6sabre_common.h | 21 +++--
 include/configs/mx6sabresd.h  |  5 -
 5 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index b76e4eb..943a4bd 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -522,6 +522,15 @@ int board_late_init(void)
add_board_boot_modes(board_boot_modes);
 #endif
 
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   setenv("board_name", "SABREAUTO");
+
+   if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
+   setenv("board_rev", "MX6Q");
+   else if (is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO))
+   setenv("board_rev", "MX6DL");
+#endif
+
return 0;
 }
 
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 23f8f6b..4f0694a 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -679,6 +679,16 @@ int board_late_init(void)
 #ifdef CONFIG_CMD_BMODE
add_board_boot_modes(board_boot_modes);
 #endif
+
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   setenv("board_name", "SABRESD");
+
+   if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
+   setenv("board_rev", "MX6Q");
+   else if (is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO))
+   setenv("board_rev", "MX6DL");
+#endif
+
return 0;
 }
 
diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
index 2260344..11cf538 100644
--- a/include/configs/mx6qsabreauto.h
+++ b/include/configs/mx6qsabreauto.h
@@ -12,11 +12,6 @@
 #define CONFIG_MACH_TYPE   3529
 #define CONFIG_MXC_UART_BASE   UART4_BASE
 #define CONFIG_CONSOLE_DEV "ttymxc3"
-#if defined CONFIG_MX6Q
-#define CONFIG_DEFAULT_FDT_FILE"imx6q-sabreauto.dtb"
-#elif defined CONFIG_MX6DL
-#define CONFIG_DEFAULT_FDT_FILE"imx6dl-sabreauto.dtb"
-#endif
 #define CONFIG_MMCROOT "/dev/mmcblk0p2"
 #define PHYS_SDRAM_SIZE(2u * 1024 * 1024 * 1024)
 
diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index e42dfc9..903ab18 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -70,10 +70,12 @@
 #define EMMC_ENV ""
 #endif
 
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
-   "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
+   "fdt_file=undefined\0" \
"fdt_addr=0x1800\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
@@ -143,9 +145,24 @@
"fi; " \
"else " \
"bootz; " \
-   "fi;\0"
+   "fi;\0" \
+   "findfdt="\
+   "if test $fdt_file = undefined; then " \
+   "if test $board_name = SABREAUTO && test 
$board_rev = MX6Q; then " \
+   "setenv fdt_file imx6q-sabreauto.dtb; 
fi; " \
+   "if test $board_name = SABREAUTO && test 
$board_rev = MX6DL; then " \
+   "setenv fdt_file imx6dl-sabreauto.dtb; 
fi; " \
+   "if test $board_name = SABRESD && test 
$board_rev = MX6Q; then " \
+   "setenv fdt_file imx6q-sabresd.dtb; fi; 
" \
+   "if test $board_name = SABRESD && test 
$board_rev = MX6DL; then " \
+   "setenv fdt_file imx6dl-sabresd.dtb; 
fi; " \
+   "if test $fdt_file = undefined; then " \
+   "echo WARNING: Could not determine dtb 
to use; fi; " \
+   "fi;\0" \
+
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt;" \
"mmc dev ${mmcdev};" \
"if mmc rescan; then " \
"if run loadbootscript; then " \
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 41162ca..5f635ca 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -19,11 +19,6

[U-Boot] [PATCH V5 1/6] imx: add cpu type for i.MX6QP/DP

[Peng Fan]

Add cpu type for i.MX6QP/DP.

This patch also fix is_mx6dqp(), since get_cpu_rev can return MXC_CPU_MX6QP
and MXC_CPU_MX6DP, we should use:
(is_cpu_type(MXC_CPU_MX6QP) || is_cpu_type(MXC_CPU_MX6DP)).

Signed-off-by: Peng Fan 
Acked-by: Stefano Babic 
---

Changes v5:
 Refine commit msg
 Add Stefano's Acked-by

Changes v4:
 Address Fabio's comments, Change Quad-Plus to Dual-Plus for i.MX6DP.

Changes v3:
 New patch
 This patch is to make print_cpuinfo display correct cpu info,and fix is_mx6dqp

Changes v2:
 none

 arch/arm/cpu/armv7/mx6/soc.c  | 11 +--
 arch/arm/imx-common/cpu.c |  4 
 arch/arm/include/asm/arch-imx/cpu.h   |  2 ++
 arch/arm/include/asm/arch-mx6/sys_proto.h |  4 +---
 4 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 29de624..d3a3b2e 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -62,12 +62,12 @@ u32 get_cpu_rev(void)
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
u32 reg = readl(&anatop->digprog_sololite);
u32 type = ((reg >> 16) & 0xff);
-   u32 major;
+   u32 major, cfg = 0;
 
if (type != MXC_CPU_MX6SL) {
reg = readl(&anatop->digprog);
struct scu_regs *scu = (struct scu_regs *)SCU_BASE_ADDR;
-   u32 cfg = readl(&scu->config) & 3;
+   cfg = readl(&scu->config) & 3;
type = ((reg >> 16) & 0xff);
if (type == MXC_CPU_MX6DL) {
if (!cfg)
@@ -81,6 +81,13 @@ u32 get_cpu_rev(void)
 
}
major = ((reg >> 8) & 0xff);
+   if ((major >= 1) &&
+   ((type == MXC_CPU_MX6Q) || (type == MXC_CPU_MX6D))) {
+   major--;
+   type = MXC_CPU_MX6QP;
+   if (cfg == 1)
+   type = MXC_CPU_MX6DP;
+   }
reg &= 0xff;/* mx6 silicon revision */
return (type << 12) | (reg + (0x10 * (major + 1)));
 }
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 5e56cfe..096d22e 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -122,6 +122,10 @@ unsigned imx_ddr_size(void)
 const char *get_imx_type(u32 imxtype)
 {
switch (imxtype) {
+   case MXC_CPU_MX6QP:
+   return "6QP";   /* Quad-Plus version of the mx6 */
+   case MXC_CPU_MX6DP:
+   return "6DP";   /* Dual-Plus version of the mx6 */
case MXC_CPU_MX6Q:
return "6Q";/* Quad-core version of the mx6 */
case MXC_CPU_MX6D:
diff --git a/arch/arm/include/asm/arch-imx/cpu.h 
b/arch/arm/include/asm/arch-imx/cpu.h
index 4715f4e..99e0e32 100644
--- a/arch/arm/include/asm/arch-imx/cpu.h
+++ b/arch/arm/include/asm/arch-imx/cpu.h
@@ -12,6 +12,8 @@
 #define MXC_CPU_MX6Q   0x63
 #define MXC_CPU_MX6D   0x64
 #define MXC_CPU_MX6SOLO0x65 /* dummy ID */
+#define MXC_CPU_MX6DP  0x68
+#define MXC_CPU_MX6QP  0x69
 
 #define CS0_1280
 #define CS0_64M_CS1_64M1
diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 28c77a4..eee8ca8 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -30,9 +30,7 @@ const char *get_imx_type(u32 imxtype);
 unsigned imx_ddr_size(void);
 void set_chipselect_size(int const);
 
-#define is_mx6dqp() ((is_cpu_type(MXC_CPU_MX6Q) || \
-is_cpu_type(MXC_CPU_MX6D)) && \
-(soc_rev() >= CHIP_REV_2_0))
+#define is_mx6dqp() (is_cpu_type(MXC_CPU_MX6QP) || is_cpu_type(MXC_CPU_MX6DP))
 
 /*
  * Initializes on-chip ethernet controllers.
-- 
1.8.4


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

[U-Boot] [PATCH V5 3/6] imx: mx6: hab : Remove the cache issue workaroud in hab for i.MX6QP

[Peng Fan]

From: "Ye.Li" 

Since the i.MX6QP has fixed the issue in boot ROM, so remove the workaround
for i.MX6QP.

Signed-off-by: Ye.Li 
Signed-off-by: Peng Fan 
Acked-by: Stefano Babic 
---

Changes v5:
 Add Stefano's Acked-by
Changes v4:
 none
Changes v3:
 none
Changes v2:
 none

 arch/arm/cpu/armv7/mx6/hab.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
index 87f422d..27cabe4 100644
--- a/arch/arm/cpu/armv7/mx6/hab.c
+++ b/arch/arm/cpu/armv7/mx6/hab.c
@@ -423,7 +423,8 @@ uint32_t authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
 * do cache flushes. don't think any
 * exist, so we ignore them.
 */
-   writel(1, MX6DQ_PU_IROM_MMU_EN_VAR);
+   if (!is_mx6dqp())
+   writel(1, 
MX6DQ_PU_IROM_MMU_EN_VAR);
} else if (is_cpu_type(MXC_CPU_MX6DL) ||
   is_cpu_type(MXC_CPU_MX6SOLO)) {
writel(1, MX6DLS_PU_IROM_MMU_EN_VAR);
-- 
1.8.4


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

[U-Boot] possible string overflow issue.

[Joya Cruz, Alejandro]

I was running a static code analysis.
And found a possible string overflow, this occurs in common/cli_simple.c  line 
278
It  might overrun the 512 byte destination string lastcommand by writing 513 
bytes from console_buffer
Hopefully someone could be able to review with more knowledge in this code.

Regards,

Alejandro Fco Joya Cruz
Intel Guadalajara Design Center
Phone: +52 33 1645 4987
Email: alejandro.joya.c...@intel.com

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

Re: [U-Boot] [PATCH v2 05/11] x86: Setup fixed range MTRRs for legacy regions

[Bin Meng]

Hi Simon,

On Sat, Jul 11, 2015 at 12:09 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 10 July 2015 at 09:39, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Fri, Jul 10, 2015 at 8:55 PM, Simon Glass  wrote:
>>> Hi Bin,
>>>
>>> On 6 July 2015 at 02:31, Bin Meng  wrote:
 We should setup fixed range MTRRs for some legacy regions like VGA
 RAM and PCI ROM areas as uncacheable. Note FSP may setup these to
 other cache settings, but we can override this in x86_cpu_init_f().

 Signed-off-by: Bin Meng 
 Acked-by: Simon Glass 
 ---

 Changes in v2: None

  arch/x86/cpu/cpu.c  | 22 ++
  arch/x86/include/asm/mtrr.h | 27 ---
  2 files changed, 38 insertions(+), 11 deletions(-)

 diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
 index d108ee5..9afdafb 100644
 --- a/arch/x86/cpu/cpu.c
 +++ b/arch/x86/cpu/cpu.c
 @@ -28,6 +28,8 @@
  #include 
  #include 
  #include 
 +#include 
 +#include 
  #include 
  #include 
  #include 
 @@ -352,6 +354,26 @@ int x86_cpu_init_f(void)
 gd->arch.has_mtrr = has_mtrr();
 }

 +   /* Configure fixed range MTRRs for some legacy regions */
 +   if (gd->arch.has_mtrr) {
 +   u64 mtrr_cap;
 +
 +   mtrr_cap = native_read_msr(MTRR_CAP_MSR);
 +   if (mtrr_cap & MTRR_CAP_FIX) {
 +   /* Mark the VGA RAM area as uncacheable */
 +   native_write_msr(MTRR_FIX_16K_A_MSR, 0, 0);
 +
 +   /* Mark the PCI ROM area as uncacheable */
 +   native_write_msr(MTRR_FIX_4K_C_MSR, 0, 0);
 +   native_write_msr(MTRR_FIX_4K_C8000_MSR, 0, 0);
 +   native_write_msr(MTRR_FIX_4K_D_MSR, 0, 0);
 +   native_write_msr(MTRR_FIX_4K_D8000_MSR, 0, 0);
>>>
>>> I just noticed that setting this up makes the Minnowmax ROM execution
>>> go really slowly. Do we need to turn off the cache? It goes from <1s
>>> to >4s.
>>
>> Oops, that's bad. I guess we should turn on the cache for the rom
>> execution then. BTW I found the tunnelcreek vbios changed the Cseg
>> MTRR to write-through itself.
>
> OK - can you try to do a patch for that? But first, why do we need to
> make the area uncacheable?
>

Yep, I can prepare a patch. I was referring to several chipset
datasheet before, which mentions the suggested MTRR settings to UC,
but this seems wrong.

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

Re: [U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format

[Simon Glass]

On 10 July 2015 at 10:18, Sudeep Holla  wrote:
>
> Commit 90fbee3e4051 ("cmd_fdt: Actually fix fdt command in sandbox")
> changed the format(from hex address to unsigned long) in which "fdtaddr"
> is saved . However do_fdt continues reads the "fdtaddr" assuming it to
> be in hex format. This may lead to fdt being either loaded or attempted
> to load at erroneous address generating fault if the address is out of
> memory.
>
> This patch changes back the format to hex while saving the "fdtaddr"
> as it was done before.
>
> Signed-off-by: Sudeep Holla 
> Cc: Linus Walleij 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Hua Yanghao 
> Cc: Heiko Schocher 
> ---
>  common/cmd_fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reposting this time with my signoff as it turns out I can legally do so.
>

Great!

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

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

[Tom Rini]

On Fri, Jul 10, 2015 at 12:59:38PM +, Luka Perkov wrote:

> Hi Tom,
> 
> can you please pull this 10 patches from Stefan?
> 
> The following changes since commit f3edfd30541d6f245d7dfa6fa7354cc916cc53e1:
> 
>   net: designware: Program MAC address to hardware after soft reset 
> (2015-07-08 13:43:19 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-marvell.git 
> 
> for you to fetch changes up to 59565736839108846d8dfa6782babfaefff6b58b:
> 
>   arm: mvebu: db-88f6820-gp: Add USB/EHCI support (2015-07-10 14:56:07 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] please pull u-boot-samsung master

[Tom Rini]

On Fri, Jul 10, 2015 at 09:16:28PM +0900, Minkyu Kang wrote:

> Dear Tom,
> 
> The following changes since commit f3edfd30541d6f245d7dfa6fa7354cc916cc53e1:
> 
>   net: designware: Program MAC address to hardware after soft reset 
> (2015-07-08 13:43:19 -0400)
> 
> are available in the git repository at:
> 
>   http://git.denx.de/u-boot-samsung 
> 
> for you to fetch changes up to 8fd3ec770c41115b95ca80f0f0ba344ac59dc293:
> 
>   exynos: i2c: Correct bug in pinmux selection (2015-07-10 21:13:48 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] mtd: fix false positive "Offset exceeds device limit" error

[Tom Rini]

On Wed, Jul 01, 2015 at 09:35:49PM +0900, Masahiro Yamada wrote:

> Since commit 09c3280754f8 (mtd, nand: Move common functions from
> cmd_nand.c to common place), NAND commands would not work at all
> on large devices.
> 
> => nand read 8000 1 1
> 
> NAND read: Offset exceeds device limit
> => nand erase 10 10
> 
> NAND erase: Offset exceeds device limit
> 
> The type of the "size" of "struct mtd_info" is uint64_t, while
> mtd_arg_off_size() and mtd_arg_off() treat chipsize as int type.
> The chipsize is wrapped around if the argument is given with 2GB
> or larger.
> 
> Acked-by: Heiko Schocher 
> Acked-by: Scott Wood 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 5/6] ARM64: hikey: hi6220: Add u-boot support for the 96boards CE HiKey board.

[Rob Herring]

On Wed, Jul 8, 2015 at 10:57 AM, Peter Griffin  wrote:
> HiKey is the first 96boards consumer edition compliant board. It features a 
> hi6220
> SoC which has eight ARM A53 cpu's.
>
> This initial port adds support for: -
> 1) Serial
> 2) eMMC / sd card

s/sd/SD/

> 3) USB
> 4) GPIO
>
> It has been tested with Arm Trusted Firmware running u-boot as the BL33 
> executable.
>
> Notes:
>
> eMMC has been tested with basic reading of eMMC partition intto DDR. I have 
> not

s/intto/into/

> tested writing / erasing. Due to lack of clock control it won't be
> running in the most performant high speed mode.
>
> SD card slot has been tested for reading and booting kernels into DDR.
> It is also currently used for saving the u-boot enviroment.

s/enviroment/environment/

> USB has been tested with ASIX networking adapter to tftpboot kernels
> into DDR. On v2015.07-rc2 dhcp now works, and also usb mass storage

s/usb/USB/

> is enumerated correctly.
>
> GPIO has been tested using gpio toggle GPIO4_1-3 to flash LEDs.
>
> Basic SoC datasheet can be found here: -
> https://github.com/96boards/documentation/blob/master/hikey/
> Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf
>
> Board schematic can be found here: -
> https://github.com/96boards/documentation/blob/master/hikey/
> 96Boards-Hikey-Rev-A1.pdf
>
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/Kconfig   |   8 +
>  board/hisilicon/hikey/Kconfig  |  15 ++
>  board/hisilicon/hikey/Makefile |   8 +
>  board/hisilicon/hikey/hikey.c  | 415 
> +
>  configs/hikey_defconfig|   5 +
>  include/configs/hikey.h| 168 +
>  6 files changed, 619 insertions(+)
>  create mode 100644 board/hisilicon/hikey/Kconfig
>  create mode 100644 board/hisilicon/hikey/Makefile
>  create mode 100644 board/hisilicon/hikey/hikey.c
>  create mode 100644 configs/hikey_defconfig
>  create mode 100644 include/configs/hikey.h

[...]

> +
> +int misc_init_r(void)
> +{
> +   init_usb_and_picophy();

Can board_usb_init or usb_lowlevel_init be used here?

> +
> +   return 0;
> +}
> +
> +int board_init(void)
> +{
> +   gd->flags = 0;
> +
> +   icache_enable();

The enable_caches call in board_r.c should do this for you.

> +
> +   return 0;
> +}
> +
> +#ifdef CONFIG_GENERIC_MMC
> +
> +static int init_dwmmc(void)
> +{
> +   int ret;
> +
> +#ifdef CONFIG_DWMMC
> +   /* mmc0 pinmux and clocks are already configured by ATF */
> +   ret = hi6220_dwmci_add_port(0, HI6220_MMC0_BASE, 8);
> +
> +   if (ret)
> +   printf("%s: Error adding eMMC port\n", __func__);
> +
> +   /* take mmc1 (sd slot) out of reset, configure clocks and pinmuxing */
> +
> +   mmc1_init_pll();
> +   mmc1_reset_clk();
> +   mmc1_setup_pinmux();
> +
> +   ret |= hi6220_dwmci_add_port(1, HI6220_MMC1_BASE, 4);
> +
> +   if (ret)
> +   printf("%s: Error adding SD port\n", __func__);
> +#endif
> +   return ret;
> +}
> +
> +int board_mmc_init(bd_t *bis)
> +{
> +   int ret;
> +
> +   /* init the pmussi ip */
> +   hi6220_pmussi_init();
> +
> +   /* init the hi6553 pmic */
> +   hikey_hi6553_init();
> +
> +   /* add the eMMC and sd ports */
> +   ret = init_dwmmc();
> +
> +   if (ret)
> +   debug("init_dwmmc failed\n");
> +
> +   return ret;
> +}
> +#endif
> +
> +int dram_init(void)
> +{
> +   gd->ram_size = PHYS_SDRAM_1_SIZE;
> +   return 0;
> +}
> +
> +void dram_init_banksize(void)
> +{
> +   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> +   gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> +}
> +
> +/* Use the Watchdog to cause reset */
> +void reset_cpu(ulong addr)
> +{
> +   /* TODO program the watchdog */
> +}
> diff --git a/configs/hikey_defconfig b/configs/hikey_defconfig
> new file mode 100644
> index 000..50baf22
> --- /dev/null
> +++ b/configs/hikey_defconfig
> @@ -0,0 +1,5 @@
> +# 96boards HiKey
> +CONFIG_ARM=y
> +CONFIG_TARGET_HIKEY=y
> +CONFIG_SHOW_BOOT_PROGRESS=y
> +CONFIG_NET=y
> diff --git a/include/configs/hikey.h b/include/configs/hikey.h
> new file mode 100644
> index 000..303b857
> --- /dev/null
> +++ b/include/configs/hikey.h
> @@ -0,0 +1,168 @@
> +/*
> + * (C) Copyright 2015 Linaro
> + *
> + * Peter Griffin 
> + *
> + * Configuration for HiKey 96boards CE. Parts were derived from other ARM
> + * configurations.
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef __HIKEY_AEMV8A_H
> +#define __HIKEY_AEMV8A_H

Drop the AEMV8A.

> +
> +/* We use generic board for hikey */
> +#define CONFIG_SYS_GENERIC_BOARD
> +
> +#define CONFIG_REMAKE_ELF
> +
> +#define CONFIG_SUPPORT_RAW_INITRD
> +
> +/* Cache Definitions */
> +#define CONFIG_SYS_DCACHE_OFF
> +
> +#define CONFIG_IDENT_STRING"hikey"
> +
> +/* Flat Device Tree Definitions */
> +#define CONFIG_OF_LIBFDT
> +
> +/* Physical Memory Map */
> +
> +/* CONFIG_SYS_TEXT_BASE needs to align with whe

[U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format

[Sudeep Holla]

Commit 90fbee3e4051 ("cmd_fdt: Actually fix fdt command in sandbox")
changed the format(from hex address to unsigned long) in which "fdtaddr"
is saved . However do_fdt continues reads the "fdtaddr" assuming it to
be in hex format. This may lead to fdt being either loaded or attempted
to load at erroneous address generating fault if the address is out of
memory.

This patch changes back the format to hex while saving the "fdtaddr"
as it was done before.

Signed-off-by: Sudeep Holla 
Cc: Linus Walleij 
Cc: Tom Rini 
Cc: Simon Glass 
Cc: Hua Yanghao 
Cc: Heiko Schocher 
---
 common/cmd_fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Reposting this time with my signoff as it turns out I can legally do so.

diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 682b6553958f..4c18962d8532 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -45,7 +45,7 @@ void set_working_fdt_addr(ulong addr)
 
buf = map_sysmem(addr, 0);
working_fdt = buf;
-   setenv_ulong("fdtaddr", addr);
+   setenv_hex("fdtaddr", addr);
 }
 
 /*
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Simon,

On 07/10 06:53, Simon Glass wrote:
> Hi,
> 
> On 8 July 2015 at 05:30, Andrew Bradford  wrote:
> > Hi Bin,
> >
> > On 07/08 11:18, Bin Meng wrote:
> >> Hi Andrew,
> >>
> >> On Wed, Jul 8, 2015 at 3:16 AM,   wrote:
> >> > From: Andrew Bradford 
> >> >
> >> > Allow for configuration of FSP UPD from the device tree which will
> >> > override any settings which the FSP was built with itself if the device
> >> > tree settings exist, otherwise simply trust the FSP's defaults.
> >> >
> >> > Modifies the MinnowMax board to transfer the FSP UPD hard-coded settings
> >> > to the MinnowMax dts.
> >> >
> >> > Signed-off-by: Andrew Bradford 
> >> > ---
> >> >
> >> > Changes from v1:
> >> >
> >> > - Use "-" rather than "_" in dt property names.
> >> > - Use "Bay Trail" for the formal name of the Intel product family.
> >> > - Use an "fsp," prefix for dt property names for clarity.
> >> > - Fix minor code indentation issues.
> >> > - Create a dt subnode for the memory-down-params.
> >> > - Clarify documentation that dt overrides the FSP's config, so we don't
> >> >   use booleans.
> >> >
> >> >  arch/x86/cpu/baytrail/fsp_configs.c| 188 
> >> > +
> >> >  arch/x86/dts/minnowmax.dts |  30 
> >> >  .../misc/intel,baytrail-fsp.txt| 119 +
> >> >  include/fdtdec.h   |   2 +
> >> >  lib/fdtdec.c   |   2 +
> >> >  5 files changed, 311 insertions(+), 30 deletions(-)
> >> >  create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
> >> >
> >> > diff --git a/arch/x86/cpu/baytrail/fsp_configs.c 
> >> > b/arch/x86/cpu/baytrail/fsp_configs.c
> >> > index 86b6926..fce76e6 100644
> >> > --- a/arch/x86/cpu/baytrail/fsp_configs.c
> >> > +++ b/arch/x86/cpu/baytrail/fsp_configs.c
> >> > @@ -1,14 +1,18 @@
> >> >  /*
> >> >   * Copyright (C) 2013, Intel Corporation
> >> >   * Copyright (C) 2014, Bin Meng 
> >> > + * Copyright (C) 2015, Kodak Alaris, Inc
> >> >   *
> >> >   * SPDX-License-Identifier:Intel
> >> >   */
> >> >
> >> >  #include 
> >> > +#include 
> >> >  #include 
> >> >  #include 
> >> >
> >> > +DECLARE_GLOBAL_DATA_PTR;
> >> > +
> >> >  /* ALC262 Verb Table - 10EC0262 */
> >> >  static const uint32_t verb_table_data13[] = {
> >> > /* Pin Complex (NID 0x11) */
> >> > @@ -116,41 +120,165 @@ const struct pch_azalia_config azalia_config = {
> >> > .reset_wait_timer_us = 300
> >> >  };
> >> >
> >> > +/**
> >> > + * Update the FSP's UPD.  The FSP itself can be configured for defaults 
> >> > to
> >> > + * store in UPD through Intel's GUI configurator but likely a specific 
> >> > board
> >> > + * will want to update these from u-boot, so allow for that via device 
> >> > tree.
> >> > + * If the device tree does not specify a setting, trust the FSP's 
> >> > default.
> >> > + */
> >> >  void update_fsp_upd(struct upd_region *fsp_upd)
> >> >  {
> >> > struct memory_down_data *mem;
> >> > +   const void *blob = gd->fdt_blob;
> >> > +   int node;
> >> >
> >> > -   /*
> >> > -* Configure everything here to avoid the poor hard-pressed user
> >> > -* needing to run Intel's binary configuration tool. It may also 
> >> > allow
> >> > -* us to support the 1GB single core variant easily.
> >> > -*
> >> > -* TODO(s...@chromium.org): Move to device tree
> >> > -*/
> >> > -   fsp_upd->mrc_init_tseg_size = 8;
> >> > -   fsp_upd->mrc_init_mmio_size = 0x800;
> >> > -   fsp_upd->emmc_boot_mode = 0xff;
> >> > -   fsp_upd->enable_sdio = 1;
> >> > -   fsp_upd->enable_sdcard = 1;
> >> > -   fsp_upd->enable_hsuart0 = 1;
> >> > fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
> >> > -   fsp_upd->enable_i2_c0 = 0;
> >> > -   fsp_upd->enable_i2_c2 = 0;
> >> > -   fsp_upd->enable_i2_c3 = 0;
> >> > -   fsp_upd->enable_i2_c4 = 0;
> >> > -   fsp_upd->enable_xhci = 0;
> >> > -   fsp_upd->igd_render_standby = 1;
> >> > +
> >> > +   node = fdtdec_next_compatible(blob, 0, 
> >> > COMPAT_INTEL_BAYTRAIL_FSP);
> >> > +   if (node < 0) {
> >> > +   debug("%s: Cannot find FSP node\n", __func__);
> >> > +   return;
> >> > +   }
> >> > +
> >> > +   fsp_upd->mrc_init_tseg_size = fdtdec_get_int(blob, node,
> >> > +
> >> > "fsp,mrc-int-tseg-size",
> >>
> >> mrc-int? Guess it is mrc-init.
> >
> > Yes, thank you for catching this.  Will fix in v3.
> >
> >> > +
> >> > fsp_upd->mrc_init_tseg_size);
> >> > +   fsp_upd->mrc_init_mmio_size = fdtdec_get_int(blob, node,
> >> > +
> >> > "fsp,mrc-init-mmio-size",
> >> > +
> >> > fsp_upd->mrc_init_mmio_size);
> >> > +   fsp_upd->mrc_init_spd_addr1 = fdtdec_

Re: [U-Boot] [PATCH v2 05/11] x86: Setup fixed range MTRRs for legacy regions

[Simon Glass]

Hi Bin,

On 10 July 2015 at 09:39, Bin Meng  wrote:
> Hi Simon,
>
> On Fri, Jul 10, 2015 at 8:55 PM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 6 July 2015 at 02:31, Bin Meng  wrote:
>>> We should setup fixed range MTRRs for some legacy regions like VGA
>>> RAM and PCI ROM areas as uncacheable. Note FSP may setup these to
>>> other cache settings, but we can override this in x86_cpu_init_f().
>>>
>>> Signed-off-by: Bin Meng 
>>> Acked-by: Simon Glass 
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>  arch/x86/cpu/cpu.c  | 22 ++
>>>  arch/x86/include/asm/mtrr.h | 27 ---
>>>  2 files changed, 38 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
>>> index d108ee5..9afdafb 100644
>>> --- a/arch/x86/cpu/cpu.c
>>> +++ b/arch/x86/cpu/cpu.c
>>> @@ -28,6 +28,8 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -352,6 +354,26 @@ int x86_cpu_init_f(void)
>>> gd->arch.has_mtrr = has_mtrr();
>>> }
>>>
>>> +   /* Configure fixed range MTRRs for some legacy regions */
>>> +   if (gd->arch.has_mtrr) {
>>> +   u64 mtrr_cap;
>>> +
>>> +   mtrr_cap = native_read_msr(MTRR_CAP_MSR);
>>> +   if (mtrr_cap & MTRR_CAP_FIX) {
>>> +   /* Mark the VGA RAM area as uncacheable */
>>> +   native_write_msr(MTRR_FIX_16K_A_MSR, 0, 0);
>>> +
>>> +   /* Mark the PCI ROM area as uncacheable */
>>> +   native_write_msr(MTRR_FIX_4K_C_MSR, 0, 0);
>>> +   native_write_msr(MTRR_FIX_4K_C8000_MSR, 0, 0);
>>> +   native_write_msr(MTRR_FIX_4K_D_MSR, 0, 0);
>>> +   native_write_msr(MTRR_FIX_4K_D8000_MSR, 0, 0);
>>
>> I just noticed that setting this up makes the Minnowmax ROM execution
>> go really slowly. Do we need to turn off the cache? It goes from <1s
>> to >4s.
>
> Oops, that's bad. I guess we should turn on the cache for the rom
> execution then. BTW I found the tunnelcreek vbios changed the Cseg
> MTRR to write-through itself.

OK - can you try to do a patch for that? But first, why do we need to
make the area uncacheable?

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

Re: [U-Boot] [PATCH v3 00/25] dm: Introduce Rockchip RK3288 support

[Simon Glass]

Hi,

On 10 July 2015 at 02:24, Sjoerd Simons  wrote:
> On Tue, 2015-06-23 at 17:28 -0600, Simon Glass wrote:
>>
>> Since much of the code is generic, this also supports the Radxa Rock
>> Pro.
>
> Just to be sure as I happen to have a Rock Pro on the way which will
> want some u-boot love. Do you actually mean the Rock Pro which is
> RK3188 based rather then Rock2 which is an RK3288 based SOM ?

Sorry, it should be Rock 2. It is RK3288-based.

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

Re: [U-Boot] [PATCH] Tegra: PLL: fix per-SoC pllinfo table regression

[Stephen Warren]

On 07/10/2015 09:36 AM, Marcel Ziswiler wrote:

From: Marcel Ziswiler 

The following commit introduced per-SoC pllinfo tables but
unfortunately there were two generic issues (e.g. mask vs. shift mixed
up and wrongly used parenthesis) plus two each masks being wrong in
the pllinfo tables for T20/T30 which this patch fixes.

commit aeea4204b340afe063ea38c36a0a60ce33015e7d
Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.


Where's that patch? I don't believe any patch with that subject has been 
posted to the lists.



Tested both on Colibri T20 as well as Colibri T30.

Signed-off-by: Marcel Ziswiler 
---
Please note that this patch applies to the next branch of the
u-boot-tegra custodian tree.


Oh right. It looks like Tom accidentally pushed his local WIP patches to 
the Tegra maintainer tree. I'd suggest ignoring those patches for now.

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

Re: [U-Boot] [Patch 2/3] Revert "e1000: fix sw fw sync on igb i210/i211"

[Tim Harvey]

On Wed, May 20, 2015 at 8:00 AM, Tim Harvey  wrote:
> On Wed, May 20, 2015 at 7:14 AM, Marcel Ziswiler  wrote:
>> On Wed, 2015-05-20 at 06:15 -0700, Tim Harvey wrote:
>> 
>>> > Tested on Apalis T30 1GB V1.1A with properly fused i211
>>> > Tested on Apalis T30 2GB V1.1A with iNVM fused i210
>>> > Tested on Apalis T30 1GB V1.0A with tools only aka non fused i211
>>> > Tested-by: Marcel Ziswiler 
>>> > ---
>>> > BTW: Still fails on Apalis T30 2GB V1.0E with tools only aka non fused
>>> > i210 as follows:
>>> > e1000: e1000#0: ERROR: Hardware Initialization Failed
>>> > In our downstream production U-Boot we temporarily hacked this as
>>> > follows for now:
>>> > http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex&id=2d8ea651b6da79047b6fa729863d25b5eb9e15d7
>>>
>>> I don't understand your results above. What I'm most interested in is
>>> if this patch series (adding the proper semaphore release and removing
>>> your patch that uses the wrong register for i210) resolves the need
>>> for you having added this particular patch for whatever board you
>>> needed it for. Is the configuration that was failing for you requiring
>>> 17da7120249bfdef877f46be5bbcb3cc01212eb9 resolved with this series
>>> applied?
>>
>> Yes, exactly.
>
> ok - thats great news
>
>>
>>> When you say it 'still fails on Apalis T30 2GB V1.0E' does that mean
>>> you have that particular failure both before and after this patch
>>> series? That would indicate to me there is something more needed
>>> specifically for that configuration.
>>
>> Yes, exactly. As once mentioned before Intel actually claims tools only
>> mode anyway not being operational at all on the other hand the Linux
>> driver worked just fine for us with each and every such combination.
>> Unfortunately so far I did not get to tracking this any further.
>
> It does make sense to me that an 'unprogrammed' device would work just
> fine as long as the programmed device-id's were supported by the
> driver (which they are) and the default mode matches your
> configuration. All 'programmed' means on an i210/i211 is that you've
> added some register writes to 'override' power-on defaults. As long as
> the power-on defaults work for your config then your ok. The default
> power-on config for i210/i211 is internal phy copper which is what you
> have.
>
> Tim

Marcel,

Could you give an 'acked-by' if you agree with this series? I would
like to see it merged:

https://patchwork.ozlabs.org/patch/473997/
https://patchwork.ozlabs.org/patch/473998/
https://patchwork.ozlabs.org/patch/473996/

Regards,

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

Re: [U-Boot] [PATCH v2 05/11] x86: Setup fixed range MTRRs for legacy regions

[Bin Meng]

Hi Simon,

On Fri, Jul 10, 2015 at 8:55 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 6 July 2015 at 02:31, Bin Meng  wrote:
>> We should setup fixed range MTRRs for some legacy regions like VGA
>> RAM and PCI ROM areas as uncacheable. Note FSP may setup these to
>> other cache settings, but we can override this in x86_cpu_init_f().
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/cpu.c  | 22 ++
>>  arch/x86/include/asm/mtrr.h | 27 ---
>>  2 files changed, 38 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
>> index d108ee5..9afdafb 100644
>> --- a/arch/x86/cpu/cpu.c
>> +++ b/arch/x86/cpu/cpu.c
>> @@ -28,6 +28,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -352,6 +354,26 @@ int x86_cpu_init_f(void)
>> gd->arch.has_mtrr = has_mtrr();
>> }
>>
>> +   /* Configure fixed range MTRRs for some legacy regions */
>> +   if (gd->arch.has_mtrr) {
>> +   u64 mtrr_cap;
>> +
>> +   mtrr_cap = native_read_msr(MTRR_CAP_MSR);
>> +   if (mtrr_cap & MTRR_CAP_FIX) {
>> +   /* Mark the VGA RAM area as uncacheable */
>> +   native_write_msr(MTRR_FIX_16K_A_MSR, 0, 0);
>> +
>> +   /* Mark the PCI ROM area as uncacheable */
>> +   native_write_msr(MTRR_FIX_4K_C_MSR, 0, 0);
>> +   native_write_msr(MTRR_FIX_4K_C8000_MSR, 0, 0);
>> +   native_write_msr(MTRR_FIX_4K_D_MSR, 0, 0);
>> +   native_write_msr(MTRR_FIX_4K_D8000_MSR, 0, 0);
>
> I just noticed that setting this up makes the Minnowmax ROM execution
> go really slowly. Do we need to turn off the cache? It goes from <1s
> to >4s.

Oops, that's bad. I guess we should turn on the cache for the rom
execution then. BTW I found the tunnelcreek vbios changed the Cseg
MTRR to write-through itself.

>
>> +
>> +   /* Enable the fixed range MTRRs */
>> +   msr_setbits_64(MTRR_DEF_TYPE_MSR, 
>> MTRR_DEF_TYPE_FIX_EN);
>> +   }
>> +   }
>> +
>> return 0;
>>  }
>>

[snip]

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

[U-Boot] [PATCH] Tegra: PLL: fix per-SoC pllinfo table regression

[Marcel Ziswiler]

From: Marcel Ziswiler 

The following commit introduced per-SoC pllinfo tables but
unfortunately there were two generic issues (e.g. mask vs. shift mixed
up and wrongly used parenthesis) plus two each masks being wrong in
the pllinfo tables for T20/T30 which this patch fixes.

commit aeea4204b340afe063ea38c36a0a60ce33015e7d
Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.

Tested both on Colibri T20 as well as Colibri T30.

Signed-off-by: Marcel Ziswiler 
---
Please note that this patch applies to the next branch of the
u-boot-tegra custodian tree.

 arch/arm/mach-tegra/clock.c | 4 ++--
 arch/arm/mach-tegra/tegra20/clock.c | 4 ++--
 arch/arm/mach-tegra/tegra30/clock.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-tegra/clock.c b/arch/arm/mach-tegra/clock.c
index 0c5ae83..6f4dcc6 100644
--- a/arch/arm/mach-tegra/clock.c
+++ b/arch/arm/mach-tegra/clock.c
@@ -474,7 +474,7 @@ unsigned clock_get_rate(enum clock_id clkid)
 * PLLU uses p_mask/p_shift for VCO on all but T210,
 * T210 uses normal DIVP. Handled in pllinfo table.
 */
-   divm <<= (base >> pllinfo->p_mask) & pllinfo->p_shift;
+   divm <<= (base >> pllinfo->p_shift) & pllinfo->p_mask;
do_div(rate, divm);
return rate;
 }
@@ -535,7 +535,7 @@ int clock_set_rate(enum clock_id clkid, u32 n, u32 m, u32 
p, u32 cpcon)
 
/* Set cpcon (KCP) to PLL_MISC */
misc_reg = readl(&pll->pll_misc);
-   misc_reg &= ~(pllinfo->kcp_mask) << pllinfo->kcp_shift;
+   misc_reg &= ~(pllinfo->kcp_mask << pllinfo->kcp_shift);
misc_reg |= cpcon << pllinfo->kcp_shift;
writel(misc_reg, &pll->pll_misc);
 
diff --git a/arch/arm/mach-tegra/tegra20/clock.c 
b/arch/arm/mach-tegra/tegra20/clock.c
index 0de5365..41e19a6 100644
--- a/arch/arm/mach-tegra/tegra20/clock.c
+++ b/arch/arm/mach-tegra/tegra20/clock.c
@@ -366,9 +366,9 @@ struct clk_pll_info 
tegra_pll_info_table[CLOCK_ID_PLL_COUNT] = {
 *   If lock_ena or lock_det are >31, they're not used in that PLL.
 */
 
-   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0xFF,  .p_shift 
= 20, .p_mask = 0x0F,
+   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0x3FF, .p_shift 
= 20, .p_mask = 0x0F,
  .lock_ena = 24, .lock_det = 27, .kcp_shift = 28, .kcp_mask = 3, 
.kvco_shift = 27, .kvco_mask = 1 },   /* PLLC */
-   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0xFF,  .p_shift 
= 0,  .p_mask = 0,
+   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0x3FF, .p_shift 
= 0,  .p_mask = 0,
  .lock_ena = 0,  .lock_det = 27, .kcp_shift = 1, .kcp_mask = 3, 
.kvco_shift = 0, .kvco_mask = 1 }, /* PLLM */
{ .m_shift = 0, .m_mask = 0x1F, .n_shift = 8, .n_mask = 0x3FF, .p_shift 
= 20, .p_mask = 0x07,
  .lock_ena = 18, .lock_det = 27, .kcp_shift = 8, .kcp_mask = 0xF, 
.kvco_shift = 4, .kvco_mask = 0xF }, /* PLLP */
diff --git a/arch/arm/mach-tegra/tegra30/clock.c 
b/arch/arm/mach-tegra/tegra30/clock.c
index 23496b0..3710a50 100644
--- a/arch/arm/mach-tegra/tegra30/clock.c
+++ b/arch/arm/mach-tegra/tegra30/clock.c
@@ -415,9 +415,9 @@ struct clk_pll_info 
tegra_pll_info_table[CLOCK_ID_PLL_COUNT] = {
 *   If lock_ena or lock_det are >31, they're not used in that PLL.
 */
 
-   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0xFF,  .p_shift 
= 20, .p_mask = 0x0F,
+   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0x3FF, .p_shift 
= 20, .p_mask = 0x0F,
  .lock_ena = 24, .lock_det = 27, .kcp_shift = 28, .kcp_mask = 3, 
.kvco_shift = 27, .kvco_mask = 1 },   /* PLLC */
-   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0xFF,  .p_shift 
= 0,  .p_mask = 0,
+   { .m_shift = 0, .m_mask = 0xFF, .n_shift = 8, .n_mask = 0x3FF, .p_shift 
= 0,  .p_mask = 0,
  .lock_ena = 0,  .lock_det = 27, .kcp_shift = 1, .kcp_mask = 3, 
.kvco_shift = 0, .kvco_mask = 1 }, /* PLLM */
{ .m_shift = 0, .m_mask = 0x1F, .n_shift = 8, .n_mask = 0x3FF, .p_shift 
= 20, .p_mask = 0x07,
  .lock_ena = 18, .lock_det = 27, .kcp_shift = 8, .kcp_mask = 0xF, 
.kvco_shift = 4, .kvco_mask = 0xF }, /* PLLP */
-- 
1.9.3

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

Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Bin Liu]

Hi,

On 07/10/2015 10:12 AM, Heiko Schocher wrote:

Hello Samuel,

Am 10.07.2015 um 16:50 schrieb Egli, Samuel:

Hi Hans,


-Original Message- From: Hans de Goede
[mailto:hdego...@redhat.com] Sent: Freitag, 10. Juli 2015 16:37
To: Egli, Samuel; ma...@denx.de Cc: u-boot@lists.denx.de;
tr...@konsulko.com; Bin Liu; Meier, Roger; Daniel Mack Subject:
Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

Hi,

On 10-07-15 16:30, Hans de Goede wrote:

Hi,

On 10-07-15 15:16, Samuel Egli wrote:

From: Bin Liu 

Do not config MUSB to highspeed mode if
CONFIG_USB_GADGET_DUALSPEED is not set, in which case Ether
gadget only operates in fullspeed.

Note: This patch is necessary for devices like some siemens
boards that allow only FULL SPEED USB 1.1, e.g. DFU
download.

Signed-off-by: Bin Liu  Reviewed-by: Tom Rini
 Tested-by: Samuel Egli
 CC: Marek Vasut  CC:
Heiko Schocher  CC: Daniel Mack
 CC: Roger Meier 


Nack this breaks highspeed mode on boards which use the musb in
host mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.


My bad, I had a short thought about this when I was initially working on
this patch, but did not really think about it throughly. Thanks for
bring it up.



p.s.

Given that you want to use this as a hack to work around the
broken pcb design of your board I suggest adding a new option for
this


Well, lets not discuss the "broken" pcb design. It seems that
wiring protection is not that common. Unfortunately, such a
protection is too expensive for USB High speed :-(.


Agreed, we have seen many cases that have nothing to do with hardware
design, but MUSB has to work in full-speed mode.




titled: CONFIG_USB_MUSB_NO_HIGHSPEED and then do:

+#ifndef CONFIG_USB_MUSB_NO_HIGHSPEED | MUSB_POWER_HSENAB
+#endif


This would be good enough. The point is indeed to limit it to full
speed.


Using CONFIG_USB_GADGET_DUALSPEED for this seems wrong, since
this has nothing to do with enabling dualspeed mode for the
gadget code really.


I agree that the name is confusing.


Yes, I vote for Hans suggestion.


*Adding* a new macro CONFIG_USB_MUSB_NO_HIGHSPEED for musb driver causes
CONFIG_USB_GADGET_DUALSPEED redundant, because both control for full-speed.

I suggest to *rename* CONFIG_USB_GADGET_DUALSPEED to
CONFIG_USB_FULLSPEED_ONLY. So that we can use one macro for both gadget
and musb drivers. Considering supper-speed exists and future, I think
CONFIG_USB_NO_HIGHSPEED is confusing...

Regards,
-Bin.



bye, Heiko

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

Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Heiko Schocher]

Hello Samuel,

Am 10.07.2015 um 16:50 schrieb Egli, Samuel:

Hi Hans,


-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: Freitag, 10. Juli 2015 16:37
To: Egli, Samuel; ma...@denx.de
Cc: u-boot@lists.denx.de; tr...@konsulko.com; Bin Liu; Meier, Roger;
Daniel Mack
Subject: Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

Hi,

On 10-07-15 16:30, Hans de Goede wrote:

Hi,

On 10-07-15 15:16, Samuel Egli wrote:

From: Bin Liu 

Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
is not set, in which case Ether gadget only operates in fullspeed.

Note:
This patch is necessary for devices like some siemens boards that
allow only FULL SPEED USB 1.1, e.g. DFU download.

Signed-off-by: Bin Liu 
Reviewed-by: Tom Rini 
Tested-by: Samuel Egli 
CC: Marek Vasut 
CC: Heiko Schocher 
CC: Daniel Mack 
CC: Roger Meier 


Nack this breaks highspeed mode on boards which use the musb in host
mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.


p.s.

Given that you want to use this as a hack to work around the broken pcb
design of your board I suggest adding a new option for this


Well, lets not discuss the "broken" pcb design. It seems that wiring protection
is not that common. Unfortunately, such a protection is too expensive for
USB High speed :-(.


titled: CONFIG_USB_MUSB_NO_HIGHSPEED and then do:

+#ifndef CONFIG_USB_MUSB_NO_HIGHSPEED
| MUSB_POWER_HSENAB
+#endif


This would be good enough. The point is indeed to limit it to full speed.


Using CONFIG_USB_GADGET_DUALSPEED for this seems wrong, since this has
nothing to do with enabling dualspeed mode for the gadget code really.


I agree that the name is confusing.


Yes, I vote for Hans suggestion.

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

Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Egli, Samuel]

Hi Hans,

>-Original Message-
>From: Hans de Goede [mailto:hdego...@redhat.com]
>Sent: Freitag, 10. Juli 2015 16:37
>To: Egli, Samuel; ma...@denx.de
>Cc: u-boot@lists.denx.de; tr...@konsulko.com; Bin Liu; Meier, Roger;
>Daniel Mack
>Subject: Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG
>
>Hi,
>
>On 10-07-15 16:30, Hans de Goede wrote:
>> Hi,
>>
>> On 10-07-15 15:16, Samuel Egli wrote:
>>> From: Bin Liu 
>>>
>>> Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
>>> is not set, in which case Ether gadget only operates in fullspeed.
>>>
>>> Note:
>>> This patch is necessary for devices like some siemens boards that
>>> allow only FULL SPEED USB 1.1, e.g. DFU download.
>>>
>>> Signed-off-by: Bin Liu 
>>> Reviewed-by: Tom Rini 
>>> Tested-by: Samuel Egli 
>>> CC: Marek Vasut 
>>> CC: Heiko Schocher 
>>> CC: Daniel Mack 
>>> CC: Roger Meier 
>>
>> Nack this breaks highspeed mode on boards which use the musb in host
>> mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.
>
>p.s.
>
>Given that you want to use this as a hack to work around the broken pcb
>design of your board I suggest adding a new option for this

Well, lets not discuss the "broken" pcb design. It seems that wiring protection
is not that common. Unfortunately, such a protection is too expensive for 
USB High speed :-(.

>titled: CONFIG_USB_MUSB_NO_HIGHSPEED and then do:
>
>+#ifndef CONFIG_USB_MUSB_NO_HIGHSPEED
>| MUSB_POWER_HSENAB
>+#endif
>
This would be good enough. The point is indeed to limit it to full speed.

>Using CONFIG_USB_GADGET_DUALSPEED for this seems wrong, since this has
>nothing to do with enabling dualspeed mode for the gadget code really.

I agree that the name is confusing. 

Kind regards

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

Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Hans de Goede]

Hi,

On 10-07-15 16:30, Hans de Goede wrote:

Hi,

On 10-07-15 15:16, Samuel Egli wrote:

From: Bin Liu 

Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
is not set, in which case Ether gadget only operates in fullspeed.

Note:
This patch is necessary for devices like some siemens boards
that allow only FULL SPEED USB 1.1, e.g. DFU download.

Signed-off-by: Bin Liu 
Reviewed-by: Tom Rini 
Tested-by: Samuel Egli 
CC: Marek Vasut 
CC: Heiko Schocher 
CC: Daniel Mack 
CC: Roger Meier 


Nack this breaks highspeed mode on boards which use the musb
in host mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.


p.s.

Given that you want to use this as a hack to work around the broken
pcb design of your board I suggest adding a new option for this
titled: CONFIG_USB_MUSB_NO_HIGHSPEED and then do:

+#ifndef CONFIG_USB_MUSB_NO_HIGHSPEED
   | MUSB_POWER_HSENAB
+#endif

Using CONFIG_USB_GADGET_DUALSPEED for this seems wrong, since this
has nothing to do with enabling dualspeed mode for the gadget code
really.

Regards,

Hans




Regards,

Hans



---
  drivers/usb/musb-new/musb_core.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index 242cc30..4edd6d7 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -942,7 +942,9 @@ void musb_start(struct musb *musb)

  /* put into basic highspeed mode and start session */
  musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
+#ifdef CONFIG_USB_GADGET_DUALSPEED
  | MUSB_POWER_HSENAB
+#endif
  /* ENSUSPEND wedges tusb */
  /* | MUSB_POWER_ENSUSPEND */
  );
--
1.7.10.4

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


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

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

Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Hans de Goede]

Hi,

On 10-07-15 15:16, Samuel Egli wrote:

From: Bin Liu 

Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
is not set, in which case Ether gadget only operates in fullspeed.

Note:
This patch is necessary for devices like some siemens boards
that allow only FULL SPEED USB 1.1, e.g. DFU download.

Signed-off-by: Bin Liu 
Reviewed-by: Tom Rini 
Tested-by: Samuel Egli 
CC: Marek Vasut 
CC: Heiko Schocher 
CC: Daniel Mack 
CC: Roger Meier 


Nack this breaks highspeed mode on boards which use the musb
in host mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.

Regards,

Hans



---
  drivers/usb/musb-new/musb_core.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index 242cc30..4edd6d7 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -942,7 +942,9 @@ void musb_start(struct musb *musb)

/* put into basic highspeed mode and start session */
musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
+#ifdef CONFIG_USB_GADGET_DUALSPEED
| MUSB_POWER_HSENAB
+#endif
/* ENSUSPEND wedges tusb */
/* | MUSB_POWER_ENSUSPEND */
);
--
1.7.10.4

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


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

[U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Samuel Egli]

From: Bin Liu 

Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
is not set, in which case Ether gadget only operates in fullspeed.

Note:
This patch is necessary for devices like some siemens boards
that allow only FULL SPEED USB 1.1, e.g. DFU download.

Signed-off-by: Bin Liu 
Reviewed-by: Tom Rini 
Tested-by: Samuel Egli 
CC: Marek Vasut 
CC: Heiko Schocher 
CC: Daniel Mack 
CC: Roger Meier 
---
 drivers/usb/musb-new/musb_core.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index 242cc30..4edd6d7 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -942,7 +942,9 @@ void musb_start(struct musb *musb)

/* put into basic highspeed mode and start session */
musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
+#ifdef CONFIG_USB_GADGET_DUALSPEED
| MUSB_POWER_HSENAB
+#endif
/* ENSUSPEND wedges tusb */
/* | MUSB_POWER_ENSUSPEND */
);
--
1.7.10.4

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

[U-Boot] (no subject)

[Samuel Egli]

Hi all,

this is a re-submission of Bin Liu's patch that was 
reverted by the commit 16b61d13bab361853564da401b15fc34ae1dfea7
from Daniel Mack.

It is not OK to set the MUSB_POWER_HSENAB unconditionally because
there are sometimes some HW limitations that allow only FULL SPEED.

In our case  we have some bad wiring protection in our USB circuit
that acts as a filter an will not allow signals to pass that
are faster than FULL SPEED.

I suggest to use CONFIG_USB_GADGET_DUALSPEED define to enable 
HIGH SPEED as it was done previously, which is by default 
enabled. 

Kind regards

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

[U-Boot] Please pull u-boot-marvell master

[Luka Perkov]

Hi Tom,

can you please pull this 10 patches from Stefan?

The following changes since commit f3edfd30541d6f245d7dfa6fa7354cc916cc53e1:

  net: designware: Program MAC address to hardware after soft reset (2015-07-08 
13:43:19 -0400)

are available in the git repository at:

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

for you to fetch changes up to 59565736839108846d8dfa6782babfaefff6b58b:

  arm: mvebu: db-88f6820-gp: Add USB/EHCI support (2015-07-10 14:56:07 +0200)


Stefan Roese (10):
  arm: mvebu: db-88f6820-gp: Add MAINTAINERS file
  mmc: sdhci: Use timer based timeout detection in sdhci_send_command()
  mmc: sdhci.c: Add config option to use a fixed buffer for transfers
  arm: mvebu: Add SDIO/SDHCI support for Armada A38x
  arm: mvebu: db-88f6820-gp: Add MMC/SDIO support
  block: ahci: Don't enable port interrupts
  arm: mvebu: Add SATA/SCSI (AHCI) support for Armada A38x
  arm: mvebu: db-88f6820-gp.h: Add SATA/SCSI (AHCI) support
  usb: Add EHCI support for Armada 38x (mvebu)
  arm: mvebu: db-88f6820-gp: Add USB/EHCI support

 arch/arm/mach-mvebu/cpu.c   | 66 +
 arch/arm/mach-mvebu/include/mach/cpu.h  |  2 +
 arch/arm/mach-mvebu/include/mach/gpio.h | 10 +
 arch/arm/mach-mvebu/include/mach/soc.h  |  3 ++
 board/Marvell/db-88f6820-gp/MAINTAINERS |  6 +++
 drivers/block/ahci.c|  3 --
 drivers/mmc/sdhci.c | 25 ++---
 drivers/usb/host/ehci-marvell.c | 36 ++
 include/configs/db-88f6820-gp.h | 41 
 9 files changed, 184 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/mach-mvebu/include/mach/gpio.h
 create mode 100644 board/Marvell/db-88f6820-gp/MAINTAINERS

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

Re: [U-Boot] [PATCH V4 1/6] imx: add dummpy cpu type MXC_CPU_MX6QP/DP

[Stefano Babic]

Hi Peng,

On 10/07/2015 10:06, Peng Fan wrote:

>> Anyway, why is it dummy ? It matches a real SOC, only the check is done
>> in another way.
> 
> Just like MXC_CPU_MX6Q and MXC_CPU_MX6D. MXC_CPU_MX6D is a dummy id,
> MXC_CPU_MX6Q is the real id. Same MXC_CPU_MX6QP/DP are also dummy id.

ok, that is what you meant, understood. It is only that value is not
exactly what we read from DIGIPROG register. The title and commit
message let me think that "the cpu type " is dummy, that is it does not
exist, while the CPU-ID is only built with a formula instead of getting
the value from the register.

IMHO it was enough you simply say "add CPU type for 6QP/DP", dropping
the first part of the commit message that is misleading.


> Since I want to print correct CPU info, so I use this way, but not
> change arch/arm/imx-common/cpu.c.

This is ok, agree.


>> Everything fine, but I have not understood this line, please help me.
>> major is the revision number and should be at least 2 for a QP or DP.
>> But you check that it can be >=, that is revision 1.x is accepted as
>> Plus. Or am I wrong ?
> 
> To i.MX6, MAJOR_LOWER is from 0,1,2... maybe larger.
> I have no knowledge whether major_lower with 2,3,4... is also called DQPlus.
> 6QP/DP is major_lower >= 1, major_lower 0 is for 6DQ.

ok, thanks - this is clear now.

> Now ">= 1" can work
> for 6QP/DP, just check "== 1" may not a good idea.
> 
> Is this clear to explain why this patch?

yes, it is ok. I was missing that even major_lower = 1 is a Plus. Fine
with me.

> 
> The reason for this patch is to print correct cpuinfo:
> 
> printf("CPU:   Freescale i.MX%s rev%d.%d",
>  get_imx_type((cpurev & 0xFF000) >> 12),
>  (cpurev & 0x000F0) >> 4,
>  (cpurev & 0xF) >> 0);
> 
> As Fabio's comments, should print i.MX6QP 1.0, but i.MX6Q rev2.0.

ok

Apart interpretation of the commit message, patch is ok for me.

Acked-by: Stefano Babic 

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, u-boot, 2/2] ARM: beagle_x15: prevent DCAN1 _wait_target_disable failure in kernel

[Tom Rini]

On Thu, Jun 25, 2015 at 10:25:50AM +0300, Roger Quadros wrote:

> If board is booted with transitions happening on DCAN1 pins then
> the following warning is seen in the kernel at boot when the
> hwmod layer initializes.
> 
> "omap_hwmod: dcan1: _wait_target_disable failed"
> 
> This is because DCAN1 module's SWAKEUP mechanism is broken
> and it fails to correctly turn OFF if it sees a transition on the
> DCAN1 pins. Suggested workaround is to keep DCAN1 pins in safe mode
> while enabling/disabling DCAN1 module.
> 
> The hwmod layer enables and disables all modules at boot
> and we have no opportunity to put the DCAN1 pins in safe mode
> at that point.
> 
> DCAN1 is not used by u-boot so it doesn't matter to it if these
> pins are in safe mode. The kernel driver correctly configures
> the right mode when DCAN1 is active.
> 
> Signed-off-by: Roger Quadros 

With %s/PULLUP/PULL_UP/ based on the DRA7xx patch, applied to
u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,3/3] arm: baltos: fix NAND boot

[Tom Rini]

On Mon, Jul 06, 2015 at 05:28:36PM +0200, Yegor Yefremov wrote:

> Specify proper U-Boot offset, enable prefetch mode,
> increase bootm size and add FIT fallback, if board_name
> is not present in kernel-fit.itb image.
> 
> Signed-off-by: Yegor Yefremov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] README.distro: fix typos

[Tom Rini]

On Tue, Jul 07, 2015 at 06:47:17PM +0900, Masahiro Yamada wrote:

> The word "partition" is doubled.  Keep decent forms for the
> following lines.
> 
> Also, fix some other typos while we are here.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,2/3] arm: baltos: drop I2C speed to 1000 Hz

[Tom Rini]

On Mon, Jul 06, 2015 at 05:28:35PM +0200, Yegor Yefremov wrote:

> This action is need to make I2C communication with PMIC
> stable for low temperature. Print current I2C speed in
> SPL for visual control.
> 
> Signed-off-by: Yegor Yefremov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] stm32f4: fix gpio description in comment

[Tom Rini]

On Wed, Jul 01, 2015 at 04:04:14PM +0800, Antonio Borneo wrote:

> On STM32F429 gpio PC6/PC7 can be allocated for USART6, as
> reported in the comment.
> But current code in
>   drivers/serial/serial_stm32.c
> uses a different gpio mapping (PG14/PG9) for USART6.
> 
> Fix the comment to match current code in the driver.
> 
> Signed-off-by: Antonio Borneo 
> To: u-boot@lists.denx.de
> To: Kamil Lulko 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2] siemens,am33x: adjust mtd partition

[Tom Rini]

On Wed, Jul 01, 2015 at 05:57:39PM +0200, Egli, Samuel wrote:

> Use one mtd partition for rootfs and configuration by
> means of ubi volumes and get rid of configuration partition.
> We can use partition layout for both 256MB and 512MB flash.
> 
> Signed-off-by: Samuel Egli 
> Cc: Heiko Schocher 
> Cc: Roger Meier 
> Reviewed-by: Tom Rini 
> Acked-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/3] arm: baltos: enable CMD_NET and FIT support in defconfig

[Tom Rini]

On Mon, Jul 06, 2015 at 05:28:34PM +0200, Yegor Yefremov wrote:

> Signed-off-by: Yegor Yefremov 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,2/2] stm32f4: fix minor typo in comment

[Tom Rini]

On Wed, Jul 01, 2015 at 02:15:03PM +0800, Antonio Borneo wrote:

> Signed-off-by: Antonio Borneo 
> To: u-boot@lists.denx.de
> To: Kamil Lulko 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2] Makefile:Add GCC flag -fno-delete-null-pointer-checks

[Tom Rini]

On Thu, Jul 02, 2015 at 12:00:17PM +0530, Prabhakar Kushwaha wrote:

> -fdelete-null-pointer-checks flag controls global dataflow analyses and
> eliminate useless checks for null pointers; It assume that if a pointer is
> checked after it has already been dereferenced, it cannot be null.
> This flag is enabled by default.
> 
> gcc v4.9 has more optimizations added to this option. Hence it is very
> aggressive with GCC v4.9 series. Add -fno-delete-null-pointer-checks to
> disable the optimization
> 
> Signed-off-by: Rohit Dharmakan 
> Signed-off-by: Prabhakar Kushwaha 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] arm: convert am3517_crane and am3517_evm to generic boards

[Tom Rini]

On Tue, Jun 30, 2015 at 09:59:47AM +0200, Yegor Yefremov wrote:

> From: Yegor Yefremov 
> 
> Add CONFIG_SYS_GENERIC_BOARD to board's config header.
> 
> Boot-tested on am3517_evm board.
> 
> Signed-off-by: Yegor Yefremov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] ti: Add SPDX license identifier to omap.h

[Tom Rini]

On Tue, Jun 30, 2015 at 04:03:02PM -0600, Simon Glass wrote:

> This also came from Linux - according to this thread it has a GPL v2
> license like arch/arm/mach-omap2/mux.h:
> 
> http://lists.denx.de/pipermail/u-boot/2015-June/217827.html
> 
> Signed-off-by: Simon Glass 
> Reported-by: Ingrid Viitanen 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/2] stm32f4: fix MAINTAINERS file

[Tom Rini]

On Wed, Jul 01, 2015 at 02:15:02PM +0800, Antonio Borneo wrote:

> When "scripts/get_maintainer.pl" parses "board/.../MAINTAINERS",
> it uses the line containing board name as delimiter.
> Without this line, the script happily mixes the lines from current
> board MAINTAINERS file with lines from another file.
> 
> Fix it by adding a reasonable board name.
> 
> Tested by comparing output of:
>   cat board/st/stm32f429-discovery/MAINTAINERS
>   ./scripts/get_maintainer.pl -f board/st/stm32f429-discovery
> 
> Signed-off-by: Antonio Borneo 
> To: u-boot@lists.denx.de
> To: Kamil Lulko 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, u-boot] ARM: DRA7-evm: prevent DCAN1 _wait_target_disable failure in kernel

[Tom Rini]

On Wed, Jun 24, 2015 at 05:00:11PM +0300, Roger Quadros wrote:

> If board is booted with transitions happening on DCAN1 pins then
> the following warning is seen in the kernel at boot when the
> hwmod layer initializes.
> 
> "omap_hwmod: dcan1: _wait_target_disable failed"
> 
> This is because DCAN1 module's SWAKEUP mechanism is broken
> and it fails to correctly turn OFF if it sees a transition on the
> DCAN1 pins. Suggested workaround is to keep DCAN1 pins in safe mode
> while enabling/disabling DCAN1 module.
> 
> The hwmod layer enables and disables all modules at boot
> and we have no opportunity to put the DCAN1 pins in safe mode
> at that point.
> 
> DCAN1 is not used by u-boot so it doesn't matter to it if these
> pins are in safe mode. The kernel driver correctly configures
> the right mode when DCAN1 is active.
> 
> Signed-off-by: Roger Quadros 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2] keystone2: config: update default mtd

[Tom Rini]

On Fri, Jun 26, 2015 at 09:17:31AM -0500, Michael Scherban wrote:

> Because it is possible for the MTD number to change, causing a
> filesystem mount failure, we should use the volume name instead
> of the MTD number and let Linux resolve the correct one.
> 
> Signed-off-by: Mike Scherban 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 05/11] x86: Setup fixed range MTRRs for legacy regions

[Simon Glass]

Hi Bin,

On 6 July 2015 at 02:31, Bin Meng  wrote:
> We should setup fixed range MTRRs for some legacy regions like VGA
> RAM and PCI ROM areas as uncacheable. Note FSP may setup these to
> other cache settings, but we can override this in x86_cpu_init_f().
>
> Signed-off-by: Bin Meng 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/cpu.c  | 22 ++
>  arch/x86/include/asm/mtrr.h | 27 ---
>  2 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> index d108ee5..9afdafb 100644
> --- a/arch/x86/cpu/cpu.c
> +++ b/arch/x86/cpu/cpu.c
> @@ -28,6 +28,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -352,6 +354,26 @@ int x86_cpu_init_f(void)
> gd->arch.has_mtrr = has_mtrr();
> }
>
> +   /* Configure fixed range MTRRs for some legacy regions */
> +   if (gd->arch.has_mtrr) {
> +   u64 mtrr_cap;
> +
> +   mtrr_cap = native_read_msr(MTRR_CAP_MSR);
> +   if (mtrr_cap & MTRR_CAP_FIX) {
> +   /* Mark the VGA RAM area as uncacheable */
> +   native_write_msr(MTRR_FIX_16K_A_MSR, 0, 0);
> +
> +   /* Mark the PCI ROM area as uncacheable */
> +   native_write_msr(MTRR_FIX_4K_C_MSR, 0, 0);
> +   native_write_msr(MTRR_FIX_4K_C8000_MSR, 0, 0);
> +   native_write_msr(MTRR_FIX_4K_D_MSR, 0, 0);
> +   native_write_msr(MTRR_FIX_4K_D8000_MSR, 0, 0);

I just noticed that setting this up makes the Minnowmax ROM execution
go really slowly. Do we need to turn off the cache? It goes from <1s
to >4s.

> +
> +   /* Enable the fixed range MTRRs */
> +   msr_setbits_64(MTRR_DEF_TYPE_MSR, 
> MTRR_DEF_TYPE_FIX_EN);
> +   }
> +   }
> +
> return 0;
>  }
>
> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
> index 3ad617c..70762ee 100644
> --- a/arch/x86/include/asm/mtrr.h
> +++ b/arch/x86/include/asm/mtrr.h
> @@ -21,6 +21,11 @@
>  #define MTRR_CAP_MSR   0x0fe
>  #define MTRR_DEF_TYPE_MSR  0x2ff
>
> +#define MTRR_CAP_SMRR  (1 << 11)
> +#define MTRR_CAP_WC(1 << 10)
> +#define MTRR_CAP_FIX   (1 << 8)
> +#define MTRR_CAP_VCNT_MASK 0xff
> +
>  #define MTRR_DEF_TYPE_EN   (1 << 11)
>  #define MTRR_DEF_TYPE_FIX_EN   (1 << 10)
>
> @@ -38,17 +43,17 @@
>  #define RANGES_PER_FIXED_MTRR  8
>  #define NUM_FIXED_RANGES   (NUM_FIXED_MTRRS * RANGES_PER_FIXED_MTRR)
>
> -#define MTRR_FIX_64K_0_MSR 0x250
> -#define MTRR_FIX_16K_8_MSR 0x258
> -#define MTRR_FIX_16K_A_MSR 0x259
> -#define MTRR_FIX_4K_C_MSR 0x268
> -#define MTRR_FIX_4K_C8000_MSR 0x269
> -#define MTRR_FIX_4K_D_MSR 0x26a
> -#define MTRR_FIX_4K_D8000_MSR 0x26b
> -#define MTRR_FIX_4K_E_MSR 0x26c
> -#define MTRR_FIX_4K_E8000_MSR 0x26d
> -#define MTRR_FIX_4K_F_MSR 0x26e
> -#define MTRR_FIX_4K_F8000_MSR 0x26f
> +#define MTRR_FIX_64K_0_MSR 0x250
> +#define MTRR_FIX_16K_8_MSR 0x258
> +#define MTRR_FIX_16K_A_MSR 0x259
> +#define MTRR_FIX_4K_C_MSR  0x268
> +#define MTRR_FIX_4K_C8000_MSR  0x269
> +#define MTRR_FIX_4K_D_MSR  0x26a
> +#define MTRR_FIX_4K_D8000_MSR  0x26b
> +#define MTRR_FIX_4K_E_MSR  0x26c
> +#define MTRR_FIX_4K_E8000_MSR  0x26d
> +#define MTRR_FIX_4K_F_MSR  0x26e
> +#define MTRR_FIX_4K_F8000_MSR  0x26f
>
>  #if !defined(__ASSEMBLER__)
>
> --
> 1.8.2.1
>

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

Re: [U-Boot] [U-Boot, 2/2] blackfin: Fix build regression due to image size

[Tom Rini]

On Mon, Jun 22, 2015 at 05:57:37PM -0500, Joe Hershberger wrote:

> bf533-stamp, bf538f-ezkit, and cm-bf548 are very space limited.
> 
> This was introduced by:
> 6e0d26c0502e (net: Handle ethaddr changes as an env callback)
> by enabling CONFIG_REGEX, which is too big for these boards.
> 
> This patch disables CONFIG_REGEX at the expense of working with more
> than the first ethaddr.
> 
> Signed-off-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] Allow CONFIG_REGEX to be disabled when CONFIG_NET

[Tom Rini]

On Mon, Jun 22, 2015 at 05:57:36PM -0500, Joe Hershberger wrote:

> Instead of selecting REGEX when NET is enabled, make it the default, but
> allow boards that are tiny to disable it and lose functionality on all
> but the first Ethernet adapter.
> 
> cm-bf548, bf538f-ezkit, and bf533-stamp need this. None appear to have
> more than one Ethernet interface.
> 
> Signed-off-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] arm: baltos: change USB ports functions

[Tom Rini]

On Thu, Jul 09, 2015 at 01:34:24PM +0200, Yegor Yefremov wrote:

> Baltos has USB0 connected to a USB hub and thus is host-only. USB1
> is connected to microUSB connector and thus should use OTG mode.
> 
> Signed-off-by: Yegor Yefremov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3] ahci: Fix compiling warnings under 64bit platforms

[Tom Rini]

On Thu, Jul 09, 2015 at 02:37:30PM +0800, yuantian.t...@freescale.com wrote:

> From: Tang Yuantian 
> 
> When compling under 64bit platforms, there are lots of warnings,
> like:
> 
> drivers/block/ahci.c:114:18: warning: cast to pointer from integer
>  of different size [-Wint-to-pointer-cast]
>   u8 *port_mmio = (u8 *)probe_ent->port[port].port_mmio;
>   ^
> drivers/block/ahci.c: In function ?.hci_host_init?.
> drivers/block/ahci.c:218:49: warning: cast from pointer to integer
>  of different size [-Wpointer-to-int-cast]
>probe_ent->port[i].port_mmio = ahci_port_base((u32) mmio, i);
> 
> ..
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Shaohui Xie 
> Signed-off-by: Tang Yuantian 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Thu, Jul 02, 2015 at 11:34:45AM +0200, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> please pull two bugfixes for MIPS
> 
> 
> The following changes since commit 891b487098ee2169a16b1bbb354aaef28aa90630:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-spi (2015-07-01
> 15:38:12 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mips.git master
> 
> for you to fetch changes up to b11c5d1dc29e81326d1215011d19377737082aeb:
> 
>   MIPS: change 'extern inline' to 'static inline' (2015-07-02 11:29:33
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi,

On 8 July 2015 at 05:30, Andrew Bradford  wrote:
> Hi Bin,
>
> On 07/08 11:18, Bin Meng wrote:
>> Hi Andrew,
>>
>> On Wed, Jul 8, 2015 at 3:16 AM,   wrote:
>> > From: Andrew Bradford 
>> >
>> > Allow for configuration of FSP UPD from the device tree which will
>> > override any settings which the FSP was built with itself if the device
>> > tree settings exist, otherwise simply trust the FSP's defaults.
>> >
>> > Modifies the MinnowMax board to transfer the FSP UPD hard-coded settings
>> > to the MinnowMax dts.
>> >
>> > Signed-off-by: Andrew Bradford 
>> > ---
>> >
>> > Changes from v1:
>> >
>> > - Use "-" rather than "_" in dt property names.
>> > - Use "Bay Trail" for the formal name of the Intel product family.
>> > - Use an "fsp," prefix for dt property names for clarity.
>> > - Fix minor code indentation issues.
>> > - Create a dt subnode for the memory-down-params.
>> > - Clarify documentation that dt overrides the FSP's config, so we don't
>> >   use booleans.
>> >
>> >  arch/x86/cpu/baytrail/fsp_configs.c| 188 
>> > +
>> >  arch/x86/dts/minnowmax.dts |  30 
>> >  .../misc/intel,baytrail-fsp.txt| 119 +
>> >  include/fdtdec.h   |   2 +
>> >  lib/fdtdec.c   |   2 +
>> >  5 files changed, 311 insertions(+), 30 deletions(-)
>> >  create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
>> >
>> > diff --git a/arch/x86/cpu/baytrail/fsp_configs.c 
>> > b/arch/x86/cpu/baytrail/fsp_configs.c
>> > index 86b6926..fce76e6 100644
>> > --- a/arch/x86/cpu/baytrail/fsp_configs.c
>> > +++ b/arch/x86/cpu/baytrail/fsp_configs.c
>> > @@ -1,14 +1,18 @@
>> >  /*
>> >   * Copyright (C) 2013, Intel Corporation
>> >   * Copyright (C) 2014, Bin Meng 
>> > + * Copyright (C) 2015, Kodak Alaris, Inc
>> >   *
>> >   * SPDX-License-Identifier:Intel
>> >   */
>> >
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >
>> > +DECLARE_GLOBAL_DATA_PTR;
>> > +
>> >  /* ALC262 Verb Table - 10EC0262 */
>> >  static const uint32_t verb_table_data13[] = {
>> > /* Pin Complex (NID 0x11) */
>> > @@ -116,41 +120,165 @@ const struct pch_azalia_config azalia_config = {
>> > .reset_wait_timer_us = 300
>> >  };
>> >
>> > +/**
>> > + * Update the FSP's UPD.  The FSP itself can be configured for defaults to
>> > + * store in UPD through Intel's GUI configurator but likely a specific 
>> > board
>> > + * will want to update these from u-boot, so allow for that via device 
>> > tree.
>> > + * If the device tree does not specify a setting, trust the FSP's default.
>> > + */
>> >  void update_fsp_upd(struct upd_region *fsp_upd)
>> >  {
>> > struct memory_down_data *mem;
>> > +   const void *blob = gd->fdt_blob;
>> > +   int node;
>> >
>> > -   /*
>> > -* Configure everything here to avoid the poor hard-pressed user
>> > -* needing to run Intel's binary configuration tool. It may also 
>> > allow
>> > -* us to support the 1GB single core variant easily.
>> > -*
>> > -* TODO(s...@chromium.org): Move to device tree
>> > -*/
>> > -   fsp_upd->mrc_init_tseg_size = 8;
>> > -   fsp_upd->mrc_init_mmio_size = 0x800;
>> > -   fsp_upd->emmc_boot_mode = 0xff;
>> > -   fsp_upd->enable_sdio = 1;
>> > -   fsp_upd->enable_sdcard = 1;
>> > -   fsp_upd->enable_hsuart0 = 1;
>> > fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
>> > -   fsp_upd->enable_i2_c0 = 0;
>> > -   fsp_upd->enable_i2_c2 = 0;
>> > -   fsp_upd->enable_i2_c3 = 0;
>> > -   fsp_upd->enable_i2_c4 = 0;
>> > -   fsp_upd->enable_xhci = 0;
>> > -   fsp_upd->igd_render_standby = 1;
>> > +
>> > +   node = fdtdec_next_compatible(blob, 0, COMPAT_INTEL_BAYTRAIL_FSP);
>> > +   if (node < 0) {
>> > +   debug("%s: Cannot find FSP node\n", __func__);
>> > +   return;
>> > +   }
>> > +
>> > +   fsp_upd->mrc_init_tseg_size = fdtdec_get_int(blob, node,
>> > +
>> > "fsp,mrc-int-tseg-size",
>>
>> mrc-int? Guess it is mrc-init.
>
> Yes, thank you for catching this.  Will fix in v3.
>
>> > +
>> > fsp_upd->mrc_init_tseg_size);
>> > +   fsp_upd->mrc_init_mmio_size = fdtdec_get_int(blob, node,
>> > +
>> > "fsp,mrc-init-mmio-size",
>> > +
>> > fsp_upd->mrc_init_mmio_size);
>> > +   fsp_upd->mrc_init_spd_addr1 = fdtdec_get_int(blob, node,
>> > +
>> > "fsp,mrc-init-spd-addr1",
>> > +
>> > fsp_upd->mrc_init_spd_addr1);
>> > +   fsp_upd->mrc_init_spd_addr2 = fdtdec_get_int(blob, node,
>> > +  

Re: [U-Boot] [PATCH v3 2/2] pci: Disable expansion ROM address decoding when signature check fails

[Simon Glass]

On 7 July 2015 at 23:06, Bin Meng  wrote:
> We should not leave the expansion ROM address window open when there
> is not a valid ROM.
>
> Suggested-by: Matt Porter 
> Signed-off-by: Bin Meng 
>
> ---
> I did not update pci_rom_probe() to handle the header type1 ROM address,
> as I think pci_rom_probe() is a static routine which is only used for
> VGA ROM only so far, so we don't need consider type1 case.
>
> Changes in v3:
> - Rebase on u-boot-x86/master
>
> Changes in v2:
> - New patch to disable expansion ROM address decoding when signature check 
> fails
>
>  drivers/pci/pci_rom.c | 4 
>  1 file changed, 4 insertions(+)

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

Re: [U-Boot] [PATCH v3 1/2] pci: Configure expansion ROM during auto config process

[Simon Glass]

On 7 July 2015 at 23:06, Bin Meng  wrote:
> Currently PCI expansion ROM address is assigned by a call to
> pciauto_setup_rom() outside of the pci auto config process.
> This does not work when expansion ROM is on a device behind
> PCI bridge where bridge's memory limit register was already
> programmed to a value that does not cover the newly assigned
> expansion ROM address. To fix this, we should configure the
> ROM address during the auto config process.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 
>
> ---
>
> Changes in v3: None
> Changes in v2:
> - Handle header type 1 ROM address programming
>
>  drivers/pci/pci_auto.c | 48 ++--
>  drivers/pci/pci_rom.c  |  5 -
>  include/pci.h  |  9 -
>  3 files changed, 22 insertions(+), 40 deletions(-)

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

[U-Boot] [PATCH] qoriq eth.c bugfix: handle received corrupted frames correctly

[Daniel Inderbitzin]

From: Daniel Inderbitzin 

The rxbd is not correctly handled in case of a frame physical error
(FPE) or frame size error (FSE). The rxbd must be cleared and
advanced in case of an error to avoid receive stall.

Signed-off-by: Daniel Inderbitzin 
---

 drivers/net/fm/eth.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index d7a37f3..6702f5a 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -520,6 +520,7 @@ static int fm_eth_recv(struct eth_device *dev)
u16 status, len;
u8 *data;
u16 offset_out;
+   int ret = 1;
 
fm_eth = (struct fm_eth *)dev->priv;
pram = fm_eth->rx_pram;
@@ -533,7 +534,7 @@ static int fm_eth_recv(struct eth_device *dev)
net_process_received_packet(data, len);
} else {
printf("%s: Rx error\n", dev->name);
-   return 0;
+   ret = 0;
}
 
/* clear the RxBDs */
@@ -559,7 +560,7 @@ static int fm_eth_recv(struct eth_device *dev)
}
fm_eth->cur_rxbd = (void *)rxbd;
 
-   return 1;
+   return ret;
 }
 
 static int fm_eth_init_mac(struct fm_eth *fm_eth, struct ccsr_fman *reg)
-- 
2.4.5

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

[U-Boot] please pull u-boot-samsung master

[Minkyu Kang]

Dear Tom,

The following changes since commit f3edfd30541d6f245d7dfa6fa7354cc916cc53e1:

  net: designware: Program MAC address to hardware after soft reset (2015-07-08 
13:43:19 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-samsung 

for you to fetch changes up to 8fd3ec770c41115b95ca80f0f0ba344ac59dc293:

  exynos: i2c: Correct bug in pinmux selection (2015-07-10 21:13:48 +0900)


Minkyu Kang (1):
  arm: adds the status info for odroid-xu3

Simon Glass (1):
  exynos: i2c: Correct bug in pinmux selection

 board/samsung/smdk5420/MAINTAINERS |1 +
 drivers/i2c/s3c24x0_i2c.c  |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] arm: adds the status info for odroid-xu3

[Minkyu Kang]

On 02/07/15 10:27, Minkyu Kang wrote:
> Adds the 'F:' entry for the board's defconfig
> 
> Signed-off-by: Minkyu Kang 
> ---
>  board/samsung/smdk5420/MAINTAINERS |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/samsung/smdk5420/MAINTAINERS 
> b/board/samsung/smdk5420/MAINTAINERS
> index a26ea68..0361657 100644
> --- a/board/samsung/smdk5420/MAINTAINERS
> +++ b/board/samsung/smdk5420/MAINTAINERS
> @@ -14,3 +14,4 @@ M:  Przemyslaw Marczak 
>  S:   Maintained
>  F:   board/samsung/smdk5420/
>  F:   include/configs/odroid_xu3.h
> +F:   configs/odroid-xu3_defconfig
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH 07/55] exynos: i2c: Correct bug in pinmux selection

[Minkyu Kang]

On 10/07/15 10:46, Simon Glass wrote:
> Hi Minkyu,
> 
> On 9 July 2015 at 19:43, Minkyu Kang  wrote:
>> Hi Simon,
>>
>> On 08/07/15 11:38, Simon Glass wrote:
>>> Hi Minkyu,
>>>
>>> On 6 July 2015 at 19:36, Minkyu Kang  wrote:
 Dear Simon,

 On 07/07/15 00:27, Simon Glass wrote:
> Hi Minkyu, Przemyslaw,
>
> On 5 July 2015 at 00:15, Heiko Schocher  wrote:
>> Hello Simon,
>>
>> Am 03.07.2015 um 02:15 schrieb Simon Glass:
>>>
>>> When driver model is not used the current code does not correctly select
>>> the pinmux for the I2C bus. This bug was introduced by this commit:
>>>
>>> 8dfcbaa dm: i2c: s3c24x0: adjust to dm-i2c api
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>>   drivers/i2c/s3c24x0_i2c.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>
>> Acked-by: Heiko Schocher 
>>
>> As it is a bugfix, this should go in the current release ... right?
>
> Minkyu, are you able to pick this up please? If not I can do it.
>

 Only this patch? or all of samsung related patches?
>>>
>>> Yes only this patch. It has been confirmed my Przemyslaw now too.
>>>
>>
>> OK.
>> then, do you want to take other patches to your tree?
> 
> There are still dependencies on u-boot-dm, so I cannot yet. But if you
> like I can do that later, after I have merged some more driver model
> support patches.
> 
> Regards,
> Simon
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH 50/55] power: Remove old TPS65090 drivers

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Remove the old drivers (both the normal one and the cros_ec one) now that
we have new drivers that use driver model.

Signed-off-by: Simon Glass 
---

  drivers/power/pmic/Makefile   |   2 -
  drivers/power/pmic/pmic_tps65090.c| 310 --
  drivers/power/pmic/pmic_tps65090_ec.c | 218 
  include/configs/peach-pit.h   |   2 -
  include/fdtdec.h  |   1 -
  include/power/tps65090_pmic.h |  73 
  lib/fdtdec.c  |   1 -
  7 files changed, 607 deletions(-)
  delete mode 100644 drivers/power/pmic/pmic_tps65090.c
  delete mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
  delete mode 100644 include/power/tps65090_pmic.h

diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index ee23c26..c8c4364 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -17,8 +17,6 @@ obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
  obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
  obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
  obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
-obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o
-obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
  obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
  obj-$(CONFIG_POWER_TPS65218) += pmic_tps62362.o
  obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
diff --git a/drivers/power/pmic/pmic_tps65090.c 
b/drivers/power/pmic/pmic_tps65090.c
deleted file mode 100644
index 337903a..000
--- a/drivers/power/pmic/pmic_tps65090.c
+++ /dev/null
@@ -1,310 +0,0 @@
-/*
- * Copyright (c) 2012 The Chromium OS Authors.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define TPS65090_NAME "TPS65090_PMIC"
-
-/* TPS65090 register addresses */
-enum {
-   REG_IRQ1 = 0,
-   REG_CG_CTRL0 = 4,
-   REG_CG_STATUS1 = 0xa,
-   REG_FET1_CTRL = 0x0f,
-   REG_FET2_CTRL,
-   REG_FET3_CTRL,
-   REG_FET4_CTRL,
-   REG_FET5_CTRL,
-   REG_FET6_CTRL,
-   REG_FET7_CTRL,
-   TPS65090_NUM_REGS,
-};
-
-enum {
-   IRQ1_VBATG = 1 << 3,
-   CG_CTRL0_ENC_MASK   = 0x01,
-
-   MAX_FET_NUM = 7,
-   MAX_CTRL_READ_TRIES = 5,
-
-   /* TPS65090 FET_CTRL register values */
-   FET_CTRL_TOFET  = 1 << 7,  /* Timeout, startup, overload */
-   FET_CTRL_PGFET  = 1 << 4,  /* Power good for FET status */
-   FET_CTRL_WAIT   = 3 << 2,  /* Overcurrent timeout max */
-   FET_CTRL_ADENFET= 1 << 1,  /* Enable output auto discharge */
-   FET_CTRL_ENFET  = 1 << 0,  /* Enable FET */
-};
-
-/**
- * Checks for a valid FET number
- *
- * @param fet_id   FET number to check
- * @return 0 if ok, -EINVAL if FET value is out of range
- */
-static int tps65090_check_fet(unsigned int fet_id)
-{
-   if (fet_id == 0 || fet_id > MAX_FET_NUM) {
-   debug("parameter fet_id is out of range, %u not in 1 ~ %u\n",
- fet_id, MAX_FET_NUM);
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
-/**
- * Set the power state for a FET
- *
- * @param pmic pmic structure for the tps65090
- * @param fet_id   Fet number to set (1..MAX_FET_NUM)
- * @param set  1 to power on FET, 0 to power off
- * @return -EIO if we got a comms error, -EAGAIN if the FET failed to
- * change state. If all is ok, returns 0.
- */
-static int tps65090_fet_set(struct pmic *pmic, int fet_id, bool set)
-{
-   int retry;
-   u32 reg, value;
-
-   value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
-   if (set)
-   value |= FET_CTRL_ENFET;
-
-   if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
-   return -EIO;
-
-   /* Try reading until we get a result */
-   for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
-   if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, ®))
-   return -EIO;
-
-   /* Check that the fet went into the expected state */
-   if (!!(reg & FET_CTRL_PGFET) == set)
-   return 0;
-
-   /* If we got a timeout, there is no point in waiting longer */
-   if (reg & FET_CTRL_TOFET)
-   break;
-
-   mdelay(1);
-   }
-
-   debug("FET %d: Power good should have set to %d but reg=%#02x\n",
- fet_id, set, reg);
-   return -EAGAIN;
-}
-
-int tps65090_fet_enable(unsigned int fet_id)
-{
-   struct pmic *pmic;
-   ulong start;
-   int loops;
-   int ret;
-
-   ret = tps65090_check_fet(fet_id);
-   if (ret)
-   return ret;
-
-   pmic = pmic_get(TPS65090_NAME);
-   if (!pmic)
-   return -EACCES;
-
-   start = get_timer(0);
-   for (loops = 0;; loops++) {
-   

Re: [U-Boot] [PATCH 47/55] exynos: config: Move common options to the common headers and tidy up

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Many options are duplicated on the exynos5 boards. Move these to the common
files. Also some options are not used so can be removed.

Tidy this up to make the files easier to maintain.

Signed-off-by: Simon Glass 
---

  include/configs/arndale.h   | 14 ++
  include/configs/exynos5-common.h|  3 ---
  include/configs/exynos5-dt-common.h | 17 -
  include/configs/exynos5250-common.h | 16 ++--
  include/configs/exynos5420-common.h |  9 +++--
  include/configs/odroid_xu3.h|  2 ++
  include/configs/peach-pi.h  | 13 +
  include/configs/peach-pit.h | 21 +
  include/configs/smdk5250.h  | 16 
  include/configs/smdk5420.h  | 11 ---
  include/configs/snow.h  | 13 +
  11 files changed, 40 insertions(+), 95 deletions(-)


...

Acked-by: Przemyslaw Marczak 

Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 48/55] exynos: Drop old exynos5420-specific board code

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Now that exynos5420 boards can use the generic exynos5 code, switch over to
it and remove the old code.

Signed-off-by: Simon Glass 
---

  board/samsung/smdk5420/Makefile |   4 -
  board/samsung/smdk5420/smdk5420.c   | 143 
  include/configs/exynos5420-common.h |   2 +
  3 files changed, 2 insertions(+), 147 deletions(-)
  delete mode 100644 board/samsung/smdk5420/smdk5420.c

diff --git a/board/samsung/smdk5420/Makefile b/board/samsung/smdk5420/Makefile
index c2f8886..96a400a 100644
--- a/board/samsung/smdk5420/Makefile
+++ b/board/samsung/smdk5420/Makefile
@@ -5,7 +5,3 @@
  #

  obj-y += smdk5420_spl.o
-
-ifndef CONFIG_SPL_BUILD
-obj-y  += smdk5420.o
-endif
diff --git a/board/samsung/smdk5420/smdk5420.c 
b/board/samsung/smdk5420/smdk5420.c
deleted file mode 100644
index 57cc92c..000
--- a/board/samsung/smdk5420/smdk5420.c
+++ /dev/null
@@ -1,143 +0,0 @@
-/*
- * Copyright (C) 2013 Samsung Electronics
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int exynos_init(void)
-{
-   return 0;
-}
-
-#ifdef CONFIG_LCD
-static int has_edp_bridge(void)
-{
-   int node;
-
-   node = fdtdec_next_compatible(gd->fdt_blob, 0, COMPAT_PARADE_PS8625);
-
-   /* No node for bridge in device tree. */
-   if (node <= 0)
-   return 0;
-
-   /* Default is with bridge ic */
-   return 1;
-}
-
-void exynos_lcd_power_on(void)
-{
-#ifdef CONFIG_POWER_TPS65090
-   int ret;
-
-   ret = tps65090_init();
-   if (ret < 0) {
-   printf("%s: tps65090_init() failed\n", __func__);
-   return;
-   }
-
-   tps65090_fet_enable(6);
-#endif
-
-   mdelay(5);
-
-   if (has_edp_bridge())
-   if (parade_init(gd->fdt_blob))
-   printf("%s: ps8625_init() failed\n", __func__);
-}
-
-void exynos_backlight_on(unsigned int onoff)
-{
-#ifdef CONFIG_POWER_TPS65090
-   tps65090_fet_enable(1);
-#endif
-}
-#endif
-
-int board_get_revision(void)
-{
-   return 0;
-}
-
-#ifdef CONFIG_USB_DWC3
-static struct dwc3_device dwc3_device_data = {
-   .maximum_speed = USB_SPEED_SUPER,
-   .base = 0x1240,
-   .dr_mode = USB_DR_MODE_PERIPHERAL,
-   .index = 0,
-};
-
-int usb_gadget_handle_interrupts(void)
-{
-   dwc3_uboot_handle_interrupt(0);
-   return 0;
-}
-
-int board_usb_init(int index, enum usb_init_type init)
-{
-   struct exynos_usb3_phy *phy = (struct exynos_usb3_phy *)
-   samsung_get_base_usb3_phy();
-
-   if (!phy) {
-   error("usb3 phy not supported");
-   return -ENODEV;
-   }
-
-   set_usbdrd_phy_ctrl(POWER_USB_DRD_PHY_CTRL_EN);
-   exynos5_usb3_phy_init(phy);
-
-   return dwc3_uboot_init(&dwc3_device_data);
-}
-#endif
-#ifdef CONFIG_SET_DFU_ALT_INFO
-char *get_dfu_alt_system(char *interface, char *devstr)
-{
-   return getenv("dfu_alt_system");
-}
-
-char *get_dfu_alt_boot(char *interface, char *devstr)
-{
-   struct mmc *mmc;
-   char *alt_boot;
-   int dev_num;
-
-   dev_num = simple_strtoul(devstr, NULL, 10);
-
-   mmc = find_mmc_device(dev_num);
-   if (!mmc)
-   return NULL;
-
-   if (mmc_init(mmc))
-   return NULL;
-
-   if (IS_SD(mmc))
-   alt_boot = CONFIG_DFU_ALT_BOOT_SD;
-   else
-   alt_boot = CONFIG_DFU_ALT_BOOT_EMMC;
-
-   return alt_boot;
-}
-#endif
diff --git a/include/configs/exynos5420-common.h 
b/include/configs/exynos5420-common.h
index 3cdec51..cd86e06 100644
--- a/include/configs/exynos5420-common.h
+++ b/include/configs/exynos5420-common.h
@@ -13,6 +13,8 @@
  /* A variant of Exynos5420 (Exynos5 Family) */
  #define CONFIG_EXYNOS5800

+#define CONFIG_EXYNOS5_DT
+
  #define MACH_TYPE_SMDK54208002
  #define CONFIG_MACH_TYPE  MACH_TYPE_SMDK5420




Acked-by: Przemyslaw Marczak 

Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 45/55] exynos: Enable new features for exynos5 boards

[Przemyslaw Marczak]

Hello,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Enable PMICs, regulators and the like so that new drivers will be made
available.

Signed-off-by: Simon Glass 
---

  board/samsung/smdk5420/smdk5420.c   |  2 +-
  configs/arndale_defconfig   |  2 ++
  configs/odroid-xu3_defconfig|  5 +
  configs/peach-pi_defconfig  | 17 +
  configs/peach-pit_defconfig | 17 +
  configs/smdk5250_defconfig  | 10 ++
  configs/smdk5420_defconfig  |  5 +
  configs/snow_defconfig  | 23 +++
  include/configs/arndale.h   |  4 
  include/configs/exynos5-common.h| 10 ++
  include/configs/exynos5-dt-common.h |  5 -
  include/configs/smdk5250.h  |  3 ---
  include/configs/snow.h  |  3 ---
  13 files changed, 86 insertions(+), 20 deletions(-)

diff --git a/board/samsung/smdk5420/smdk5420.c 
b/board/samsung/smdk5420/smdk5420.c
index 88f4044..57cc92c 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -50,9 +50,9 @@ static int has_edp_bridge(void)

  void exynos_lcd_power_on(void)
  {
+#ifdef CONFIG_POWER_TPS65090
int ret;

-#ifdef CONFIG_POWER_TPS65090
ret = tps65090_init();
if (ret < 0) {
printf("%s: tps65090_init() failed\n", __func__);
diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig
index 43f39f2..10e9d03 100644
--- a/configs/arndale_defconfig
+++ b/configs/arndale_defconfig
@@ -10,3 +10,5 @@ CONFIG_I2S=y
  CONFIG_I2S_SAMSUNG=y
  CONFIG_SOUND_MAX98095=y
  CONFIG_SOUND_WM8994=y
+CONFIG_DM_I2C=y
+CONFIG_DM_I2C_COMPAT=y
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index c9c4849..9760808 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -4,3 +4,8 @@ CONFIG_TARGET_ODROID_XU3=y
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_DEFAULT_DEVICE_TREE="exynos5422-odroidxu3"
  CONFIG_CMD_NET=y
+CONFIG_DM_I2C=y
+CONFIG_DM_I2C_COMPAT=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_REGULATOR=y


At present we don't have pmic/regulator driver for XU3, but probably 
will have soon, so it can be enabled.


But there is no video bridge on XU3.

I assume that you enable this, because of using the single board file, 
but should go this way?


Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 30/55] dm: pmic: Display the regulator limits on error

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

When a regulator command cannot honour the requested voltage, display the
limits to try to be helpful.

Signed-off-by: Simon Glass 
---

  common/cmd_regulator.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/cmd_regulator.c b/common/cmd_regulator.c
index 6149d1e..2d8579b 100644
--- a/common/cmd_regulator.c
+++ b/common/cmd_regulator.c
@@ -241,7 +241,8 @@ static int do_value(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])

value = simple_strtoul(argv[1], NULL, 0);
if ((value < uc_pdata->min_uV || value > uc_pdata->max_uV) && !force) {
-   printf("Value exceeds regulator constraint limits\n");


Could you please also add printing the 'uV' unit?


+   printf("Value exceeds regulator constraint limits %d..%d\n",
+  uc_pdata->min_uV, uc_pdata->max_uV);
return CMD_RET_FAILURE;
}




Acked-by: Przemyslaw Marczak 

Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 29/55] dm: power: Don't return an error when regulators are not autoset

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Not all regulators can be set up automatically. Adjust the code so that
regulators_enable_boot_on() will return success when some are skipped.
Only genuine errors are reported.

Signed-off-by: Simon Glass 
---

  drivers/power/regulator/regulator-uclass.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index 12e141b..f3fe7a5 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -319,8 +319,10 @@ int regulators_enable_boot_on(bool verbose)
 dev && !ret;
 uclass_next_device(&dev)) {
ret = regulator_autoset(dev);
-   if (ret == -EMEDIUMTYPE)
+   if (ret == -EMEDIUMTYPE) {
+   ret = 0;
continue;
+   }
if (verbose)
regulator_show(dev, ret);
}



Acked-by: Przemyslaw Marczak 

Regards.
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 28/55] dm: pmic: max77686: Support all BUCK regulators

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Add support for all BUCK regulators, now that the correct register is
accessed for each.

Signed-off-by: Simon Glass 
---

  drivers/power/regulator/max77686.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/power/regulator/max77686.c 
b/drivers/power/regulator/max77686.c
index 21173fc..427b717 100644
--- a/drivers/power/regulator/max77686.c
+++ b/drivers/power/regulator/max77686.c
@@ -81,11 +81,7 @@ static int max77686_buck_volt2hex(int buck, int uV)
/* hex = (uV - 60) / 12500; */
hex = (uV - MAX77686_BUCK_UV_LMIN) / MAX77686_BUCK_UV_LSTEP;
hex_max = MAX77686_BUCK234_VOLT_MAX_HEX;
-   /**
-* Those use voltage scaller - temporary not implemented
-* so return just 0
-*/
-   return -ENOSYS;
+   break;
default:
/* hex = (uV - 75) / 5; */
hex = (uV - MAX77686_BUCK_UV_HMIN) / MAX77686_BUCK_UV_HSTEP;
@@ -379,11 +375,11 @@ static int max77686_buck_val(struct udevice *dev, int op, 
int *uV)
case 2:
case 3:
case 4:
-   /* Those use voltage scallers - will support in the future */
mask = MAX77686_BUCK234_VOLT_MASK;
-   return -ENOSYS;
+   break;
default:
mask = MAX77686_BUCK_VOLT_MASK;
+   break;
}

ret = pmic_read(dev->parent, adr, &val, 1);



The bucks 2,3,4 can work in DVS mode, which allows select one of eight 
DVS regulators for each output. The default selection at power-on is 
DVS1 for each output, and it corresponds to the currently defined output 
register addresses.


The selection can be done by six PMIC's GPIOs:
- DVS1/2/3 - output selection: 0x0=DVS1...0x7=DVS8
- SELB2/3/4 - mode switch: 'DVS' or 'no DVS'

Reading or writing the default registers is proper only in case:
- for the default PMIC's power-up setting - may conflict with bl1/bl2
- when DVS1/2/3 GPIOs are set to LOW - DVS1 selected
- SELB2/3/4 - are set to LOW - no DVS mode

The documentation is poor, but if I good understand, the SELB is used as 
"latch" for the DVS selection.


So the driver, could be unreliable for these outputs if it doesn't check 
the PMIC's GPIOs.


It's quite confusing, since the PMIC, doesn't provide registers to check 
those GPIOs. It should be checked by the driver and can be delivered by 
device-tree.


This is also confusing, since it depends on board design, because the 
PMIC's GPIOs can be connected to the SoCs GPIOs and also just pulled to 
POWER/GND signals.


The documentation says, that those GPIOs should be set accordingly, and 
for example Odroid U3 has connected the SELB to VDD_IO(LDO3) power line, 
so actually this state can not be changed or can be changed by accident 
when changing the VDD_IO - which is HIGH at PMIC's power-up.


The switching is impossible, since the VDD_IO line is shared with few 
other peripherals.


In this case, maybe you should add config to allow use of the BUCK234 
only for case in which DVS mode is disabled by board design (SELB2/3/4 
set to LOW). This may also work, when the GPIOs of Exynos stays in the 
reset state.


Then, using the default 'buck_out' registers: 0x14, 0x1e, 0x28 is 
reasonable.


Did you tried measure the output voltage, after its change?

Regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 26/55] dm: pmic: Correct the pmic_reg_write() implementation

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

This should write the register, not read it. Fix this bug.

Signed-off-by: Simon Glass 
---

  drivers/power/pmic/pmic-uclass.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/pmic/pmic-uclass.c b/drivers/power/pmic/pmic-uclass.c
index d99cb9a..49709f3 100644
--- a/drivers/power/pmic/pmic-uclass.c
+++ b/drivers/power/pmic/pmic-uclass.c
@@ -142,7 +142,7 @@ int pmic_reg_write(struct udevice *dev, uint reg, uint 
value)
u8 byte = value;

debug("%s: reg=%x, value=%x\n", __func__, reg, value);
-   return pmic_read(dev, reg, &byte, 1);
+   return pmic_write(dev, reg, &byte, 1);
  }

  int pmic_clrsetbits(struct udevice *dev, uint reg, uint clr, uint set)



Acked-by: Przemyslaw Marczak 

Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 27/55] dm: power: max77686: Correct BUCK register access

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

Some regulators use the wrong voltage register and thus it is not possible
to control them. Fix this.

Signed-off-by: Simon Glass 
---

  drivers/power/regulator/max77686.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/power/regulator/max77686.c 
b/drivers/power/regulator/max77686.c
index 37ebe94..21173fc 100644
--- a/drivers/power/regulator/max77686.c
+++ b/drivers/power/regulator/max77686.c
@@ -61,10 +61,14 @@ static struct dm_regulator_mode max77686_buck_mode_onoff[] 
= {
MODE(OPMODE_ON, MAX77686_BUCK_MODE_ON, "ON"),
  };

-static const char max77686_buck_addr[] = {
+static const char max77686_buck_ctrl[] = {
0xff, 0x10, 0x12, 0x1c, 0x26, 0x30, 0x32, 0x34, 0x36, 0x38
  };

+static const char max77686_buck_out[] = {
+   0xff, 0x11, 0x14, 0x1e, 0x28, 0x31, 0x33, 0x35, 0x37, 0x39
+};
+
  static int max77686_buck_volt2hex(int buck, int uV)
  {
unsigned int hex = 0;
@@ -368,7 +372,7 @@ static int max77686_buck_val(struct udevice *dev, int op, 
int *uV)
*uV = 0;

/* &buck_out = ctrl + 1 */
-   adr = max77686_buck_addr[buck] + 1;
+   adr = max77686_buck_out[buck];

/* mask */
switch (buck) {
@@ -549,7 +553,7 @@ static int max77686_buck_mode(struct udevice *dev, int op, 
int *opmode)
return -EINVAL;
}

-   adr = max77686_buck_addr[buck];
+   adr = max77686_buck_ctrl[buck];

/* mask */
switch (buck) {



Acked-by: Przemyslaw Marczak 

Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 23/55] dm: power: Add support for the S5M8767 PMIC

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports probing and basic register access. It supports the standard
device tree binding and supports driver model. A regulator driver can be
provided also.

Signed-off-by: Simon Glass 
---

  drivers/power/pmic/Kconfig   |  9 +
  drivers/power/pmic/Makefile  |  2 +
  drivers/power/pmic/s5m8767.c | 95 
  include/power/s5m8767.h  | 85 +++
  4 files changed, 191 insertions(+)
  create mode 100644 drivers/power/pmic/s5m8767.c
  create mode 100644 include/power/s5m8767.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index fd8af81..7b98189 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -42,6 +42,15 @@ config DM_PMIC_SANDBOX

Driver binding info: doc/device-tree-bindings/pmic/sandbox.txt

+config PMIC_S5M8767
+   bool "Enable Driver Model for the Samsung S5M8767 PMIC"
+   depends on DM_PMIC
+   ---help---
+   The S5M8767 PMIC provides a large array of LDOs and BUCKs for use
+   as a SoC power controller. It also provides 32KHz clock outputs. This
+   driver provides basic register access and sets up the attached
+   regulators if regulator support is enabled.
+
  config PMIC_TPS65090
bool "Enable driver for Texas Instruments TPS65090 PMIC"
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 2316e3b..ee23c26 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
  obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
  obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
  obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
+obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
+
  obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
  obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
  obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
diff --git a/drivers/power/pmic/s5m8767.c b/drivers/power/pmic/s5m8767.c
new file mode 100644
index 000..075fe7e
--- /dev/null
+++ b/drivers/power/pmic/s5m8767.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright (C) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+   { .prefix = "LDO", .driver = S5M8767_LDO_DRIVER },
+   { .prefix = "BUCK", .driver = S5M8767_BUCK_DRIVER },
+   { },
+};
+
+static int s5m8767_reg_count(struct udevice *dev)
+{
+   return S5M8767_NUM_OF_REGS;
+}
+
+static int s5m8767_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+   if (dm_i2c_write(dev, reg, buff, len)) {
+   error("write error to device: %p register: %#x!", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int s5m8767_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   if (dm_i2c_read(dev, reg, buff, len)) {
+   error("read error from device: %p register: %#x!", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+int s5m8767_enable_32khz_cp(struct udevice *dev)
+{
+   return pmic_clrsetbits(dev, S5M8767_EN32KHZ_CP, 0, 1 << 1);
+}
+
+static int s5m8767_bind(struct udevice *dev)
+{
+   int node;
+   const void *blob = gd->fdt_blob;
+   int children;
+
+   node = fdt_subnode_offset(blob, dev->of_offset, "regulators");
+   if (node <= 0) {
+   debug("%s: %s regulators subnode not found!", __func__,
+ dev->name);
+   return -ENXIO;
+   }
+
+   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
+
+   children = pmic_bind_children(dev, node, pmic_children_info);
+   if (!children)
+   debug("%s: %s - no child found\n", __func__, dev->name);
+
+   /* Always return success for this device */
+   return 0;
+}
+
+static struct dm_pmic_ops s5m8767_ops = {
+   .reg_count = s5m8767_reg_count,
+   .read = s5m8767_read,
+   .write = s5m8767_write,
+};
+
+static const struct udevice_id s5m8767_ids[] = {
+   { .compatible = "samsung,s5m8767-pmic" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_s5m8767) = {
+   .name = "s5m8767_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = s5m8767_ids,
+   .bind = s5m8767_bind,
+   .ops = &s5m8767_ops,
+};
diff --git a/include/power/s5m8767.h b/include/power/s5m8767.h
new file mode 100644
index 000..ba88ff7
--- /dev/null
+++ b/include/power/s5m8767.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __S5M8767_H_
+#define __S5M8767_H_
+
+enum s5m8767_regnum {
+   S5M8767_BUCK1 = 0,
+   S5M8767_BUCK2,
+  

Re: [U-Boot] [PATCH 25/55] dm: pmic: max77686: Correct a few nits

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

The driver name should not have a space in it. Also the regulator names
should match the case of the device tree. Fix these problems.

Signed-off-by: Simon Glass 
---

  drivers/power/pmic/max77686.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/power/pmic/max77686.c b/drivers/power/pmic/max77686.c
index 3523b4a..dc5a54a 100644
--- a/drivers/power/pmic/max77686.c
+++ b/drivers/power/pmic/max77686.c
@@ -17,8 +17,8 @@
  DECLARE_GLOBAL_DATA_PTR;

  static const struct pmic_child_info pmic_children_info[] = {
-   { .prefix = "ldo", .driver = MAX77686_LDO_DRIVER },
-   { .prefix = "buck", .driver = MAX77686_BUCK_DRIVER },
+   { .prefix = "LDO", .driver = MAX77686_LDO_DRIVER },
+   { .prefix = "BUCK", .driver = MAX77686_BUCK_DRIVER },
{ },
  };

@@ -84,7 +84,7 @@ static const struct udevice_id max77686_ids[] = {
  };

  U_BOOT_DRIVER(pmic_max77686) = {
-   .name = "max77686 pmic",
+   .name = "max77686_pmic",
.id = UCLASS_PMIC,
.of_match = max77686_ids,
.bind = max77686_bind,



Acked-by: Przemyslaw Marczak 

This change is ok, but could you please consider Odroid U3 
(exynos4412-odroid.dts) within this patch set?


Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 24/55] dm: power: Add support for S5M8767 regulators

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:16 AM, Simon Glass wrote:

This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports changing voltage and enabling/disabling each regulator. It
supports the standard device tree binding and supports driver model.

Signed-off-by: Simon Glass 
---

  drivers/power/regulator/Kconfig   |   9 ++
  drivers/power/regulator/Makefile  |   1 +
  drivers/power/regulator/s5m8767.c | 269 ++
  3 files changed, 279 insertions(+)
  create mode 100644 drivers/power/regulator/s5m8767.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index d090650..e85c692 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -32,6 +32,15 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements get/set api
for enable and get only for voltage value.

+config REGULATOR_S5M8767
+   bool "Enable support for S5M8767 regulator"
+   depends on DM_REGULATOR && PMIC_S5M8767
+   ---help---
+   This enables the regulator features of the S5M8767, allowing voltages
+   to be set, etc. The driver is not fully complete but supports most
+   common requirements, including all LDOs and BUCKs. This allows many
+   supplies to be set automatically using the device tree values.
+
  config DM_REGULATOR_SANDBOX
bool "Enable Driver Model for Sandbox PMIC regulator"
depends on DM_REGULATOR && DM_PMIC_SANDBOX
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 43f4d2c..08d7b0d 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -8,5 +8,6 @@
  obj-$(CONFIG_DM_REGULATOR) += regulator-uclass.o
  obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
  obj-$(CONFIG_DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
  obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
  obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o
diff --git a/drivers/power/regulator/s5m8767.c 
b/drivers/power/regulator/s5m8767.c
new file mode 100644
index 000..93a3c94
--- /dev/null
+++ b/drivers/power/regulator/s5m8767.c
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct sec_voltage_desc buck_v1 = {
+   .max = 2225000,
+   .min =  65,
+   .step =   6250,
+};
+
+static const struct sec_voltage_desc buck_v2 = {
+   .max = 160,
+   .min =  60,
+   .step =   6250,
+};
+
+static const struct sec_voltage_desc buck_v3 = {
+   .max = 300,
+   .min =  75,
+   .step =  12500,
+};
+
+static const struct sec_voltage_desc ldo_v1 = {
+   .max = 395,
+   .min =  80,
+   .step =  5,
+};
+
+static const struct sec_voltage_desc ldo_v2 = {
+   .max = 2375000,
+   .min =  80,
+   .step =  25000,
+};
+
+static const struct s5m8767_para buck_param[] = {
+   /*
+*| voltage |  | enable -|   voltage
+* regnum   addr  bpos mask  addr  on desc
+*/
+   {S5M8767_BUCK1, 0x33, 0x0, 0xff, 0x32, 0x3, &buck_v1},
+   {S5M8767_BUCK2, 0x35, 0x0, 0xff, 0x34, 0x1, &buck_v2},
+   {S5M8767_BUCK3, 0x3e, 0x0, 0xff, 0x3d, 0x1, &buck_v2},
+   {S5M8767_BUCK4, 0x47, 0x0, 0xff, 0x46, 0x1, &buck_v2},
+   {S5M8767_BUCK5, 0x50, 0x0, 0xff, 0x4f, 0x3, &buck_v1},
+   {S5M8767_BUCK6, 0x55, 0x0, 0xff, 0x54, 0x3, &buck_v1},
+   {S5M8767_BUCK7, 0x57, 0x0, 0xff, 0x56, 0x3, &buck_v3},
+   {S5M8767_BUCK8, 0x59, 0x0, 0xff, 0x58, 0x3, &buck_v3},
+   {S5M8767_BUCK9, 0x5b, 0x0, 0xff, 0x5a, 0x3, &buck_v3},
+};
+
+static const struct s5m8767_para ldo_param[] = {
+   {S5M8767_LDO1,  0x5c, 0x0, 0x3f, 0x5c, 0x3, &ldo_v2},
+   {S5M8767_LDO2,  0x5d, 0x0, 0x3f, 0x5d, 0x1, &ldo_v2},
+   {S5M8767_LDO3,  0x61, 0x0, 0x3f, 0x61, 0x3, &ldo_v1},
+   {S5M8767_LDO4,  0x62, 0x0, 0x3f, 0x62, 0x3, &ldo_v1},
+   {S5M8767_LDO5,  0x63, 0x0, 0x3f, 0x63, 0x3, &ldo_v1},
+   {S5M8767_LDO6,  0x64, 0x0, 0x3f, 0x64, 0x1, &ldo_v2},
+   {S5M8767_LDO7,  0x65, 0x0, 0x3f, 0x65, 0x1, &ldo_v2},
+   {S5M8767_LDO8,  0x66, 0x0, 0x3f, 0x66, 0x1, &ldo_v2},
+   {S5M8767_LDO9,  0x67, 0x0, 0x3f, 0x67, 0x3, &ldo_v1},
+   {S5M8767_LDO10, 0x68, 0x0, 0x3f, 0x68, 0x1, &ldo_v1},
+   {S5M8767_LDO11, 0x69, 0x0, 0x3f, 0x69, 0x1, &ldo_v1},
+   {S5M8767_LDO12, 0x6a, 0x0, 0x3f, 0x6a, 0x1, &ldo_v1},
+   {S5M8767_LDO13, 0x6b, 0x0, 0x3f, 0x6b, 0x3, &ldo_v1},
+   {S5M8767_LDO14, 0x6c, 0x0, 0x3f, 0x6c, 0x1, &ldo_v1},
+   {S5M8767_LDO15, 0x6d, 0x0, 0x3f, 0x6d, 0x1, &ldo_v2},
+   {S5M8767_LDO16, 0x6e, 0x0, 0x3f, 0x6e, 0x1, &ldo_v1},
+   {S5M8767_LDO17, 0x6f, 0x0, 0x3f, 0x6f, 0x3, &ldo_v1},
+   {S5M8767_LDO18, 0x70, 0x0, 0x3f, 0x70

Re: [U-Boot] [PATCH 22/55] dm: power: Add support for TPS65090 FETs

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:15 AM, Simon Glass wrote:

The TPS65090 has 7 FETs which are modelled as regulators. This allows them
to be controlled by drivers easier, accessed through the 'regulator' command
and used by other drivers.

Signed-off-by: Simon Glass 
---

  drivers/power/regulator/Kconfig  |  10 ++
  drivers/power/regulator/Makefile |   1 +
  drivers/power/regulator/tps65090_regulator.c | 138 +++
  3 files changed, 149 insertions(+)
  create mode 100644 drivers/power/regulator/tps65090_regulator.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 6289b83..d090650 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -61,3 +61,13 @@ config DM_REGULATOR_SANDBOX

A detailed information can be found in header: ''
Binding info: 'doc/device-tree-bindings/pmic/max77686.txt'
+
+config REGULATOR_TPS65090
+   bool "Enable driver for TPS65090 PMIC regulators"
+   depends on PMIC_TPS65090
+   ---help---
+   The TPS65090 provides several FETs (Field-effect Transistors,
+   effectively switches) which are supported by this driver as
+   regulators, one for each FET. The standard regulator interface is
+   supported, but it is only possible to turn the regulators on or off.
+   There is no voltage/current control.
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 96aa624..43f4d2c 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_DM_REGULATOR) += regulator-uclass.o
  obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
  obj-$(CONFIG_DM_REGULATOR_FIXED) += fixed.o
  obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
+obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o
diff --git a/drivers/power/regulator/tps65090_regulator.c 
b/drivers/power/regulator/tps65090_regulator.c
new file mode 100644
index 000..affc504
--- /dev/null
+++ b/drivers/power/regulator/tps65090_regulator.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int tps65090_fet_probe(struct udevice *dev)
+{
+   struct dm_regulator_uclass_platdata *uc_pdata;
+
+   uc_pdata = dev_get_uclass_platdata(dev);
+
+   uc_pdata->type = REGULATOR_TYPE_OTHER;
+   uc_pdata->mode_count = 0;
+
+   return 0;
+}
+
+static bool tps65090_fet_get_enable(struct udevice *dev)
+{
+   struct udevice *pmic = dev_get_parent(dev);
+   int ret, fet_id;
+
+   fet_id = dev->driver_data;
+   debug("%s: fet_id=%d\n", __func__, fet_id);
+
+   ret = pmic_reg_read(pmic, REG_FET_BASE + fet_id);
+   if (ret < 0)
+   return ret;
+
+   return ret & FET_CTRL_ENFET;
+}
+
+/**
+ * Set the power state for a FET
+ *
+ * @param pmic pmic structure for the tps65090
+ * @param fet_id   FET number to set (1..MAX_FET_NUM)
+ * @param set  1 to power on FET, 0 to power off
+ * @return -EIO if we got a comms error, -EAGAIN if the FET failed to
+ * change state. If all is ok, returns 0.
+ */
+static int tps65090_fet_set(struct udevice *pmic, int fet_id, bool set)
+{
+   int retry;
+   u32 value;
+   int ret;
+
+   value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
+   if (set)
+   value |= FET_CTRL_ENFET;
+
+   if (pmic_reg_write(pmic, REG_FET_BASE + fet_id, value))
+   return -EIO;
+
+   /* Try reading until we get a result */
+   for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
+   ret = pmic_reg_read(pmic, REG_FET_BASE + fet_id);
+   if (ret < 0)
+   return ret;
+
+   /* Check that the FET went into the expected state */
+   debug("%s: flags=%x\n", __func__, ret);
+   if (!!(ret & FET_CTRL_PGFET) == set)
+   return 0;
+
+   /* If we got a timeout, there is no point in waiting longer */
+   if (ret & FET_CTRL_TOFET)
+   break;
+
+   mdelay(1);
+   }
+
+   debug("FET %d: Power good should have set to %d but reg=%#02x\n",
+ fet_id, set, ret);
+   return -EAGAIN;
+}
+
+static int tps65090_fet_set_enable(struct udevice *dev, bool enable)
+{
+   struct udevice *pmic = dev_get_parent(dev);
+   int ret, fet_id;
+   ulong start;
+   int loops;
+
+   fet_id = dev->driver_data;
+   debug("%s: fet_id=%d, enable=%d\n", __func__, fet_id, enable);
+
+   start = get_timer(0);
+   for (loops = 0;; loops++) {
+   ret = tps65090_fet_set(pmic, fet_id, enable);
+   if (!ret)
+   break;
+
+   if (get_timer(start) > 100)
+   break;
+
+   /* Turn it off and try again until we time out */
+  

Re: [U-Boot] [PATCH 21/55] dm: power: Add a new driver for the TPS65090 PMIC

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:15 AM, Simon Glass wrote:

The existing TPS65090 driver does not support driver model. Add a new one
that does. This can be used as a base for a regulator driver also. It uses
the standard device tree binding.

Signed-off-by: Simon Glass 
---

  drivers/power/pmic/Kconfig|  9 +
  drivers/power/pmic/Makefile   |  1 +
  drivers/power/pmic/tps65090.c | 94 +++
  include/power/tps65090.h  | 56 ++
  4 files changed, 160 insertions(+)
  create mode 100644 drivers/power/pmic/tps65090.c
  create mode 100644 include/power/tps65090.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 164f421..fd8af81 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -41,3 +41,12 @@ config DM_PMIC_SANDBOX
  - set by i2c emul driver's probe() (defaults in header)

Driver binding info: doc/device-tree-bindings/pmic/sandbox.txt
+
+config PMIC_TPS65090
+   bool "Enable driver for Texas Instruments TPS65090 PMIC"
+   depends on DM_PMIC
+   ---help---
+   The TPS65090 is a PMIC containing several LDOs, DC to DC convertors,
+   FETs and a battery charger. This driver provides register access
+   only, and you can enable the regulator/charger drivers separately if
+   required.
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index ae86f04..2316e3b 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -8,6 +8,7 @@
  obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
  obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
  obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
+obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
  obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
  obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
  obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
diff --git a/drivers/power/pmic/tps65090.c b/drivers/power/pmic/tps65090.c
new file mode 100644
index 000..4797f32
--- /dev/null
+++ b/drivers/power/pmic/tps65090.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ * Written by Simon Glass 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+   { .prefix = "fet", .driver = TPS65090_FET_DRIVER },
+   { },
+};
+
+static int tps65090_reg_count(struct udevice *dev)
+{
+   return TPS65090_NUM_REGS;
+}
+
+static int tps65090_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+   if (dm_i2c_write(dev, reg, buff, len)) {
+   error("write error to device: %p register: %#x!", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int tps65090_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   int ret;
+
+   ret = dm_i2c_read(dev, reg, buff, len);
+   if (ret) {
+   error("read error %d from device: %p register: %#x!", ret, dev,
+ reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int tps65090_bind(struct udevice *dev)
+{
+   int regulators_node;
+   const void *blob = gd->fdt_blob;
+   int children;
+
+   regulators_node = fdt_subnode_offset(blob, dev->of_offset,
+"regulators");
+   if (regulators_node <= 0) {
+   debug("%s: %s regulators subnode not found!", __func__,
+ dev->name);
+   return -ENXIO;
+   }
+
+   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
+
+   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+   if (!children)
+   debug("%s: %s - no child found\n", __func__, dev->name);
+
+   /* Always return success for this device */
+   return 0;
+}
+
+static struct dm_pmic_ops tps65090_ops = {
+   .reg_count = tps65090_reg_count,
+   .read = tps65090_read,
+   .write = tps65090_write,
+};
+
+static const struct udevice_id tps65090_ids[] = {
+   { .compatible = "ti,tps65090" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_tps65090) = {
+   .name = "tps65090 pmic",
+   .id = UCLASS_PMIC,
+   .of_match = tps65090_ids,
+   .bind = tps65090_bind,
+   .ops = &tps65090_ops,
+};
diff --git a/include/power/tps65090.h b/include/power/tps65090.h
new file mode 100644
index 000..3a0690b
--- /dev/null
+++ b/include/power/tps65090.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ * Written by Simon Glass 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __TPS65090_PMIC_H_
+#define __TPS65090_PMIC_H_
+
+/* I2C device address for TPS65090 PMU */
+#define TPS65090_I2C_ADDR  0x48
+
+/* TPS65090 register addresses */
+enum {
+   REG_IRQ1 = 0,
+   REG_CG_CTRL0 = 4,
+   REG_CG_STATUS1 = 0xa,
+   REG_FET_BASE 

Re: [U-Boot] [PATCH 12/55] exynos: dts: Add PMIC and regulator definitions

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:15 AM, Simon Glass wrote:

Snow and smdk5250 use a max77686 PMIC. We have a driver for this, so add
the relevant node to the device tree so it can be used.

Signed-off-by: Simon Glass 
---

  arch/arm/dts/exynos5250-smdk5250.dts | 150 ++
  arch/arm/dts/exynos5250-snow.dts | 154 +++
  2 files changed, 304 insertions(+)

diff --git a/arch/arm/dts/exynos5250-smdk5250.dts 
b/arch/arm/dts/exynos5250-smdk5250.dts
index 636fec9..8b69544 100644
--- a/arch/arm/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/dts/exynos5250-smdk5250.dts
@@ -150,3 +150,153 @@
samsung,vbus-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
};
  };
+
+&i2c_0 {
+   status = "okay";
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <2>;
+
+   max77686@09 {
+   compatible = "maxim,max77686";
+   reg = <0x09>;


Are those two properties below, required? (The same for snow dts)


+   interrupt-parent = <&gpx3>;
+   interrupts = <2 IRQ_TYPE_NONE>;
+
+   voltage-regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "P1.0V_LDO_OUT1";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   regulator-always-on;
+   };


...snip...

Acked-by: Przemyslaw Marczak 

Best regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 11/55] exynos: dts: Sync up I2C ports with the kernel

[Przemyslaw Marczak]

Hello Simon,

On 07/03/2015 02:15 AM, Simon Glass wrote:

The kernel uses upper case for I2C unit addresses. Follow the same
convention to reduce differences.

Signed-off-by: Simon Glass 
---

  arch/arm/dts/exynos5.dtsi | 34 -
  arch/arm/dts/exynos5250-arndale.dts   | 16 
  arch/arm/dts/exynos5250-smdk5250.dts  | 21 ++--
  arch/arm/dts/exynos5250-snow.dts  | 32 +--
  arch/arm/dts/exynos5250.dtsi  | 24 +++
  arch/arm/dts/exynos5420-peach-pit.dts |  8 
  arch/arm/dts/exynos5420-smdk5420.dts  |  4 ++--
  arch/arm/dts/exynos54xx.dtsi  | 36 +--
  arch/arm/dts/exynos5800-peach-pi.dts  |  8 
  9 files changed, 94 insertions(+), 89 deletions(-)

diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi
index 238acb8..179584c 100644
--- a/arch/arm/dts/exynos5.dtsi
+++ b/arch/arm/dts/exynos5.dtsi
@@ -72,39 +72,39 @@
interrupts = <1 9 0xf04>;
};

-   i2c@12c6 {
-   #address-cells = <1>;
-   #size-cells = <0>;
+   i2c_0: i2c@12C6 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C6 0x100>;
interrupts = <0 56 0>;
-   };
-
-   i2c@12c7 {
#address-cells = <1>;
#size-cells = <0>;
+   };
+
+   i2c_1: i2c@12C7 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C7 0x100>;
interrupts = <0 57 0>;
-   };
-
-   i2c@12c8 {
#address-cells = <1>;
#size-cells = <0>;
+   };
+
+   i2c_2: i2c@12C8 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C8 0x100>;
interrupts = <0 58 0>;
-   };
-
-   i2c@12c9 {
#address-cells = <1>;
#size-cells = <0>;
+   };
+
+   i2c_3: i2c@12C9 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C9 0x100>;
interrupts = <0 59 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
};

-   spi@12d2 {
+   spi_0: spi@12d2 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,exynos-spi";
@@ -112,7 +112,7 @@
interrupts = <0 68 0>;
};

-   spi@12d3 {
+   spi_1: spi@12d3 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,exynos-spi";
@@ -120,7 +120,7 @@
interrupts = <0 69 0>;
};

-   spi@12d4 {
+   spi_2: spi@12d4 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,exynos-spi";
@@ -129,7 +129,7 @@
interrupts = <0 70 0>;
  };

-   spi@131a {
+   spi_3: spi@131a {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,exynos-spi";
@@ -137,7 +137,7 @@
interrupts = <0 129 0>;
};

-   spi@131b {
+   spi_4: spi@131b {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,exynos-spi";
diff --git a/arch/arm/dts/exynos5250-arndale.dts 
b/arch/arm/dts/exynos5250-arndale.dts
index 21c0a21..031c622 100644
--- a/arch/arm/dts/exynos5250-arndale.dts
+++ b/arch/arm/dts/exynos5250-arndale.dts
@@ -15,14 +15,14 @@
compatible = "samsung,arndale", "samsung,exynos5250";

aliases {
-   i2c0 = "/i2c@12c6";
-   i2c1 = "/i2c@12c7";
-   i2c2 = "/i2c@12c8";
-   i2c3 = "/i2c@12c9";
-   i2c4 = "/i2c@12ca";
-   i2c5 = "/i2c@12cb";
-   i2c6 = "/i2c@12cc";
-   i2c7 = "/i2c@12cd";
+   i2c0 = "/i2c@12C6";
+   i2c1 = "/i2c@12C7";
+   i2c2 = "/i2c@12C8";
+   i2c3 = "/i2c@12C9";
+   i2c4 = "/i2c@12CA";
+   i2c5 = "/i2c@12CB";
+   i2c6 = "/i2c@12CC";
+   i2c7 = "/i2c@12CD";
serial0 = "/serial@12C2";
console = "/serial@12C2";
};
diff --git a/arch/arm/dts/exynos5250-smdk5250.dts 
b/arch/arm/dts/exynos5250-smdk5250.dts
index 3cebfc2..636fec9 100644
--- a/arch/arm/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/dts/exynos5250-smdk5250.dts
@@ -11,20 +11,21 @@

  /dts-v1/;
  #include "exynos5250.dtsi"
+#include 

  / {
model = "SAMSUNG SMDK5250 board based on EXYNOS5250";
compatible = "samsung,smdk5250", "samsung,exynos5250";

aliases {
-   i2c0 = "/i2c@12c6";
-   i2c1 = "/i2c@12c7

Re: [U-Boot] [PATCH] RFC: dm: Add pointer checking for allocated data

[Albert ARIBAUD]

Hello Simon,

On Thu,  9 Jul 2015 08:15:51 -0600, Simon Glass 
wrote:
> With driver model drivers can have things stored in several places. There is
> driver-private data, then the uclass can attach things to a device. If the
> device is on a bus then its bus may attach parent data to the device too.
> 
> At present everything is done through void pointers. It would be nice to
> have a way to check that the correct C struct is used in each case.
> 
> Here is a proposed implementation of a way of checking structures in driver
> model. It relies on turning the existing dev_get_priv() function into a
> macro which (if checking is enabled) checks that the structure names match.
> Each xxx_auto_alloc_size turns into a structure containing a string (the
> structure name) and the size.
> 
> The dev_get_priv() macro has an extra parameter which is the structure being
> accessed:
> 
>   struct eth_pdata *priv = dev_get_priv(dev, struct eth_pdata);
> 
> and you get an error like this when things are wrong:
> 
> Invalid access to device priv: dev=eth@10002000, expecting
>'struct eth_sandbox_priv', requested 'struct eth_pdata'

'Requested' seems too synonymous to 'expecting' for me.

> A new Kconfg option is added to turn this on, since it bloats the code a
> little.

Sounds like some kind of RTTI to me. Do we really need this? Can we not
check this at build time ? (for both answers -- which I assume will be
"yes" and "no" respectively -- a concrete example would be welcome to
help me figure out what the specific issue is, as opposed to generic
C type casting issues).

Plus, IIUC, a mismatch warning is pretty much an indication that things
have gone Horribly Wrong -- which makes the feature sound like a debug
helper to me, see below.

> The next step would be to extend it to all pointers in the device and
> uclass. This is mostly a mechanical code change.
> 
> Finally we should have a way of checking that the device pointer itself is
> valid. For example if someone passes an invalid address like 0x12345 as the
> 'struct udevice' then at present we will dutifully look for the devices'
> driver and perform an invalid memory access.
> 
> If we want to check for memory corruption one way would be to add a magic
> numnber before each allocated memory area. Perhaps this is more the role
> of dlmalloc(), but if required it could be attached to Masahiro's devres
> feature, which already prepends some data to every allocated area.

Sounds like a debug helper to me, as when a corrupt pointer is
detected, there is not much you can do but whine about it on the
console (assuming the faulty pointer won't kill the console).

> Comments welcome. I'd like to figure this out soon as it involves trivial
> but invasive patches to change each driver.

If, as I believe they are, both feature above are debug helpers,
then I would suggest that we organize them and other debug helpers)
under the general 'DEBUG' option, with a sub-option for each helper,
like 'DEBUG_DRIVER_STRUCTS' and 'DEBUG_ALLOCS'. This could also help
organize debug messages, e.g. DEBUG_LOG, DEBUG_LOG_USB, DEBUG_LOG_ENV,
etc.

That would make a central point where developers could find (hopefully
documented) debug features, enable and disable them easily (I am
thinking about those development environment with 'release' vs 'debug'
builds) and which would become a natural landing point for new debugging
features.

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

Re: [U-Boot] [PATCH V4 1/6] imx: add dummpy cpu type MXC_CPU_MX6QP/DP

[Peng Fan]

Hi Stefano,

On Fri, Jul 10, 2015 at 10:30:59AM +0200, Stefano Babic wrote:
>Hi Peng,
>
>in the title "dummpy" instead of "dummy".

Thanks pointing this out.

>
>On 30/06/2015 04:36, Peng Fan wrote:
>> Add dummy cpu type MXC_CPU_MX6QP/DP.
>
>Anyway, why is it dummy ? It matches a real SOC, only the check is done
>in another way.

Just like MXC_CPU_MX6Q and MXC_CPU_MX6D. MXC_CPU_MX6D is a dummy id,
MXC_CPU_MX6Q is the real id. Same MXC_CPU_MX6QP/DP are also dummy id.
Since I want to print correct CPU info, so I use this way, but not
change arch/arm/imx-common/cpu.c.

>
>> Since i.MX6QP use a revision 2, but with
>> cpu type i.MX6Q, we need the MXC_CPU_MX6QP and to decrease major with 1 to
>> let print_cpuinfo print the correct info.
>
>I understand well the code, not so well the text here. Maybe does it
>help simply to write that MX6 with MAJOR_LOWER >= 2 are plus ?
>
Only for 6QP/DP. Not for all MX6 with MAJOR_LOWER >= 1.

>> 
>> This patch also fix is_mx6dqp(), since get_cpu_rev can return MXC_CPU_MX6QP
>> and MXC_CPU_MX6DP, we should use:
>> (is_cpu_type(MXC_CPU_MX6QP) || is_cpu_type(MXC_CPU_MX6DP)).
>> 
>> Signed-off-by: Peng Fan 
>> ---
>> 
>> Changes v4:
>>  Address Fabio's comments, Change Quad-Plus to Dual-Plus for i.MX6DP.
>> 
>> Changes v3:
>>  New patch
>>  This patch is to make print_cpuinfo display correct cpu info, also fix
>>  is_mx6dqp
>> 
>> Changes v2:
>>  none
>> 
>>  arch/arm/cpu/armv7/mx6/soc.c  | 11 +--
>>  arch/arm/imx-common/cpu.c |  4 
>>  arch/arm/include/asm/arch-imx/cpu.h   |  2 ++
>>  arch/arm/include/asm/arch-mx6/sys_proto.h |  4 +---
>>  4 files changed, 16 insertions(+), 5 deletions(-)
>> 
>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>> index 29de624..d3a3b2e 100644
>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>> @@ -62,12 +62,12 @@ u32 get_cpu_rev(void)
>>  struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
>>  u32 reg = readl(&anatop->digprog_sololite);
>>  u32 type = ((reg >> 16) & 0xff);
>> -u32 major;
>> +u32 major, cfg = 0;
>>  
>>  if (type != MXC_CPU_MX6SL) {
>>  reg = readl(&anatop->digprog);
>>  struct scu_regs *scu = (struct scu_regs *)SCU_BASE_ADDR;
>> -u32 cfg = readl(&scu->config) & 3;
>> +cfg = readl(&scu->config) & 3;
>>  type = ((reg >> 16) & 0xff);
>>  if (type == MXC_CPU_MX6DL) {
>>  if (!cfg)
>> @@ -81,6 +81,13 @@ u32 get_cpu_rev(void)
>>  
>>  }
>>  major = ((reg >> 8) & 0xff);
>> +if ((major >= 1) &&
>
>Everything fine, but I have not understood this line, please help me.
>major is the revision number and should be at least 2 for a QP or DP.
>But you check that it can be >=, that is revision 1.x is accepted as
>Plus. Or am I wrong ?

To i.MX6, MAJOR_LOWER is from 0,1,2... maybe larger.
I have no knowledge whether major_lower with 2,3,4... is also called DQPlus.
6QP/DP is major_lower >= 1, major_lower 0 is for 6DQ. Now ">= 1" can work
for 6QP/DP, just check "== 1" may not a good idea.

Is this clear to explain why this patch?

The reason for this patch is to print correct cpuinfo:

printf("CPU:   Freescale i.MX%s rev%d.%d",
   get_imx_type((cpurev & 0xFF000) >> 12),
   (cpurev & 0x000F0) >> 4,
   (cpurev & 0xF) >> 0);

As Fabio's comments, should print i.MX6QP 1.0, but i.MX6Q rev2.0.

>
>> +((type == MXC_CPU_MX6Q) || (type == MXC_CPU_MX6D))) {
>> +major--;
>> +type = MXC_CPU_MX6QP;
>> +if (cfg == 1)
>> +type = MXC_CPU_MX6DP;
>> +}
>>  reg &= 0xff;/* mx6 silicon revision */
>>  return (type << 12) | (reg + (0x10 * (major + 1)));
>>  }
>> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>> index 5e56cfe..096d22e 100644
>> --- a/arch/arm/imx-common/cpu.c
>> +++ b/arch/arm/imx-common/cpu.c
>> @@ -122,6 +122,10 @@ unsigned imx_ddr_size(void)
>>  const char *get_imx_type(u32 imxtype)
>>  {
>>  switch (imxtype) {
>> +case MXC_CPU_MX6QP:
>> +return "6QP";   /* Quad-Plus version of the mx6 */
>> +case MXC_CPU_MX6DP:
>> +return "6DP";   /* Dual-Plus version of the mx6 */
>>  case MXC_CPU_MX6Q:
>>  return "6Q";/* Quad-core version of the mx6 */
>>  case MXC_CPU_MX6D:
>> diff --git a/arch/arm/include/asm/arch-imx/cpu.h 
>> b/arch/arm/include/asm/arch-imx/cpu.h
>> index 4715f4e..99e0e32 100644
>> --- a/arch/arm/include/asm/arch-imx/cpu.h
>> +++ b/arch/arm/include/asm/arch-imx/cpu.h
>> @@ -12,6 +12,8 @@
>>  #define MXC_CPU_MX6Q0x63
>>  #define MXC_CPU_MX6D0x64
>>  #define MXC_CPU_MX6SOLO 0x65 /* dummy ID */
>> +#define MXC_CPU_MX6DP   0x68
>> +#define MXC_CPU_MX6QP   0x69
>>  
>>  #define CS0_128 0
>>  #define CS0_64M_CS1_64M

Re: [U-Boot] [PATCH 07/55] exynos: i2c: Correct bug in pinmux selection

[Przemyslaw Marczak]

Hello,

On 07/10/2015 03:46 AM, Simon Glass wrote:

Hi Minkyu,

On 9 July 2015 at 19:43, Minkyu Kang  wrote:

Hi Simon,

On 08/07/15 11:38, Simon Glass wrote:

Hi Minkyu,

On 6 July 2015 at 19:36, Minkyu Kang  wrote:

Dear Simon,

On 07/07/15 00:27, Simon Glass wrote:

Hi Minkyu, Przemyslaw,

On 5 July 2015 at 00:15, Heiko Schocher  wrote:

Hello Simon,

Am 03.07.2015 um 02:15 schrieb Simon Glass:


When driver model is not used the current code does not correctly select
the pinmux for the I2C bus. This bug was introduced by this commit:

8dfcbaa dm: i2c: s3c24x0: adjust to dm-i2c api

Signed-off-by: Simon Glass 
---

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



Acked-by: Heiko Schocher 

As it is a bugfix, this should go in the current release ... right?


Minkyu, are you able to pick this up please? If not I can do it.



Only this patch? or all of samsung related patches?


Yes only this patch. It has been confirmed my Przemyslaw now too.



OK.
then, do you want to take other patches to your tree?


There are still dependencies on u-boot-dm, so I cannot yet. But if you
like I can do that later, after I have merged some more driver model
support patches.

Regards,
Simon



Simon, please wait a moment with merge the patchset.
I will send a few comments today.

Regards
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] hang: ARM64/Relocating u-boot from u-boot

[Albert ARIBAUD]

Hello Wolfgang,

On Thu, 09 Jul 2015 22:38:48 +0200, Wolfgang Denk  wrote:
> Dear Albert,
> 
> In message <20150708084625.5a18e9a5@lilith> you wrote:
> > 
> > > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
> > 
> > If I may, this FAQ is slightly outdated, in that chainloading U-Boot is
> > not only possible but actually made possible by design, at least for
> > many ARM (and possibly some ARM64) targets, and I suspect for many
> > non-ARM targets too, as long as they use SPL.
> 
> I agree that the documentation could need some dditional explanations,
> but it is not exactly outdated nor incorrect.
> 
> > First off: the FAQ is perfectly true if applied to running SPL from
> > SPL.
> 
> Right.  This is the part that needs to be explained:  You cannot (at
> least not in general, there are always some exceptions) run the code
> that is supposed to "run first" again from an already running U-Boot.
> 
> With Non-SPL versions this is the plain U-Boot binary, with SPL it's
> the SPL, etc.
> 
> > IOW, on targets with SPL, U-Boot starts with the guarantee that all
> > initializations needed for external RAM to work have been done, and
> > it guarantees that it will not perform these external RAM inits again.
> 
> This is true, but not always sufficient.  There may still be
> initializations that cannot be done again.
> 
> > And since an SPL-chainloaded U-Boot runs with external already
> > initialized and does not initialize it again, it follows that this
> > U-Boot is a valid environment for running another instance of itself,
> > provided the new instance and current instances do not overwrite each
> > other.
> 
> This is often the case, but not necessarily always.  There are systems
> with components that can be initialized just once after a reset - for
> example, the watchdog on some systems.  If your first U-Boot
> configures the watchdog on such a system to run, and you try and load
> another U-Boot image which tries to disable the watchdog, it will not
> work, and the new U-Boot will crash as it fails to trigger toe
> watchdog.
> 
> > All of this makes it nont only perfectly possible for (SPL-run) U-Boot
> > to chainload (SPL-run) U-Boot, it pretty much guarantees it.
> 
> The point is, this guarantee is a one-time-only guarantee.  There is
> no guarantee that you can do exactly the same twice, without a reset
> inbetween.
> 
> Yes, I agree, it will just work in most of the cases.  But this is
> _not_ guaranteed, and we should at least warn potential users of such
> methods that they really have to understand _exactly_ what they are
> doing, and even if it's working now it may be broken in the next
> version of U-Boot.
> 
> > (on an OT note, I'd even say that a SPL-supported U-Bot which cannot
> > chainload itself probably does not completely and/or properly reset the
> > hardware into booting condition, but that's slightly beside the point.)
> 
> Not all hardware can be reset by software actions alone.  There are
> things like write-once registers.  Once written, you MUST perform a
> reset to write any different values.

All of the above is right: there is no 100% guarantee that this will
work, not even "close-enough" guarantee; and yes, there is hardware out
there that is write-once-per-power-cycle, which may or may not prevent
resetting it to a known state.

> > Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader
> > cases?
> 
> It's a wiki, all contributions are welcome.

OK -- I was not so much asking for someone to do it than asking whether
the general direction of the proposed edit would be fine. :)

> Best regards,
> 
> Wolfgang Denk

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

Re: [U-Boot] [PATCH 1/2][V2] pci: Add function to find an extended capability

[Bin Meng]

On Fri, Jul 10, 2015 at 11:35 AM, Minghuan Lian
 wrote:
> PCIe extends device's configuration space to 4k and provides
> extended capability. The patch adds function to find them.
> The code is ported from Linux PCIe driver.
>
> Signed-off-by: Minghuan Lian 
> ---
> Change log:
> v2-v1:
> 1. add a descriptor of pci_find_next_ext_capability
> 2. fix a typo
>
>  drivers/pci/pci.c | 53 +
>  include/pci.h | 41 +
>  2 files changed, 94 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 157491c..df50b48 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -526,3 +526,56 @@ int pci_find_cap(struct pci_controller *hose, pci_dev_t 
> dev, int pos, int cap)
> }
> return 0;
>  }
> +
> +/**
> + * pci_find_next_ext_capability - Find an extended capability
> + *
> + * Returns the address of the next matching extended capability structure
> + * within the device's PCI configuration space or 0 if the device does
> + * not support it.  Some capabilities can occur several times, e.g., the
> + * vendor-specific capability, and this provides a way to find them all.
> + */
> +int pci_find_next_ext_capability(struct pci_controller *hose, pci_dev_t dev,
> +int start, int cap)
> +{
> +   u32 header;
> +   int ttl, pos = PCI_CFG_SPACE_SIZE;
> +
> +   /* minimum 8 bytes per capability */
> +   ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
> +
> +   if (start)
> +   pos = start;
> +
> +   pci_hose_read_config_dword(hose, dev, pos, &header);
> +   if (header == 0x || header == 0)
> +   return 0;
> +
> +   while (ttl-- > 0) {
> +   if (PCI_EXT_CAP_ID(header) == cap && pos != start)
> +   return pos;
> +
> +   pos = PCI_EXT_CAP_NEXT(header);
> +   if (pos < PCI_CFG_SPACE_SIZE)
> +   break;
> +
> +   pci_hose_read_config_dword(hose, dev, pos, &header);
> +   if (header == 0x || header == 0)
> +   break;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * pci_hose_find_ext_capability - Find an extended capability
> + *
> + * Returns the address of the requested extended capability structure
> + * within the device's PCI configuration space or 0 if the device does
> + * not support it.
> + */
> +int pci_hose_find_ext_capability(struct pci_controller *hose, pci_dev_t dev,
> +int cap)
> +{
> +   return pci_find_next_ext_capability(hose, dev, 0, cap);
> +}
> diff --git a/include/pci.h b/include/pci.h
> index 07b1e9a..2f88714 100644
> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -11,6 +11,9 @@
>  #ifndef _PCI_H
>  #define _PCI_H
>
> +#define PCI_CFG_SPACE_SIZE 256
> +#define PCI_CFG_SPACE_EXP_SIZE 4096
> +
>  /*
>   * Under PCI, each device has 256 bytes of configuration address space,
>   * of which the first 64 bytes are standardized as follows:
> @@ -413,6 +416,39 @@
>  #define PCI_FIND_CAP_TTL 0x48
>  #define CAP_START_POS 0x40
>
> +/* Extended Capabilities (PCI-X 2.0 and Express) */
> +#define PCI_EXT_CAP_ID(header) (header & 0x)
> +#define PCI_EXT_CAP_VER(header)((header >> 16) & 0xf)
> +#define PCI_EXT_CAP_NEXT(header)   ((header >> 20) & 0xffc)
> +
> +#define PCI_EXT_CAP_ID_ERR 0x01/* Advanced Error Reporting */
> +#define PCI_EXT_CAP_ID_VC  0x02/* Virtual Channel Capability */
> +#define PCI_EXT_CAP_ID_DSN 0x03/* Device Serial Number */
> +#define PCI_EXT_CAP_ID_PWR 0x04/* Power Budgeting */
> +#define PCI_EXT_CAP_ID_RCLD0x05/* Root Complex Link Declaration */
> +#define PCI_EXT_CAP_ID_RCILC   0x06/* Root Complex Internal Link Control 
> */
> +#define PCI_EXT_CAP_ID_RCEC0x07/* Root Complex Event Collector */
> +#define PCI_EXT_CAP_ID_MFVC0x08/* Multi-Function VC Capability */
> +#define PCI_EXT_CAP_ID_VC9 0x09/* same as _VC */
> +#define PCI_EXT_CAP_ID_RCRB0x0A/* Root Complex RB? */
> +#define PCI_EXT_CAP_ID_VNDR0x0B/* Vendor-Specific */
> +#define PCI_EXT_CAP_ID_CAC 0x0C/* Config Access - obsolete */
> +#define PCI_EXT_CAP_ID_ACS 0x0D/* Access Control Services */
> +#define PCI_EXT_CAP_ID_ARI 0x0E/* Alternate Routing ID */
> +#define PCI_EXT_CAP_ID_ATS 0x0F/* Address Translation Services */
> +#define PCI_EXT_CAP_ID_SRIOV   0x10/* Single Root I/O Virtualization */
> +#define PCI_EXT_CAP_ID_MRIOV   0x11/* Multi Root I/O Virtualization */
> +#define PCI_EXT_CAP_ID_MCAST   0x12/* Multicast */
> +#define PCI_EXT_CAP_ID_PRI 0x13/* Page Request Interface */
> +#define PCI_EXT_CAP_ID_AMD_XXX 0x14/* Reserved for AMD */
> +#define PCI_EXT_CAP_ID_REBAR   0x15/* Resizable BAR */
> +#define PCI_EXT_CAP_ID_DPA 0x16/* Dynamic Power Alloca

Re: [U-Boot] [PATCH V4 5/6] imx: mx6sabresd/sabreauto runtime setting fdt_file

[Stefano Babic]

On 30/06/2015 04:36, Peng Fan wrote:
> Detect the SOC and board variant at runtime and change the dtb name,
> but not hardcoding the fdt_file env variable.
> 
> Take the following patch as a reference.
> Íd58699b157df75f1aa0b363ea9c21add21a0c
> "mx6cuboxi: Load the correct 'fdtfile' variable"
> 
> Signed-off-by: Peng Fan 
> Reviewed-by: Fabio Estevam 
> ---
> 
> Changes v4:
>  Add Fabio's Reviewed-by
> Changes v3:
>  New patch
> Changes v2:
>  none
> 
>  board/freescale/mx6qsabreauto/mx6qsabreauto.c |  9 +
>  board/freescale/mx6sabresd/mx6sabresd.c   | 10 ++
>  include/configs/mx6qsabreauto.h   |  5 -
>  include/configs/mx6sabre_common.h | 21 +++--
>  include/configs/mx6sabresd.h  |  5 -
>  5 files changed, 38 insertions(+), 12 deletions(-)
> 
> diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
> b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> index b76e4eb..943a4bd 100644
> --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> @@ -522,6 +522,15 @@ int board_late_init(void)
>   add_board_boot_modes(board_boot_modes);
>  #endif
>  
> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> + setenv("board_name", "SABREAUTO");
> +
> + if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> + setenv("board_rev", "MX6Q");
> + else if (is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO))
> + setenv("board_rev", "MX6DL");
> +#endif
> +
>   return 0;
>  }
>  
> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
> b/board/freescale/mx6sabresd/mx6sabresd.c
> index 23f8f6b..4f0694a 100644
> --- a/board/freescale/mx6sabresd/mx6sabresd.c
> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
> @@ -679,6 +679,16 @@ int board_late_init(void)
>  #ifdef CONFIG_CMD_BMODE
>   add_board_boot_modes(board_boot_modes);
>  #endif
> +
> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> + setenv("board_name", "SABRESD");
> +
> + if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> + setenv("board_rev", "MX6Q");
> + else if (is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO))
> + setenv("board_rev", "MX6DL");
> +#endif
> +
>   return 0;
>  }
>  
> diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
> index 2260344..11cf538 100644
> --- a/include/configs/mx6qsabreauto.h
> +++ b/include/configs/mx6qsabreauto.h
> @@ -12,11 +12,6 @@
>  #define CONFIG_MACH_TYPE 3529
>  #define CONFIG_MXC_UART_BASE UART4_BASE
>  #define CONFIG_CONSOLE_DEV   "ttymxc3"
> -#if defined CONFIG_MX6Q
> -#define CONFIG_DEFAULT_FDT_FILE  "imx6q-sabreauto.dtb"
> -#elif defined CONFIG_MX6DL
> -#define CONFIG_DEFAULT_FDT_FILE  "imx6dl-sabreauto.dtb"
> -#endif
>  #define CONFIG_MMCROOT   "/dev/mmcblk0p2"
>  #define PHYS_SDRAM_SIZE  (2u * 1024 * 1024 * 1024)
>  
> diff --git a/include/configs/mx6sabre_common.h 
> b/include/configs/mx6sabre_common.h
> index c8c9f81..397ad7b 100644
> --- a/include/configs/mx6sabre_common.h
> +++ b/include/configs/mx6sabre_common.h
> @@ -76,10 +76,12 @@
>  #define EMMC_ENV ""
>  #endif
>  
> +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> +
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   "script=boot.scr\0" \
>   "image=zImage\0" \
> - "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
> + "fdt_file=undefined\0" \
>   "fdt_addr=0x1800\0" \
>   "boot_fdt=try\0" \
>   "ip_dyn=yes\0" \
> @@ -149,9 +151,24 @@
>   "fi; " \
>   "else " \
>   "bootz; " \
> - "fi;\0"
> + "fi;\0" \
> + "findfdt="\
> + "if test $fdt_file = undefined; then " \
> + "if test $board_name = SABREAUTO && test 
> $board_rev = MX6Q; then " \
> + "setenv fdt_file imx6q-sabreauto.dtb; 
> fi; " \
> + "if test $board_name = SABREAUTO && test 
> $board_rev = MX6DL; then " \
> + "setenv fdt_file imx6dl-sabreauto.dtb; 
> fi; " \
> + "if test $board_name = SABRESD && test 
> $board_rev = MX6Q; then " \
> + "setenv fdt_file imx6q-sabresd.dtb; fi; 
> " \
> + "if test $board_name = SABRESD && test 
> $board_rev = MX6DL; then " \
> + "setenv fdt_file imx6dl-sabresd.dtb; 
> fi; " \
> + "if test $fdt_file = undefined; then " \
> + "echo WARNING: Could not determine dtb 
> to use; fi; " \
> + "fi;\0" \
> +
>  
>  #define CONFIG_BOOTCOMMAND \
> + "run findfdt;" \
>   "mmc dev ${mmcdev};" \
>   "if mmc rescan; then " \
>   "if run loadbootscript; then " \
> diff --git a/include/confi

Re: [U-Boot] [PATCH V4 4/6] imx: mx6qp Enable PRG clock for IPU

[Stefano Babic]

On 30/06/2015 04:36, Peng Fan wrote:
> The i.MX6DQP has a PRG module, need to enable its clock for using IPU.
> 
> Signed-off-by: Peng Fan 
> Signed-off-by: Brown Oliver 
> Signed-off-by: Ye.Li 
> Reviewed-by: Fabio Estevam 
> ---
> 
>  Changes v4:
>  Take Fabio's suggestion, use setbits_le32. Add Fabio's Reviewed-by
>  Changes v3:
>   Remove ipu qos settings
> 
>  Changes v2:
>   1. runtime check
>   2. introduce ipu qos settings for better performance
> 
>  arch/arm/cpu/armv7/mx6/clock.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index 446fe84..b7e714c 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -866,6 +866,11 @@ void enable_ipu_clock(void)
>   reg = readl(&mxc_ccm->CCGR3);
>   reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK;
>   writel(reg, &mxc_ccm->CCGR3);
> +
> + if (is_mx6dqp()) {
> + setbits_le32(&mxc_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
> + setbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
> + }
>  }
>  #endif
>  /***/
> 

Acked-by: Stefano Babic 

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 3/6] imx: mx6: hab : Remove the cache issue workaroud in hab for i.MX6QP

[Stefano Babic]

On 30/06/2015 04:36, Peng Fan wrote:
> From: "Ye.Li" 
> 
> Since the i.MX6QP has fixed the issue in boot ROM, so remove the workaround
> for i.MX6QP.
> 
> Signed-off-by: Ye.Li 
> Signed-off-by: Peng Fan 
> ---
> 
> Changes v4:
>  none
> Changes v3:
>  none
> Changes v2:
>  none
> 
>  arch/arm/cpu/armv7/mx6/hab.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
> index 8dee595..bf7dbf0 100644
> --- a/arch/arm/cpu/armv7/mx6/hab.c
> +++ b/arch/arm/cpu/armv7/mx6/hab.c
> @@ -252,7 +252,8 @@ uint32_t authenticate_image(uint32_t ddr_start, uint32_t 
> image_size)
>* do cache flushes. don't think any
>* exist, so we ignore them.
>*/
> - writel(1, MX6DQ_PU_IROM_MMU_EN_VAR);
> + if (!is_mx6dqp())
> + writel(1, 
> MX6DQ_PU_IROM_MMU_EN_VAR);
>   } else if (is_cpu_type(MXC_CPU_MX6DL) ||
>  is_cpu_type(MXC_CPU_MX6SOLO)) {
>   writel(1, MX6DLS_PU_IROM_MMU_EN_VAR);
> 

Acked-by: Stefano Babic 

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 2/6] imx: mx6: ccm: Change the clock settings for i.MX6QP

[Stefano Babic]

On 30/06/2015 04:36, Peng Fan wrote:
> Since i.MX6QP changes some CCM registers, so modify the clocks settings to
> follow the hardware changes.
> 
> In c files, use runtime check and discard #ifdef.
> 
> Signed-off-by: Ye.Li 
> Signed-off-by: Peng Fan 
> Reviewed-by: Fabio Estevam 
> ---
> 
> Changes v4:
>  Add Fabio's Reviewed-by
> 
> Changes v3:
>  Move bit definition to crm_regs.h.
> 
> Changes v2:
>   1. Remove #ifdef, but use runtime check
>   2. A few bit definitions are introduced in c files, because to other 
> platforms
>  the macro will make compilation fail, also there are no other places 
> refer
>  the bit macro definitions.
> 
>  arch/arm/cpu/armv7/mx6/clock.c   | 30 +---
>  arch/arm/cpu/armv7/mx6/soc.c |  5 +++-
>  arch/arm/include/asm/arch-mx6/crm_regs.h | 48 
> +---
>  3 files changed, 49 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index ae99945..446fe84 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -323,10 +323,12 @@ static u32 get_ipg_per_clk(void)
>   u32 reg, perclk_podf;
>  
>   reg = __raw_readl(&imx_ccm->cscmr1);
> -#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
> - if (reg & MXC_CCM_CSCMR1_PER_CLK_SEL_MASK)
> - return MXC_HCLK; /* OSC 24Mhz */
> -#endif
> + if (is_cpu_type(MXC_CPU_MX6SL) || is_cpu_type(MXC_CPU_MX6SX) ||
> + is_mx6dqp()) {
> + if (reg & MXC_CCM_CSCMR1_PER_CLK_SEL_MASK)
> + return MXC_HCLK; /* OSC 24Mhz */
> + }
> +
>   perclk_podf = reg & MXC_CCM_CSCMR1_PERCLK_PODF_MASK;
>  
>   return get_ipg_clk() / (perclk_podf + 1);
> @@ -337,10 +339,13 @@ static u32 get_uart_clk(void)
>   u32 reg, uart_podf;
>   u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
>   reg = __raw_readl(&imx_ccm->cscdr1);
> -#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
> - if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
> - freq = MXC_HCLK;
> -#endif
> +
> + if (is_cpu_type(MXC_CPU_MX6SL) || is_cpu_type(MXC_CPU_MX6SX) ||
> + is_mx6dqp()) {
> + if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
> + freq = MXC_HCLK;
> + }
> +
>   reg &= MXC_CCM_CSCDR1_UART_CLK_PODF_MASK;
>   uart_podf = reg >> MXC_CCM_CSCDR1_UART_CLK_PODF_OFFSET;
>  
> @@ -352,8 +357,13 @@ static u32 get_cspi_clk(void)
>   u32 reg, cspi_podf;
>  
>   reg = __raw_readl(&imx_ccm->cscdr2);
> - reg &= MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK;
> - cspi_podf = reg >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
> + cspi_podf = (reg & MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK) >>
> +  MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
> +
> + if (is_mx6dqp()) {
> + if (reg & MXC_CCM_CSCDR2_ECSPI_CLK_SEL_MASK)
> + return MXC_HCLK / (cspi_podf + 1);
> + }
>  
>   return  decode_pll(PLL_USBOTG, MXC_HCLK) / (8 * (cspi_podf + 1));
>  }
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index d3a3b2e..e80c09c 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -342,9 +342,12 @@ static void set_ahb_rate(u32 val)
>  static void clear_mmdc_ch_mask(void)
>  {
>   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> + u32 reg;
> + reg = readl(&mxc_ccm->ccdr);
>  
>   /* Clear MMDC channel mask */
> - writel(0, &mxc_ccm->ccdr);
> + reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
> + writel(reg, &mxc_ccm->ccdr);
>  }
>  
>  static void init_bandgap(void)
> diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
> b/arch/arm/include/asm/arch-mx6/crm_regs.h
> index 887d048..5bbf6e0 100644
> --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
> +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
> @@ -123,6 +123,8 @@ struct mxc_ccm_reg {
>  /* Define the bits in register CCDR */
>  #define MXC_CCM_CCDR_MMDC_CH1_HS_MASK(1 << 16)
>  #define MXC_CCM_CCDR_MMDC_CH0_HS_MASK(1 << 17)
> +/* Exists on i.MX6QP */
> +#define MXC_CCM_CCDR_MMDC_CH1_AXI_ROOT_CG(1 << 18)
>  
>  /* Define the bits in register CSR */
>  #define MXC_CCM_CSR_COSC_READY   (1 << 5)
> @@ -195,10 +197,8 @@ struct mxc_ccm_reg {
>  #define MXC_CCM_CBCMR_GPU3D_SHADER_CLK_SEL_OFFSET8
>  #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_MASK(0x3 << 4)
>  #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_OFFSET  4
> -#ifndef CONFIG_MX6SX
> -#define MXC_CCM_CBCMR_GPU3D_AXI_CLK_SEL  (1 << 1)
> -#define MXC_CCM_CBCMR_GPU2D_AXI_CLK_SEL  (1 << 0)
> -#endif
> +/* Exists on i.MX6QP */
> +#define MXC_CCM_CBCMR_PRE_CLK_SEL(1 << 1)
>  
>  /* Define the bits in register CSCMR1 */
>  #define MXC_CCM_CSCMR1_ACLK_EMI_SLOW_MASK  

Re: [U-Boot] [PATCH V4 1/6] imx: add dummpy cpu type MXC_CPU_MX6QP/DP

[Stefano Babic]

Hi Peng,

in the title "dummpy" instead of "dummy".

On 30/06/2015 04:36, Peng Fan wrote:
> Add dummy cpu type MXC_CPU_MX6QP/DP.

Anyway, why is it dummy ? It matches a real SOC, only the check is done
in another way.

> Since i.MX6QP use a revision 2, but with
> cpu type i.MX6Q, we need the MXC_CPU_MX6QP and to decrease major with 1 to
> let print_cpuinfo print the correct info.

I understand well the code, not so well the text here. Maybe does it
help simply to write that MX6 with MAJOR_LOWER >= 2 are plus ?

> 
> This patch also fix is_mx6dqp(), since get_cpu_rev can return MXC_CPU_MX6QP
> and MXC_CPU_MX6DP, we should use:
> (is_cpu_type(MXC_CPU_MX6QP) || is_cpu_type(MXC_CPU_MX6DP)).
> 
> Signed-off-by: Peng Fan 
> ---
> 
> Changes v4:
>  Address Fabio's comments, Change Quad-Plus to Dual-Plus for i.MX6DP.
> 
> Changes v3:
>  New patch
>  This patch is to make print_cpuinfo display correct cpu info, also fix
>  is_mx6dqp
> 
> Changes v2:
>  none
> 
>  arch/arm/cpu/armv7/mx6/soc.c  | 11 +--
>  arch/arm/imx-common/cpu.c |  4 
>  arch/arm/include/asm/arch-imx/cpu.h   |  2 ++
>  arch/arm/include/asm/arch-mx6/sys_proto.h |  4 +---
>  4 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 29de624..d3a3b2e 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -62,12 +62,12 @@ u32 get_cpu_rev(void)
>   struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
>   u32 reg = readl(&anatop->digprog_sololite);
>   u32 type = ((reg >> 16) & 0xff);
> - u32 major;
> + u32 major, cfg = 0;
>  
>   if (type != MXC_CPU_MX6SL) {
>   reg = readl(&anatop->digprog);
>   struct scu_regs *scu = (struct scu_regs *)SCU_BASE_ADDR;
> - u32 cfg = readl(&scu->config) & 3;
> + cfg = readl(&scu->config) & 3;
>   type = ((reg >> 16) & 0xff);
>   if (type == MXC_CPU_MX6DL) {
>   if (!cfg)
> @@ -81,6 +81,13 @@ u32 get_cpu_rev(void)
>  
>   }
>   major = ((reg >> 8) & 0xff);
> + if ((major >= 1) &&

Everything fine, but I have not understood this line, please help me.
major is the revision number and should be at least 2 for a QP or DP.
But you check that it can be >=, that is revision 1.x is accepted as
Plus. Or am I wrong ?

> + ((type == MXC_CPU_MX6Q) || (type == MXC_CPU_MX6D))) {
> + major--;
> + type = MXC_CPU_MX6QP;
> + if (cfg == 1)
> + type = MXC_CPU_MX6DP;
> + }
>   reg &= 0xff;/* mx6 silicon revision */
>   return (type << 12) | (reg + (0x10 * (major + 1)));
>  }
> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
> index 5e56cfe..096d22e 100644
> --- a/arch/arm/imx-common/cpu.c
> +++ b/arch/arm/imx-common/cpu.c
> @@ -122,6 +122,10 @@ unsigned imx_ddr_size(void)
>  const char *get_imx_type(u32 imxtype)
>  {
>   switch (imxtype) {
> + case MXC_CPU_MX6QP:
> + return "6QP";   /* Quad-Plus version of the mx6 */
> + case MXC_CPU_MX6DP:
> + return "6DP";   /* Dual-Plus version of the mx6 */
>   case MXC_CPU_MX6Q:
>   return "6Q";/* Quad-core version of the mx6 */
>   case MXC_CPU_MX6D:
> diff --git a/arch/arm/include/asm/arch-imx/cpu.h 
> b/arch/arm/include/asm/arch-imx/cpu.h
> index 4715f4e..99e0e32 100644
> --- a/arch/arm/include/asm/arch-imx/cpu.h
> +++ b/arch/arm/include/asm/arch-imx/cpu.h
> @@ -12,6 +12,8 @@
>  #define MXC_CPU_MX6Q 0x63
>  #define MXC_CPU_MX6D 0x64
>  #define MXC_CPU_MX6SOLO  0x65 /* dummy ID */
> +#define MXC_CPU_MX6DP0x68
> +#define MXC_CPU_MX6QP0x69
>  
>  #define CS0_128  0
>  #define CS0_64M_CS1_64M  1
> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
> b/arch/arm/include/asm/arch-mx6/sys_proto.h
> index 28c77a4..eee8ca8 100644
> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h
> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
> @@ -30,9 +30,7 @@ const char *get_imx_type(u32 imxtype);
>  unsigned imx_ddr_size(void);
>  void set_chipselect_size(int const);
>  
> -#define is_mx6dqp() ((is_cpu_type(MXC_CPU_MX6Q) || \
> -  is_cpu_type(MXC_CPU_MX6D)) && \
> -  (soc_rev() >= CHIP_REV_2_0))
> +#define is_mx6dqp() (is_cpu_type(MXC_CPU_MX6QP) || 
> is_cpu_type(MXC_CPU_MX6DP))
>  
>  /*
>   * Initializes on-chip ethernet controllers.
> 


Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
==

Re: [U-Boot] [PATCH v3 00/25] dm: Introduce Rockchip RK3288 support

[Sjoerd Simons]

On Tue, 2015-06-23 at 17:28 -0600, Simon Glass wrote:
> 
> Since much of the code is generic, this also supports the Radxa Rock 
> Pro.

Just to be sure as I happen to have a Rock Pro on the way which will
want some u-boot love. Do you actually mean the Rock Pro which is
RK3188 based rather then Rock2 which is an RK3288 based SOM ?


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

Re: [U-Boot] [PATCH] thermal: imx_thermal: fix busywait if IMX6 temp <0C

[Stefano Babic]

Hi Tim,

On 09/07/2015 00:49, Tim Harvey wrote:
> The temperature calculation must be typecasted to keep the compiler
> from sign extending a negative value prior to division.
> 
> This fixes an issue where if the CPU temperature is <0C it will get stuck
> in the busywait loop until the CPU heats up to 0C.
> 
> Cc: Ye Li 
> Cc: Jason Liu 
> Signed-off-by: Tim Harvey 
> ---
>  drivers/thermal/imx_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 0d893c9..6d1ac97 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -115,7 +115,7 @@ static int read_cpu_temperature(struct udevice *dev)
>   writel(TEMPSENSE0_FINISHED, &anatop->tempsense0_clr);
>  
>   /* milli_Tmeas = c2 - Nmeas * c1 */
> - temperature = (c2 - n_meas * c1)/1000;
> + temperature = (long)(c2 - n_meas * c1)/1000;
>  
>   /* power down anatop thermal sensor */
>   writel(TEMPSENSE0_POWER_DOWN, &anatop->tempsense0_set);
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size

[Stefano Babic]

On 19/06/2015 14:18, Albert ARIBAUD (3ADEV) wrote:
> imximage header size is 4-byte, not 8-byte aligned.
> This produces .imx images that a Vybrid cannot boot
> on.
> 
> Fix by adding a "padding" field in header.
> 
> Signed-off-by: Albert ARIBAUD (3ADEV) 
> ---
> 
>  tools/imximage.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/imximage.h b/tools/imximage.h
> index 36fe095..a913329 100644
> --- a/tools/imximage.h
> +++ b/tools/imximage.h
> @@ -129,6 +129,7 @@ typedef struct {
>   ivt_header_t header;
>   write_dcd_command_t write_dcd_command;
>   dcd_addr_data_t addr_data[MAX_HW_CFG_SIZE_V2];
> + uint32_t padding[1]; /* end up on an 8-byte boundary */
>  } dcd_v2_t;
>  
>  typedef struct {
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] i2c: fix vf610 support

[Stefano Babic]

Hi Albert,

On 19/06/2015 14:18, Albert ARIBAUD (3ADEV) wrote:
> Add support in mxc_i2c driver, iomux_v3 and vf610 architecture for the four
> I2C instances available in VF610.
> 
> Signed-off-by: Albert ARIBAUD (3ADEV) 
> ---
> 
>  arch/arm/include/asm/arch-vf610/crm_regs.h|  3 +++
>  arch/arm/include/asm/arch-vf610/imx-regs.h|  3 +++
>  arch/arm/include/asm/arch-vf610/iomux-vf610.h | 11 +++
>  arch/arm/include/asm/imx-common/iomux-v3.h|  2 ++
>  drivers/i2c/mxc_i2c.c |  3 ++-
>  5 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h 
> b/arch/arm/include/asm/arch-vf610/crm_regs.h
> index fdb45e9..a46e396 100644
> --- a/arch/arm/include/asm/arch-vf610/crm_regs.h
> +++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
> @@ -207,6 +207,7 @@ struct anadig_reg {
>  #define CCM_CCGR4_CCM_CTRL_MASK  (0x3 << 22)
>  #define CCM_CCGR4_GPC_CTRL_MASK  (0x3 << 24)
>  #define CCM_CCGR4_I2C0_CTRL_MASK (0x3 << 12)
> +#define CCM_CCGR4_I2C1_CTRL_MASK (0x3 << 14)
>  #define CCM_CCGR6_OCOTP_CTRL_MASK(0x3 << 10)
>  #define CCM_CCGR6_DSPI2_CTRL_MASK(0x3 << 24)
>  #define CCM_CCGR6_DSPI3_CTRL_MASK(0x3 << 26)
> @@ -216,6 +217,8 @@ struct anadig_reg {
>  #define CCM_CCGR9_FEC0_CTRL_MASK 0x3
>  #define CCM_CCGR9_FEC1_CTRL_MASK (0x3 << 2)
>  #define CCM_CCGR10_NFC_CTRL_MASK 0x3
> +#define CCM_CCGR10_I2C2_CTRL_MASK(0x3 << 12)
> +#define CCM_CCGR10_I2C3_CTRL_MASK(0x3 << 14)
>  
>  #define ANADIG_PLL7_CTRL_BYPASS (1 << 16)
>  #define ANADIG_PLL7_CTRL_ENABLE (1 << 13)
> diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h 
> b/arch/arm/include/asm/arch-vf610/imx-regs.h
> index 7df3b1e..4366985 100644
> --- a/arch/arm/include/asm/arch-vf610/imx-regs.h
> +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
> @@ -75,6 +75,9 @@
>  #define ESAI_FIFO_BASE_ADDR  (AIPS0_BASE_ADDR + 0x00063000)
>  #define WDOG_BASE_ADDR   (AIPS0_BASE_ADDR + 0x00065000)
>  #define I2C1_BASE_ADDR   (AIPS0_BASE_ADDR + 0x00066000)
> +#define I2C2_BASE_ADDR   (AIPS0_BASE_ADDR + 0x00067000)
> +#define I2C3_BASE_ADDR   (AIPS0_BASE_ADDR + 0x000E6000)
> +#define I2C4_BASE_ADDR   (AIPS0_BASE_ADDR + 0x000E7000)
>  #define WKUP_BASE_ADDR   (AIPS0_BASE_ADDR + 0x0006A000)
>  #define CCM_BASE_ADDR(AIPS0_BASE_ADDR + 0x0006B000)
>  #define GPC_BASE_ADDR(AIPS0_BASE_ADDR + 0x0006C000)
> diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h 
> b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
> index 019307b..0e2bd53 100644
> --- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
> +++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
> @@ -20,7 +20,8 @@
>  #define VF610_DDR_PAD_CTRL_1 (PAD_CTL_DSE_25ohm | \
>   PAD_CTL_INPUT_DIFFERENTIAL)
>  #define VF610_I2C_PAD_CTRL   (PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_50ohm | \
> - PAD_CTL_SPEED_HIGH | PAD_CTL_OBE_IBE_ENABLE)
> + PAD_CTL_SPEED_HIGH | PAD_CTL_ODE | \
> + PAD_CTL_OBE_IBE_ENABLE)
>  #define VF610_NFC_IO_PAD_CTRL(PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
>   PAD_CTL_DSE_50ohm | PAD_CTL_PUS_47K_UP | \
>   PAD_CTL_OBE_IBE_ENABLE)
> @@ -110,6 +111,8 @@ enum {
>   VF610_PAD_PTA29__ESDHC1_DAT3= IOMUX_PAD(0x004c, 0x004c, 5, 
> __NA_, 0, VF610_SDHC_PAD_CTRL),
>   VF610_PAD_PTB14__I2C0_SCL   = IOMUX_PAD(0x0090, 0x0090, 2, 
> 0x033c, 1, VF610_I2C_PAD_CTRL),
>   VF610_PAD_PTB15__I2C0_SDA   = IOMUX_PAD(0x0094, 0x0094, 2, 
> 0x0340, 1, VF610_I2C_PAD_CTRL),
> + VF610_PAD_PTA22__I2C2_SCL   = IOMUX_PAD(0x0030, 0x0030, 6, 
> 0x034c, 0, VF610_I2C_PAD_CTRL),
> + VF610_PAD_PTA23__I2C2_SDA   = IOMUX_PAD(0x0034, 0x0034, 6, 
> 0x0350, 0, VF610_I2C_PAD_CTRL),
>   VF610_PAD_PTD31__NF_IO15= IOMUX_PAD(0x00fc, 0x00fc, 2, 
> __NA_, 0, VF610_NFC_IO_PAD_CTRL),
>   VF610_PAD_PTD31__GPIO_63= IOMUX_PAD(0x00fc, 0x00fc, 0, 
> __NA_, 0, VF610_GPIO_PAD_CTRL),
>   VF610_PAD_PTD30__NF_IO14= IOMUX_PAD(0x0100, 0x0100, 2, 
> __NA_, 0, VF610_NFC_IO_PAD_CTRL),
> @@ -146,10 +149,10 @@ enum {
>   VF610_PAD_PTD12__GPIO_91= IOMUX_PAD(0x016c, 0x016c, 0, 
> __NA_, 0, VF610_GPIO_PAD_CTRL),
>   VF610_PAD_PTD13__GPIO_92= IOMUX_PAD(0x0170, 0x0170, 0, 
> __NA_, 0, VF610_GPIO_PAD_CTRL),
>   VF610_PAD_PTD22__NF_IO6 = IOMUX_PAD(0x0120, 0x0120, 2, 
> __NA_, 0, VF610_NFC_IO_PAD_CTRL),
> - VF610_PAD_PTD21__NF_IO5 = IOMUX_PAD(0x0124, 0x0124, 2, 
> __NA_, 0, VF610_NFC_IO_PAD_CTRL), 
> - VF610_PAD_PTD20__NF_IO4 = IOMUX_PAD(0x

Re: [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code

[Stefano Babic]

Hi Albert, Stefan,

On 19/06/2015 19:33, Albert ARIBAUD wrote:

> 
> I could probably factor back out the JEDEC settings, but there are
> still differences in the lists of registers to write between the
> existing vf610twr/colibri_vf and the new pcm052, especially the PHY
> regs but elsewhere too, and there are some writes in the driver that
> the PCM052 does not have.
> 
> As I wanted to leave the existing boards strictly unaffected, and as I
> did not want to start sprinkling '#if defined(some-board)' over the
> driver code, I went for a fully board-controlled design so that no
> board could possibly be affected by any future change to the driver.
> 
> How about a mix? I could keep the JEDEC and lvl pointers in the DDR
> controller init call arguments and append "per-boards" CR and PHY
> arrays. The driver would do the JEDEC writes (thus keeping JEDEC DDR3
> additions simple), the LVL writes if not NULL, then the "per-board" CR
> writes if not NULL, then the current common PHY writes, then the
> "per-board" PHY writes if not null.

This matches IMHO what we have already tried to do with most of
Frescale's i.MXes, putting general code and setting in the arch/cpu/ (or
in the imx_common for MX5 and MX6), but letting the board code to write
the board specific part.

Some mix seems to me a goog compromise between flexibility and common code.
> 
> This would keep common parts (JEDEC and minimal settings) in the driver
> while allowing board their own specific settings -- even overriding the
> driver settings, since the per-board writes would come last before
> CR000 is rewritten.
> 
> Would that be ok ?
> 
>> --
Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] net: fec_mxc: remove useless struct nbuf

[Stefano Babic]

On 19/06/2015 14:18, Albert ARIBAUD (3ADEV) wrote:
> This locally defined struct is actually only used once
> and as an opaque type. Remove it for clarity.
> 
> Signed-off-by: Albert ARIBAUD (3ADEV) 
> ---
> 
>  drivers/net/fec_mxc.c | 20 +---
>  1 file changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 9225d37..c5dcbbb 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -67,13 +67,6 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #undef DEBUG
>  
> -struct nbuf {
> - uint8_t data[1500]; /**< actual data */
> - int length; /**< actual length */
> - int used;   /**< buffer in use or not */
> - uint8_t head[16];   /**< MAC header(6 + 6 + 2) + 2(aligned) */
> -};
> -
>  #ifdef CONFIG_FEC_MXC_SWAP_PACKET
>  static void swap_packet(uint32_t *packet, int length)
>  {
> @@ -775,7 +768,6 @@ static int fec_recv(struct eth_device *dev)
>   struct fec_bd *rbd = &fec->rbd_base[fec->rbd_index];
>   unsigned long ievent;
>   int frame_length, len = 0;
> - struct nbuf *frame;
>   uint16_t bd_status;
>   uint32_t addr, size, end;
>   int i;
> @@ -835,12 +827,11 @@ static int fec_recv(struct eth_device *dev)
>   /*
>* Get buffer address and size
>*/
> - frame = (struct nbuf *)readl(&rbd->data_pointer);
> + addr = readl(&rbd->data_pointer);
>   frame_length = readw(&rbd->data_length) - 4;
>   /*
>* Invalidate data cache over the buffer
>*/
> - addr = (uint32_t)frame;
>   end = roundup(addr + frame_length, ARCH_DMA_MINALIGN);
>   addr &= ~(ARCH_DMA_MINALIGN - 1);
>   invalidate_dcache_range(addr, end);
> @@ -849,16 +840,15 @@ static int fec_recv(struct eth_device *dev)
>*  Fill the buffer and pass it to upper layers
>*/
>  #ifdef CONFIG_FEC_MXC_SWAP_PACKET
> - swap_packet((uint32_t *)frame->data, frame_length);
> + swap_packet((uint32_t *)addr, frame_length);
>  #endif
> - memcpy(buff, frame->data, frame_length);
> + memcpy(buff, (char *)addr, frame_length);
>   net_process_received_packet(buff, frame_length);
>   len = frame_length;
>   } else {
>   if (bd_status & FEC_RBD_ERR)
> - printf("error frame: 0x%08lx 0x%08x\n",
> - (ulong)rbd->data_pointer,
> - bd_status);
> + printf("error frame: 0x%08x 0x%08x\n",
> +addr, bd_status);
>   }
>  
>   /*
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] iMX: adding parsing to hab_status command

[Stefano Babic]

Hi Ulises,

On 03/07/2015 04:26, ulises.carde...@freescale.com wrote:
> From: Ulises Cardenas 
> 
> hab_status command returns a memory dump of the hab event log. But the
> raw data is not human-readable. Parsing such data into readable event
> will help to minimize debbuging time.
> 
> Signed-off-by: Ulises Cardenas 
> ---
> 
> Changes in v2:
> -Refactored get_<*>_idx functions as recommended by Michael, to a single
> generic function to travese the enum.



> 
>  arch/arm/cpu/armv7/mx6/hab.c| 173 
> +++-
>  arch/arm/include/asm/arch-mx6/hab.h |  85 +++---
>  2 files changed, 245 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
> index 8dee595..87f422d 100644
> --- a/arch/arm/cpu/armv7/mx6/hab.c
> +++ b/arch/arm/cpu/armv7/mx6/hab.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2010-2014 Freescale Semiconductor, Inc.
> + * Copyright (C) 2010-2015 Freescale Semiconductor, Inc.
>   *
>   * SPDX-License-Identifier:GPL-2.0+
>   */
> @@ -111,6 +111,153 @@
>   * ++ + CSF_PAD_SIZE
>   */
>  
> +#define MAX_RECORD_BYTES (8*1024) /* 4 kbytes */
> +
> +struct record {
> + uint8_t  tag;   /* Tag */
> + uint8_t  len[2];/* Length */
> + uint8_t  par;   /* Version */
> + uint8_t  contents[MAX_RECORD_BYTES];/* Record Data */
> + bool any_rec_flag;
> +};
> +
> +char *rsn_str[] = {"RSN = HAB_RSN_ANY (0x00)\n",
> +"RSN = HAB_ENG_FAIL (0x30)\n",
> +"RSN = HAB_INV_ADDRESS (0x22)\n",
> +"RSN = HAB_INV_ASSERTION (0x0C)\n",
> +"RSN = HAB_INV_CALL (0x28)\n",
> +"RSN = HAB_INV_CERTIFICATE (0x21)\n",
> +"RSN = HAB_INV_COMMAND (0x06)\n",
> +"RSN = HAB_INV_CSF (0x11)\n",
> +"RSN = HAB_INV_DCD (0x27)\n",
> +"RSN = HAB_INV_INDEX (0x0F)\n",
> +"RSN = HAB_INV_IVT (0x05)\n",
> +"RSN = HAB_INV_KEY (0x1D)\n",
> +"RSN = HAB_INV_RETURN (0x1E)\n",
> +"RSN = HAB_INV_SIGNATURE (0x18)\n",
> +"RSN = HAB_INV_SIZE (0x17)\n",
> +"RSN = HAB_MEM_FAIL (0x2E)\n",
> +"RSN = HAB_OVR_COUNT (0x2B)\n",
> +"RSN = HAB_OVR_STORAGE (0x2D)\n",
> +"RSN = HAB_UNS_ALGORITHM (0x12)\n",
> +"RSN = HAB_UNS_COMMAND (0x03)\n",
> +"RSN = HAB_UNS_ENGINE (0x0A)\n",
> +"RSN = HAB_UNS_ITEM (0x24)\n",
> +"RSN = HAB_UNS_KEY (0x1B)\n",
> +"RSN = HAB_UNS_PROTOCOL (0x14)\n",
> +"RSN = HAB_UNS_STATE (0x09)\n",
> +"RSN = INVALID\n",
> +NULL};
> +
> +char *sts_str[] = {"STS = HAB_SUCCESS (0xF0)\n",
> +"STS = HAB_FAILURE (0x33)\n",
> +"STS = HAB_WARNING (0x69)\n",
> +"STS = INVALID\n",
> +NULL};
> +
> +char *eng_str[] = {"ENG = HAB_ENG_ANY (0x00)\n",
> +"ENG = HAB_ENG_SCC (0x03)\n",
> +"ENG = HAB_ENG_RTIC (0x05)\n",
> +"ENG = HAB_ENG_SAHARA (0x06)\n",
> +"ENG = HAB_ENG_CSU (0x0A)\n",
> +"ENG = HAB_ENG_SRTC (0x0C)\n",
> +"ENG = HAB_ENG_DCP (0x1B)\n",
> +"ENG = HAB_ENG_CAAM (0x1D)\n",
> +"ENG = HAB_ENG_SNVS (0x1E)\n",
> +"ENG = HAB_ENG_OCOTP (0x21)\n",
> +"ENG = HAB_ENG_DTCP (0x22)\n",
> +"ENG = HAB_ENG_ROM (0x36)\n",
> +"ENG = HAB_ENG_HDCP (0x24)\n",
> +"ENG = HAB_ENG_RTL (0x77)\n",
> +"ENG = HAB_ENG_SW (0xFF)\n",
> +"ENG = INVALID\n",
> +NULL};
> +
> +char *ctx_str[] = {"CTX = HAB_CTX_ANY(0x00)\n",
> +"CTX = HAB_CTX_FAB (0xFF)\n",
> +"CTX = HAB_CTX_ENTRY (0xE1)\n",
> +"CTX = HAB_CTX_TARGET (0x33)\n",
> +"CTX = HAB_CTX_AUTHENTICATE (0x0A)\n",
> +

Re: [U-Boot] [PATCH] mmc:fsl_esdhc invalidate dcache before read

[Stefano Babic]

Hi Peng,


I see this patch is now delegated to me. Then, I have no objections to
merge it into u-boot-imx if Pantelis agree.


On 25/06/2015 04:32, Peng Fan wrote:
> DCIMVAC is upgraded to DCCIMVAC for the individual processor
> (Cortex-A7) that the DCIMVAC is executed on.
> 
Can you better explain it ? What are the consequences of using DCCIMVAC
into this driver ?

This driver is not only for i.MX. It runs on PowerPc, too. Do you tested
this patch on PowerPC architecture, too ? Maybe someone else can do it ?

> We should follow the linux dma follow. Before DMA read, first
> invalidate dcache then after DMA read, invalidate dcache again.
> 
> With the DMA direction DMA_FROM_DEVICE, the dcache need be
> invalidated again after the DMA completion. The reason is
> that we need explicity make sure the dcache been invalidated
> thus to get the DMA'ed memory correctly from the physical memory.
> Any cache-line fill during the DMA operations such as the
> pre-fetching can cause the DMA coherency issue, thus CPU get the stale data.
> 
> Signed-off-by: Peng Fan 
> Signed-off-by: Ye.Li 
> Signed-off-by: Nitin Garg 
> Signed-off-by: Jason Liu 
> ---
>  drivers/mmc/fsl_esdhc.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index c4719e6..0510bf0 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -341,6 +341,9 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
>   err = esdhc_setup_data(mmc, data);
>   if(err)
>   return err;
> +
> + if (data->flags & MMC_DATA_READ)
> + check_and_invalidate_dcache_range(cmd, data);
>   }
>  
>   /* Figure out the transfer arguments */
> @@ -437,6 +440,11 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
>   }
>   } while ((irqstat & DATA_COMPLETE) != DATA_COMPLETE);
>  
> + /*
> +  * Need invalidate the dcache here again to avoid any
> +  * cache-fill during the DMA operations such as the
> +  * speculative pre-fetching etc.
> +  */
>   if (data->flags & MMC_DATA_READ)
>   check_and_invalidate_dcache_range(cmd, data);
>  #endif
> 

>From my side it is ok.

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 1/2] imx: mx6 remove duplicated enable_cspi_clock

[Stefano Babic]

Hi Peng,

On 01/07/2015 11:01, Peng Fan wrote:
> enable_spi_clock does the same thing with enable_cspi_clock, so
> remove enable_cspi_clock.
> Remove enable_cspi_clock prototype in header file
> convert cm_fx6/spl.c to use enable_spi_clk
> 
> Signed-off-by: Peng Fan 
> Acked-by: Stefano Babic 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot