[U-Boot] [PATCH V2] exynos: spl: Add a custom spi copy function

[Rajeshwari Shinde]

This patch implements a custom spi_copy funtion to copy u-boot from SF
to RAM. This is faster then iROM spi_copy funtion as this runs spi at
50Mhz and also in WORD mode of operation.

Changed a printf in pinmux.c to debug just to avoid the compilation
error in SPL.
Removed enum for boot mode from spl_boot.c as it was already define
in spl.h

Based on "[PATCH V2] spi: exynos: Support word transfers"

Signed-off-by: Alim Akhtar 
Signed-off-by: Tom Wai-Hong Tam 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- Corrected the commit message.
- Added a SPI timeout check.
- Corrected the comments.
 arch/arm/cpu/armv7/exynos/pinmux.c |2 +-
 arch/arm/include/asm/arch-exynos/spi.h |2 +
 board/samsung/smdk5250/spl_boot.c  |  136 ---
 include/configs/exynos5250-dt.h|3 +
 spl/Makefile   |4 +
 5 files changed, 132 insertions(+), 15 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index bd499b4..c484a86 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -427,7 +427,7 @@ static int exynos4_pinmux_config(int peripheral, int flags)
case PERIPH_ID_SDMMC1:
case PERIPH_ID_SDMMC3:
case PERIPH_ID_SDMMC4:
-   printf("SDMMC device %d not implemented\n", peripheral);
+   debug("SDMMC device %d not implemented\n", peripheral);
return -1;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
diff --git a/arch/arm/include/asm/arch-exynos/spi.h 
b/arch/arm/include/asm/arch-exynos/spi.h
index e67ad27..3430ac1 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -43,6 +43,8 @@ struct exynos_spi {
 
 #define SPI_TIMEOUT_MS 10
 
+#define SF_READ_DATA_CMD   0x3
+
 /* SPI_CHCFG */
 #define SPI_CH_HS_EN   (1 << 6)
 #define SPI_CH_RST (1 << 5)
diff --git a/board/samsung/smdk5250/spl_boot.c 
b/board/samsung/smdk5250/spl_boot.c
index c0bcf46..85a5d68 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -22,17 +22,13 @@
 
 #include
 #include
+#include 
+#include 
+#include 
+#include 
+#include 
 
-enum boot_mode {
-   BOOT_MODE_MMC = 4,
-   BOOT_MODE_SERIAL = 20,
-   /* Boot based on Operating Mode pin settings */
-   BOOT_MODE_OM = 32,
-   BOOT_MODE_USB,  /* Boot using USB download */
-};
-
-   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
-   typedef u32 (*usb_copy_func_t)(void);
+typedef u32 (*usb_copy_func_t)(void);
 
 /*
  * Set/clear program flow prediction and return the previous state.
@@ -48,6 +44,119 @@ static int config_branch_prediction(int set_cr_z)
return cr & CR_Z;
 }
 
+static void spi_rx_tx(struct exynos_spi *regs, int todo,
+   void *dinp, void const *doutp, int i)
+{
+   uint *rxp = (uint *)(dinp + (i * (32 * 1024)));
+   int rx_lvl, tx_lvl;
+   uint out_bytes, in_bytes;
+
+   out_bytes = todo;
+   in_bytes = todo;
+   setbits_le32(®s->ch_cfg, SPI_CH_RST);
+   clrbits_le32(®s->ch_cfg, SPI_CH_RST);
+   writel(((todo * 8) / 32) | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
+
+   while (in_bytes) {
+   uint32_t spi_sts;
+   int temp;
+
+   spi_sts = readl(®s->spi_sts);
+   rx_lvl = ((spi_sts >> 15) & 0x7f);
+   tx_lvl = ((spi_sts >> 6) & 0x7f);
+   while (tx_lvl < 32 && out_bytes) {
+   temp = 0x;
+   writel(temp, ®s->tx_data);
+   out_bytes -= 4;
+   tx_lvl += 4;
+   }
+   while (rx_lvl >= 4 && in_bytes) {
+   temp = readl(®s->rx_data);
+   if (rxp)
+   *rxp++ = temp;
+   in_bytes -= 4;
+   rx_lvl -= 4;
+   }
+   }
+}
+
+/*
+* Copy uboot from spi flash to RAM
+*
+* @parma uboot_sizesize of u-boot to copy
+* @param uboot_addraddress in u-boot to copy
+*/
+static void exynos_spi_copy(unsigned int uboot_size, unsigned int uboot_addr)
+{
+   int upto, todo;
+   int i, timeout = 100;
+   struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
+
+   set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
+   /* set the spi1 GPIO */
+   exynos_pinmux_config(PERIPH_ID_SPI1, PINMUX_FLAG_NONE);
+
+   /* set pktcnt and enable it */
+   writel(4 | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
+   /* set FB_CLK_SEL */
+   writel(SPI_FB_DELAY_180, ®s->fb_clk);
+   /* set CH_WIDTH and BUS_WIDTH as word */
+   setbits_le32(®s->mode_cfg, SPI_MODE_CH_WIDTH_WORD |
+   SPI_MODE_BUS_WIDTH_WORD);
+   clrbits_le32(®s->ch_cfg, SPI_C

[U-Boot] [PATCH V2] spi: exynos: Support word transfers

[Rajeshwari Shinde]

Since SPI register access is so expensive, it is worth transferring data
a word at a time if we can. This complicates the driver unfortunately.

Use the byte-swapping feature to avoid having to convert to/from big
endian in software.

This change increases speed from about 2MB/s to about 4.5MB/s.

Based on "[PATCH V2] spi: exynos: Minimise access to SPI FIFO level"

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- Rebased on [PATCH V2] spi: exynos: Minimise access to SPI FIFO level
 arch/arm/include/asm/arch-exynos/spi.h |   11 -
 drivers/spi/exynos_spi.c   |   79 ++--
 2 files changed, 74 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/spi.h 
b/arch/arm/include/asm/arch-exynos/spi.h
index 7cab1e9..e67ad27 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -34,7 +34,7 @@ struct exynos_spi {
unsigned intrx_data;/* 0x1c */
unsigned intpkt_cnt;/* 0x20 */
unsigned char   reserved2[4];
-   unsigned char   reserved3[4];
+   unsigned intswap_cfg;   /* 0x28 */
unsigned intfb_clk; /* 0x2c */
unsigned char   padding[0xffd0];
 };
@@ -74,5 +74,14 @@ struct exynos_spi {
 /* Packet Count */
 #define SPI_PACKET_CNT_EN  (1 << 16)
 
+/* Swap config */
+#define SPI_TX_SWAP_EN (1 << 0)
+#define SPI_TX_BYTE_SWAP   (1 << 2)
+#define SPI_TX_HWORD_SWAP  (1 << 3)
+#define SPI_TX_BYTE_SWAP   (1 << 2)
+#define SPI_RX_SWAP_EN (1 << 4)
+#define SPI_RX_BYTE_SWAP   (1 << 6)
+#define SPI_RX_HWORD_SWAP  (1 << 7)
+
 #endif /* __ASSEMBLY__ */
 #endif
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index bcca3d6..4dda23b 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -216,12 +216,29 @@ static void spi_get_fifo_levels(struct exynos_spi *regs,
  *
  * @param regs SPI peripheral registers
  * @param countNumber of bytes to transfer
+ * @param step Number of bytes to transfer in each packet (1 or 4)
  */
-static void spi_request_bytes(struct exynos_spi *regs, int count)
+static void spi_request_bytes(struct exynos_spi *regs, int count, int step)
 {
+   /* For word address we need to swap bytes */
+   if (step == 4) {
+   setbits_le32(®s->mode_cfg,
+SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD);
+   count /= 4;
+   setbits_le32(®s->swap_cfg, SPI_TX_SWAP_EN | SPI_RX_SWAP_EN |
+   SPI_TX_BYTE_SWAP | SPI_RX_BYTE_SWAP |
+   SPI_TX_HWORD_SWAP | SPI_RX_HWORD_SWAP);
+   } else {
+   /* Select byte access and clear the swap configuration */
+   clrbits_le32(®s->mode_cfg,
+SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD);
+   writel(0, ®s->swap_cfg);
+   }
+
assert(count && count < (1 << 16));
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
+
writel(count | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
 }
 
@@ -236,6 +253,7 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
int toread;
unsigned start = get_timer(0);
int stopping;
+   int step;
 
out_bytes = in_bytes = todo;
 
@@ -243,10 +261,19 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
!(spi_slave->mode & SPI_SLAVE);
 
/*
+* Try to transfer words if we can. This helps read performance at
+* SPI clock speeds above about 20MHz.
+*/
+   step = 1;
+   if (!((todo | (uintptr_t)rxp | (uintptr_t)txp) & 3) &&
+   !spi_slave->skip_preamble)
+   step = 4;
+
+   /*
 * If there's something to send, do a software reset and set a
 * transaction size.
 */
-   spi_request_bytes(regs, todo);
+   spi_request_bytes(regs, todo, step);
 
/*
 * Bytes are transmitted/received in pairs. Wait to receive all the
@@ -259,14 +286,26 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
 
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, &rx_lvl, &tx_lvl);
+
+   /*
+* Don't completely fill the txfifo, since we don't want our
+* rxfifo to overflow, and it may already contain data.
+*/
while (tx_lvl < spi_slave->fifo_size/2 && out_bytes) {
-   temp = txp ? *txp++ : 0xff;
+   if (!txp)
+   temp = -1;
+   else if (step == 4)
+   temp = *(uint32_t *)txp;
+   else
+   temp = *txp;
  

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi Stephen,

On Wed, May 29, 2013 at 10:11 PM, Stephen Warren wrote:

> On 05/29/2013 10:46 PM, Simon Glass wrote:
> > Hi,
> >
> > On Wed, May 29, 2013 at 4:07 PM, Stephen Warren  > > wrote:
> >
> > On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
> > > Dear Stephen Warren,
> > >
> > > In message <51a67ec1.2000...@wwwdotorg.org
> > > you wrote:
> > >>
> > >> To keep this process in check a bit, we could always pick a
> > specific git
> > >> commit or release version of dtc that each U-Boot version
> > (release) will
> > >> be allowed to assume. That will limit the number of times people
> > need to
> > >> update their locally-built dtc to at most once per U-Boot release.
> > >> Hopefully much less often.
> > >
> > > I think this is broken by design, in several aspects.  First,
> U-Boot
> > > is usually not the only user of DTC.  Second, assume you run a "git
> > > bisect" over a U-Boot tree - would you really want to switch DTC
> in-
> > > flight?
> > >
> > > Sorry, instead we should strive to be compatible to a reasonably
> old,
> > > stable version of DTC, like we do for all other tools as well.  As
> > > mentioned before - just because RHEL 5 ships an ancient version of
> -
> > > say - "make" we will NOT start building this from the sources
> ourself.
> > > This cannot be the way to go.
> >
> > So the result of that is that we can never ever use new features in
> any
> > tool, at least in any meaningful time-frame.
> >
> > I think we need to differentiate between tools that are already
> stable
> > and/or core to all aspects of the U-Boot build process (such as
> make),
> > and tools that enable new features that are under development.
> >
> > Clearly the U-Boot makefiles have to be fairly cautious in their use
> of
> > any new make features, so that everyone with any reasonable version
> of
> > make can build U-Boot.
> >
> > However, when enabling a new feature, such as using device trees to
> > configure U-Boot[1], for which tool support is new and evolving along
> > with the feature itself, and which is only used on a very very few
> > boards and even fewer SoCs right now within U-Boot, it seems entirely
> > reasonable to demand that the people working on/with that new feature
> > are aware that it's evolving, and that they may need to take a few
> extra
> > steps to go out and get tools that support that new feature. No doubt
> > once this feature has settled down a bit, and distros have pulled in
> > newer versions of dtc, everthing will "just work" just like any other
> > stable feature.
> >
> > If you don't accept this, then we simply have to ban any include use
> in
> > U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd
> need to
> > stop using that. We'd need to move *.dts into a single directory
> within
> > U-Boot to work around that, or perhaps hard-coding relative include
> > paths in *.dts might work. Similarly for the patches to support
> dtc+cpp
> > usage, so we wouldn't be able to use named constants in DT files for
> > many years, which would prevent sharing DT files with the kernel
> and/or
> > any other standard repository of DT files, which are bound to use
> this
> > feature.
> >
> > [1] Which is very specifically a different feature than simply having
> > U-Boot pass a DT to the Linux kernel during boot, and perhaps modify
> it
> > a little, which clearly is not a new feature.
> >
> >
> > My patch:
> >
> > - doesn't require -i but uses it if available (ARCH_CPU_DTS works around
> > this)
>

I had to remove all sharp objects from the room half-way through reading
your email :-) Gosh, things aren't that bad!


>
> If we ever need to support a dtc that doesn't implement -i, then we
> always need to support that. So, there's no point using -i when it's
> available; we should simply have a single way of writing the *.dts files
> that doesn't ever assume dtc -i is available. Otherwise, there will be
> rampant inconsistency between different *.dts files; how they're
> written, the flow by which they're compiled, etc.
>
> In other words, we /always/ have to use "ARCH_CPU_DTS" in *.dts
> throughout the entire U-Boot source tree if we're to support not using
> dtc -i.
>

Well realistically at some point there will be a new dtc release, and
perhaps a year or so after that we can maybe start deprecating this and
requiring -i.


>
> > - honours #define, #include, etc.
> > - works with old and new versions of dtc
>
> If we are forced to rely only upon features in old versions of dtc, we
> specifically shouldn't allow use of features that will only work with
> newer dtc. If we don't actively enforce this rule, we haven't achieved
> the goal of not relying upon new versions of dtc.
>

As you know I'm un

[U-Boot] [PATCH V2] spi: exynos: Minimise access to SPI FIFO level

[Rajeshwari Shinde]

Accessing SPI registers is slow, but access to the FIFO level register
in particular seems to be extraordinarily expensive (I measure up to
600ns). Perhaps it is required to synchronise with the SPI byte output
logic which might run at 1/8th of the 40MHz SPI speed (just a guess).

Reduce access to this register by filling up and emptying FIFOs
more completely, rather than just one word each time around the inner
loop.

Since the rxfifo value will now likely be much greater that what we read
before we fill the txfifo, we only fill the txfifo halfway. This is
because if the txfifo is empty, but the rxfifo has data in it, then writing
too much data to the txfifo may overflow the rxfifo as data arrives.

This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow.

Based on "[PATCH 0/2 V3] exynos: Support a delay after deactivate for SPI"

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- Rebased on "[PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode" 
 drivers/spi/exynos_spi.c |   27 +++
 1 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index deb32bd..bcca3d6 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -259,24 +259,27 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
 
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, &rx_lvl, &tx_lvl);
-   if (tx_lvl < spi_slave->fifo_size && out_bytes) {
+   while (tx_lvl < spi_slave->fifo_size/2 && out_bytes) {
temp = txp ? *txp++ : 0xff;
writel(temp, ®s->tx_data);
out_bytes--;
+   tx_lvl++;
}
if (rx_lvl > 0) {
-   temp = readl(®s->rx_data);
-   if (spi_slave->skip_preamble) {
-   if (temp == SPI_PREAMBLE_END_BYTE) {
-   spi_slave->skip_preamble = 0;
-   stopping = 0;
+   while (rx_lvl > 0) {
+   temp = readl(®s->rx_data);
+   if (spi_slave->skip_preamble) {
+   if (temp == SPI_PREAMBLE_END_BYTE) {
+   spi_slave->skip_preamble = 0;
+   stopping = 0;
+   }
+   } else {
+   if (rxp || stopping)
+   *rxp++ = temp;
+   in_bytes--;
}
-   } else {
-   if (rxp || stopping)
-   *rxp++ = temp;
-   in_bytes--;
-   }
-   toread--;
+   toread--;
+   rx_lvl--;
} else if (!toread) {
/*
 * We have run out of input data, but haven't read
-- 
1.7.4.4

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

[U-Boot] [PATCH 2/2 V3] spi: exynos: Support a delay after deactivate

[Rajeshwari Shinde]

For devices that need some time to react after a spi transaction
finishes, add the ability to set a delay.

Implement this as a delay on the first/next transaction to avoid
any delay in the fairly common case where a SPI transaction is
followed by other processing.

Based on:
"[U-Boot] [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode"

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- None.
Changes in V3:
- Rebased on "[PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode"
 drivers/spi/exynos_spi.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 01378d0..03cf503 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -38,6 +38,7 @@ struct spi_bus {
struct exynos_spi *regs;
int inited; /* 1 if this bus is ready for use */
int node;
+   uint deactivate_delay_us;   /* Delay to wait after deactivate */
 };
 
 /* A list of spi buses that we know about */
@@ -52,6 +53,8 @@ struct exynos_spi_slave {
enum periph_id periph_id;   /* Peripheral ID for this device */
unsigned int fifo_size;
int skip_preamble;
+   struct spi_bus *bus;/* Pointer to our SPI bus info */
+   ulong last_transaction_us;  /* Time of last transaction end */
 };
 
 static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -97,6 +100,7 @@ struct spi_slave *spi_setup_slave(unsigned int busnum, 
unsigned int cs,
}
 
bus = &spi_bus[busnum];
+   spi_slave->bus = bus;
spi_slave->regs = bus->regs;
spi_slave->mode = mode;
spi_slave->periph_id = bus->periph_id;
@@ -107,6 +111,7 @@ struct spi_slave *spi_setup_slave(unsigned int busnum, 
unsigned int cs,
spi_slave->fifo_size = 256;
 
spi_slave->skip_preamble = 0;
+   spi_slave->last_transaction_us = timer_get_us();
 
spi_slave->freq = bus->frequency;
if (max_hz)
@@ -371,9 +376,21 @@ void spi_cs_activate(struct spi_slave *slave)
 {
struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
 
+   /* If it's too soon to do another transaction, wait */
+   if (spi_slave->bus->deactivate_delay_us &&
+   spi_slave->last_transaction_us) {
+   ulong delay_us; /* The delay completed so far */
+   delay_us = timer_get_us() - spi_slave->last_transaction_us;
+   if (delay_us < spi_slave->bus->deactivate_delay_us)
+   udelay(spi_slave->bus->deactivate_delay_us - delay_us);
+   }
clrbits_le32(&spi_slave->regs->cs_reg, SPI_SLAVE_SIG_INACT);
debug("Activate CS, bus %d\n", spi_slave->slave.bus);
spi_slave->skip_preamble = spi_slave->mode & SPI_PREAMBLE;
+
+   /* Remember time of this transaction so we can honour the bus delay */
+   if (spi_slave->bus->deactivate_delay_us)
+   spi_slave->last_transaction_us = timer_get_us();
 }
 
 /**
@@ -423,6 +440,8 @@ static int spi_get_config(const void *blob, int node, 
struct spi_bus *bus)
/* Use 500KHz as a suitable default */
bus->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
50);
+   bus->deactivate_delay_us = fdtdec_get_int(blob, node,
+   "spi-deactivate-delay", 0);
 
return 0;
 }
-- 
1.7.4.4

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

[U-Boot] [PATCH 0/2 V3] exynos: Support a delay after deactivate for SPI

[Rajeshwari Shinde]

This patch set exports the function timer_get_us and adds a delay for 
devices that need some time to react after spi transation
finishes

This patch set is based on
"EXYNOS: SPI: Support SPI_PREAMBLE mode"
link: "http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/162269";

Changes in V2:
- Removed #ifdefine for exported function.
Changes in V3:
- Rebased on "[PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode"

Rajeshwari Shinde (2):
  exynos: Export timer_get_us() to get microsecond timer
  spi: exynos: Support a delay after deactivate

 drivers/spi/exynos_spi.c |   19 +++
 include/common.h |6 ++
 2 files changed, 25 insertions(+), 0 deletions(-)

-- 
1.7.4.4

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

[U-Boot] [PATCH 1/2 V3] exynos: Export timer_get_us() to get microsecond timer

[Rajeshwari Shinde]

This function, if implemented by the board, provides a microsecond
timer. The granularity may be larger than 1us if hardware does not
support this.

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- Removed #ifdefine for exported function.
Changes in V3:
- None
 include/common.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/common.h b/include/common.h
index 8a1f3e4..c228d44 100644
--- a/include/common.h
+++ b/include/common.h
@@ -590,6 +590,12 @@ void ddr_enable_ecc(unsigned int dram_size);
 #endif
 #endif
 
+/*
+ * Return the current value of a monotonically increasing microsecond timer.
+ * Granularity may be larger than 1us if hardware does not support this.
+ */
+ulong timer_get_us(void);
+
 /* $(CPU)/cpu.c */
 static inline int cpumask_next(int cpu, unsigned int mask)
 {
-- 
1.7.4.4

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

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/29/2013 10:46 PM, Simon Glass wrote:
> Hi,
> 
> On Wed, May 29, 2013 at 4:07 PM, Stephen Warren  > wrote:
> 
> On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
> > Dear Stephen Warren,
> >
> > In message <51a67ec1.2000...@wwwdotorg.org
> > you wrote:
> >>
> >> To keep this process in check a bit, we could always pick a
> specific git
> >> commit or release version of dtc that each U-Boot version
> (release) will
> >> be allowed to assume. That will limit the number of times people
> need to
> >> update their locally-built dtc to at most once per U-Boot release.
> >> Hopefully much less often.
> >
> > I think this is broken by design, in several aspects.  First, U-Boot
> > is usually not the only user of DTC.  Second, assume you run a "git
> > bisect" over a U-Boot tree - would you really want to switch DTC in-
> > flight?
> >
> > Sorry, instead we should strive to be compatible to a reasonably old,
> > stable version of DTC, like we do for all other tools as well.  As
> > mentioned before - just because RHEL 5 ships an ancient version of -
> > say - "make" we will NOT start building this from the sources ourself.
> > This cannot be the way to go.
> 
> So the result of that is that we can never ever use new features in any
> tool, at least in any meaningful time-frame.
> 
> I think we need to differentiate between tools that are already stable
> and/or core to all aspects of the U-Boot build process (such as make),
> and tools that enable new features that are under development.
> 
> Clearly the U-Boot makefiles have to be fairly cautious in their use of
> any new make features, so that everyone with any reasonable version of
> make can build U-Boot.
> 
> However, when enabling a new feature, such as using device trees to
> configure U-Boot[1], for which tool support is new and evolving along
> with the feature itself, and which is only used on a very very few
> boards and even fewer SoCs right now within U-Boot, it seems entirely
> reasonable to demand that the people working on/with that new feature
> are aware that it's evolving, and that they may need to take a few extra
> steps to go out and get tools that support that new feature. No doubt
> once this feature has settled down a bit, and distros have pulled in
> newer versions of dtc, everthing will "just work" just like any other
> stable feature.
> 
> If you don't accept this, then we simply have to ban any include use in
> U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to
> stop using that. We'd need to move *.dts into a single directory within
> U-Boot to work around that, or perhaps hard-coding relative include
> paths in *.dts might work. Similarly for the patches to support dtc+cpp
> usage, so we wouldn't be able to use named constants in DT files for
> many years, which would prevent sharing DT files with the kernel and/or
> any other standard repository of DT files, which are bound to use this
> feature.
> 
> [1] Which is very specifically a different feature than simply having
> U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it
> a little, which clearly is not a new feature.
> 
> 
> My patch:
> 
> - doesn't require -i but uses it if available (ARCH_CPU_DTS works around
> this)

If we ever need to support a dtc that doesn't implement -i, then we
always need to support that. So, there's no point using -i when it's
available; we should simply have a single way of writing the *.dts files
that doesn't ever assume dtc -i is available. Otherwise, there will be
rampant inconsistency between different *.dts files; how they're
written, the flow by which they're compiled, etc.

In other words, we /always/ have to use "ARCH_CPU_DTS" in *.dts
throughout the entire U-Boot source tree if we're to support not using
dtc -i.

> - honours #define, #include, etc.
> - works with old and new versions of dtc

If we are forced to rely only upon features in old versions of dtc, we
specifically shouldn't allow use of features that will only work with
newer dtc. If we don't actively enforce this rule, we haven't achieved
the goal of not relying upon new versions of dtc.

...
> However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we

This shouldn't be about whether a specific Soc's DT requires some
feature or not. All the U-Boot *.dts should work the same way.

> should just add a setting to tell U-Boot to not build the device tree at
> all? The same U-Boot binary can run on many different board times, just
> needing a different device tree.

Unfortunately, that's not remotely true yet for any Tegra system at
least; there's still a bunch of C code specific to each board. The
amount is reducing as things get migrated to DT, 

Re: [U-Boot] [PATCH V9 0/9] EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot

[Simon Glass]

On Tue, May 28, 2013 at 11:36 PM, Rajeshwari Birje <
rajeshwari.bi...@gmail.com> wrote:

> Hi Andy,
>
> U seem to be busy. I you have no issues can I ask Minkyu Kang to take
> them in u-boot-samsung tree. Please do reply.
>

It would be great to get this applied soon, thank you.


>
> --
> Regards,
> Rajeshwari Shinde
> On Fri, May 24, 2013 at 11:16 AM, Rajeshwari Birje
>  wrote:
> > Hi Andy,
> >
> > Please do let us know if any comments on this patch set.
> > If no comments can we get them merged, as they seem to be floating in
> > mainline for quite sometime now.
> >
> > Regards,
> > Rajeshwari Shinde
> >
> > On Sat, May 11, 2013 at 8:55 AM, Simon Glass  wrote:
> >> On Sat, Apr 27, 2013 at 12:12 AM, amar_g 
> wrote:
> >>> From: Amar 
> >>>
> >>> This patch set enables and initialises DWMMC for Exynos5250 on
> SMDK5250.
> >>> Adds driver changes required for DWMMC.
> >>> Adds FDT support for DWMMC.
> >>> Adds EMMC boot support for SMDK5250.
> >>>
> >>> This patch set is based on:
> >>> "EXYNOS: mmc: support DesignWare Controller for Samsung-SoC", which
> >>> is merged in u-boot-mmc.
> >>> "Exynos: clock: support get_mmc_clk for exynos".
> >>> "Add DT based ethernet driver for SMDK5250".
> >>> "SMDK5250: Add FDT support" present at the following link
> >>> http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/149991
> >>>
> >>> Changes since V1:
> >>> 1)Corrected in response to review comments.
> >>> 2)Created separate board files for FDT and non-FDT versions.
> >>> 3)Added binding file for DWMMC device node.
> >>> 4)Removed the propname 'index' from device node.
> >>> 5)Prefixed the vendor name 'samsung' before propname in device
> node.
> >>> 6)Ensured to have same signature for the function
> exynos_dwmci_init()
> >>> for both FDT and non-FDT versions.
> >>> 7)EMMC clock setting has been moved from spl_boot.c to
> clock_init.c.
> >>>
> >>> Changes since V2:
> >>> 1)Updation of commit message and resubmition of proper patch
> set.
> >>>
> >>> Changes since V3:
> >>> 1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of
> the
> >>> hard coded value (1 << 10).
> >>> 2)In the file exynos_dw_mmc.c, replaced the new function
> >>> exynos5_mmc_set_clk_div() with the existing function
> set_mmc_clk().
> >>> set_mmc_clk() will do the purpose.
> >>> 3)In the file exynos_dw_mmc.c, computation of FSYS block clock
> >>> divisor (pre-ratio) value is added.
> >>> 4)Removed the new function exynos5_mmc_set_clk_div() from
> clock.c.
> >>>
> >>> Changes since V4:
> >>> 1)Updated the function dwmci_send_cmd() to use get_timer()
> instead
> >>> of using mdelay(1).
> >>> 2)Replaced the function call 'exynos_dwmmc_init(0, 8);' with
> the
> >>> function exynos_dwmmc_add_port() in smdk5250.c.
> >>> 3)The function get_irom_func(int index) has been added to avoid
> >>> type casting at many places.
> >>> 4)Used the generic function "mmc_boot_part_access()" instead
> of two
> >>> functions "mmc_boot_open()" and "mmc_boot_close()". By doing
> so user
> >>> can specify which boot partition to be accessed (opened /
> closed).
> >>>
> >>> Changes since V5:
> >>> 1)Added the 'removable' flag to mmc device node.
> >>> 2)Changed the mmc clock value from 50MHz to 52MHz in the
> function
> >>> exynos_dwmci_add_port() present in file
> drivers/mmc/exynos_dw_mmc.c.
> >>> 3)Enabled CONFIG_LCD only for non-FDT operation.
> >>> 4)Removed the function call i2c_init() present inside the
> >>> function board_i2c_init().
> >>>
> >>> Changes since V6:
> >>> 1)Re-based to the patch "SMDK5250: Add PMIC voltage settings".
> >>>
> >>> Changes since V7:
> >>> 1)Re-based to the patch
> >>> "Exynos: pwm: Remove dead code of function
> exynos5_get_pwm_clk".
> >>> 2)In file dw_mmc.c, updated the function dwmci_setup_bus() to
> >>> return 0 if (freq == 0).This is to avoid the run time exception
> >>> "raise:Signal # 8 caught".
> >>> 3)In the files drivers/mmc/mmc.c and common/cmd_mmc.c, the
> piece
> >>> of code involved in EMMC open/close and resize of EMMC boot
> >>> partition has been made conditional and is enabled only if the
> >>> macro CONFIG_SUPPORT_EMMC_BOOT is defined.
> >>> 4)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are
> made
> >>> local to file clock_init.c.
> >>>
> >>> Changes since V8:
> >>> 1)Re-based to the patch
> >>> "exynos: fdt: Add TMU node for snow".
> >>> 2)In spl_boot.c, updated USB boot piece of code, to use
> >>> get_irom_func(int index) to avoid type casting.
> >>> 3)Updated the below in response to review comments
> >>> a)Changed the type of input parameters from u32 to u8 for the
> >>> function boot_part_a

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi,

On Wed, May 29, 2013 at 4:07 PM, Stephen Warren wrote:

> On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
> > Dear Stephen Warren,
> >
> > In message <51a67ec1.2000...@wwwdotorg.org> you wrote:
> >>
> >> To keep this process in check a bit, we could always pick a specific git
> >> commit or release version of dtc that each U-Boot version (release) will
> >> be allowed to assume. That will limit the number of times people need to
> >> update their locally-built dtc to at most once per U-Boot release.
> >> Hopefully much less often.
> >
> > I think this is broken by design, in several aspects.  First, U-Boot
> > is usually not the only user of DTC.  Second, assume you run a "git
> > bisect" over a U-Boot tree - would you really want to switch DTC in-
> > flight?
> >
> > Sorry, instead we should strive to be compatible to a reasonably old,
> > stable version of DTC, like we do for all other tools as well.  As
> > mentioned before - just because RHEL 5 ships an ancient version of -
> > say - "make" we will NOT start building this from the sources ourself.
> > This cannot be the way to go.
>
> So the result of that is that we can never ever use new features in any
> tool, at least in any meaningful time-frame.
>
> I think we need to differentiate between tools that are already stable
> and/or core to all aspects of the U-Boot build process (such as make),
> and tools that enable new features that are under development.
>
> Clearly the U-Boot makefiles have to be fairly cautious in their use of
> any new make features, so that everyone with any reasonable version of
> make can build U-Boot.
>
> However, when enabling a new feature, such as using device trees to
> configure U-Boot[1], for which tool support is new and evolving along
> with the feature itself, and which is only used on a very very few
> boards and even fewer SoCs right now within U-Boot, it seems entirely
> reasonable to demand that the people working on/with that new feature
> are aware that it's evolving, and that they may need to take a few extra
> steps to go out and get tools that support that new feature. No doubt
> once this feature has settled down a bit, and distros have pulled in
> newer versions of dtc, everthing will "just work" just like any other
> stable feature.
>
> If you don't accept this, then we simply have to ban any include use in
> U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to
> stop using that. We'd need to move *.dts into a single directory within
> U-Boot to work around that, or perhaps hard-coding relative include
> paths in *.dts might work. Similarly for the patches to support dtc+cpp
> usage, so we wouldn't be able to use named constants in DT files for
> many years, which would prevent sharing DT files with the kernel and/or
> any other standard repository of DT files, which are bound to use this
> feature.
>
> [1] Which is very specifically a different feature than simply having
> U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it
> a little, which clearly is not a new feature.
>

My patch:

- doesn't require -i but uses it if available (ARCH_CPU_DTS works around
this)
- honours #define, #include, etc.
- works with old and new versions of dtc
- uses -Ulinux which we are thinking might be better done another way

Let's not throw the baby out with the bathwater. I have no problem with
updating my dtc as needed, but it would certainly be nice if U-Boot didn't
require this.

However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we
should just add a setting to tell U-Boot to not build the device tree at
all? The same U-Boot binary can run on many different board times, just
needing a different device tree. Rather than pick one, we could just pick
none. Then if you want to use new features in dtc, just define
CONFIG_OF_NO_BUILD, or similar, and you can deal with the device tree
details yourself. MAKEALL/buildman will be happy with this.

Otherwise for now I think my patch is a reasonable compromise in terms of
features.

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

Re: [U-Boot] [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode

[Simon Glass]

Hi,

On Tue, May 28, 2013 at 11:10 PM, Rajeshwari Shinde <
rajeshwar...@samsung.com> wrote:

> This patch set enables PREAMBLE Mode for EXYNOS SPI.
>
> Changes in v2:
> - Remove preamable_count variable which is not really needed
> - Fix checkpatch warning (multiple assignments)
> Changes in V3:
> - Modified the if logic in spi_rx_tx function
> - Added blank lines as suggested by Minkyu Kang.
> - Removed in_bytes check in while loop.
> - Added a error check.
> Changes in V4:
> - Corrected a if condition.
> Changes in V5:
> - In commit message header changed
> SPI to spi
> EXYNOS: SPI: to spi: exynos:
>
> Rajeshwari Shinde (2):
>   spi: Add support for preamble bytes
>   spi: exynos: Support SPI_PREAMBLE mode
>

Hoping these patches can be applied soon...

Regards,
Simon



>
>  drivers/spi/exynos_spi.c |   69
> +++--
>  include/spi.h|5 +++
>  2 files changed, 64 insertions(+), 10 deletions(-)
>
> --
> 1.7.4.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's

[Lokesh Vutla]

Hi,
On Wednesday 29 May 2013 06:42 PM, Tom Rini wrote:

On Wed, May 29, 2013 at 04:32:35PM +0530, Lokesh Vutla wrote:


This series update support for DRA7xx family Socs and the data for
DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-0-3-ARM-OMAP4-Misc-Cleanup-tt155877.html

Tested on DRA752 ES1.0, OMAP5432 ES2.0,
MAKEALL for all armv7 board has been verified.


Aside from a few comments, everything else looks good.  Oh, and please
test with MAKEALL -s omap as well as -c armv7, thanks!

Thanks Tom. Will address your comments and post a V2.
Ok will do MAKEALL for omap boards also.

Regards,
Lokesh




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

[U-Boot] fopen/fwrite functions

[TigerLiu]

Hi, experts:
Could i use fopen/fwrite standard C lib functions in U-boot code?

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

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <51a67ec1.2000...@wwwdotorg.org> you wrote:
>>
>> To keep this process in check a bit, we could always pick a specific git
>> commit or release version of dtc that each U-Boot version (release) will
>> be allowed to assume. That will limit the number of times people need to
>> update their locally-built dtc to at most once per U-Boot release.
>> Hopefully much less often.
> 
> I think this is broken by design, in several aspects.  First, U-Boot
> is usually not the only user of DTC.  Second, assume you run a "git
> bisect" over a U-Boot tree - would you really want to switch DTC in-
> flight?
> 
> Sorry, instead we should strive to be compatible to a reasonably old,
> stable version of DTC, like we do for all other tools as well.  As
> mentioned before - just because RHEL 5 ships an ancient version of -
> say - "make" we will NOT start building this from the sources ourself.
> This cannot be the way to go.

So the result of that is that we can never ever use new features in any
tool, at least in any meaningful time-frame.

I think we need to differentiate between tools that are already stable
and/or core to all aspects of the U-Boot build process (such as make),
and tools that enable new features that are under development.

Clearly the U-Boot makefiles have to be fairly cautious in their use of
any new make features, so that everyone with any reasonable version of
make can build U-Boot.

However, when enabling a new feature, such as using device trees to
configure U-Boot[1], for which tool support is new and evolving along
with the feature itself, and which is only used on a very very few
boards and even fewer SoCs right now within U-Boot, it seems entirely
reasonable to demand that the people working on/with that new feature
are aware that it's evolving, and that they may need to take a few extra
steps to go out and get tools that support that new feature. No doubt
once this feature has settled down a bit, and distros have pulled in
newer versions of dtc, everthing will "just work" just like any other
stable feature.

If you don't accept this, then we simply have to ban any include use in
U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to
stop using that. We'd need to move *.dts into a single directory within
U-Boot to work around that, or perhaps hard-coding relative include
paths in *.dts might work. Similarly for the patches to support dtc+cpp
usage, so we wouldn't be able to use named constants in DT files for
many years, which would prevent sharing DT files with the kernel and/or
any other standard repository of DT files, which are bound to use this
feature.

[1] Which is very specifically a different feature than simply having
U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it
a little, which clearly is not a new feature.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality

[Scott Wood]

On 05/28/2013 09:11:17 PM, Zhang Ying-B40530 wrote:



-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, May 29, 2013 6:34 AM
To: Zhang Ying-B40530
Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie  
Xiaobo-R63061; Ilya Yanok
Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more  
functionality


On 05/22/2013 08:26:31 PM, Zhang Ying-B40530 wrote:
>
>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, May 22, 2013 11:46 PM
> To: Zhang Ying-B40530
> Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie
> Xiaobo-R63061; Ilya Yanok
> Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more
> functionality
>
> On 05/21/2013 09:15:08 PM, Zhang Ying-B40530 wrote:
> > > diff --git a/include/configs/MPC8313ERDB.h
> > > b/include/configs/MPC8313ERDB.h
> > > index c28dfe0..a2bdcff 100644
> > > --- a/include/configs/MPC8313ERDB.h
> > > +++ b/include/configs/MPC8313ERDB.h
> > > @@ -40,7 +40,9 @@
> > >  #define CONFIG_SPL_INIT_MINIMAL
> > >  #define CONFIG_SPL_SERIAL_SUPPORT
> > >  #define CONFIG_SPL_NAND_SUPPORT
> > > +#ifdef CONFIG_SPL_BUILD
> > >  #define CONFIG_SPL_NAND_MINIMAL
> > > +#endif
> > >  #define CONFIG_SPL_FLUSH_IMAGE
> > >  #define CONFIG_SPL_TARGET   "u-boot-with-spl.bin"
> > >  #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
> > > diff --git a/include/configs/P1022DS.h  
b/include/configs/P1022DS.h

> > > index 8b13b10..5bdd44a 100644
> > > --- a/include/configs/P1022DS.h
> > > +++ b/include/configs/P1022DS.h
> > > @@ -41,7 +41,9 @@
> > >  #define CONFIG_SPL_INIT_MINIMAL
> > >  #define CONFIG_SPL_SERIAL_SUPPORT
> > >  #define CONFIG_SPL_NAND_SUPPORT
> > > +#ifdef CONFIG_SPL_BUILD
> > >  #define CONFIG_SPL_NAND_MINIMAL
> > > +#endif
> > >  #define CONFIG_SPL_FLUSH_IMAGE
> > >  #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
> > >
> > > diff --git a/include/configs/p1_p2_rdb_pc.h
> > > b/include/configs/p1_p2_rdb_pc.h
> > > index 7ed634b..bc48d62 100644
> > > --- a/include/configs/p1_p2_rdb_pc.h
> > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > @@ -159,7 +159,9 @@
> > >  #define CONFIG_SPL_INIT_MINIMAL
> > >  #define CONFIG_SPL_SERIAL_SUPPORT
> > >  #define CONFIG_SPL_NAND_SUPPORT
> > > +#ifdef CONFIG_SPL_BUILD
> > >  #define CONFIG_SPL_NAND_MINIMAL
> > > +#endif
> > >  #define CONFIG_SPL_FLUSH_IMAGE
> > >  #define CONFIG_SPL_TARGET   "u-boot-with-spl.bin"
> >
> > Are you sure this belongs in this patch?
> > [Zhang Ying]
> > Yes, it is necessary. Because CONFIG_SPL_NAND_MINIMAL has been  
used

> > in the file law.c and tlb.c in this patch.
>
> What I mean is that it should probably have been done earlier, when
> you
> introduced CONFIG_SPL_NAND_MINIMAL.
> [Zhang Ying]
> I can understand you mean. Because the symbol
> "CONFIG_SPL_NAND_MINIMAL" has been useless, I think no need to split
> out a separate patch.

OK, it looks like CONFIG_SPL_NAND_MINIMAL was there before your
patchset.  I think that was an accidental left-over and should have
been removed (it was replaced with CONFIG_SPL_NAND_DRIVERS, _BASE, and
_ECC).

Could you describe what specifically you're using it to mean here?
[Zhang Ying]
CONFIG_SPL_NAND_MINIMAL is effective only for mpc85xx NAND SPL.


No, it's just a mistake that should be removed.  It doesn't mean  
anything.  There are other SPL targets that use minimal NAND drivers  
(e.g. mxc_nand_spl.c) that don't define this.


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

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/29/2013 03:33 PM, Wolfgang Denk wrote:
> Dear Stephen,
> 
> In message <51a634b5.5060...@wwwdotorg.org> you wrote:
>>
>>> I think this is not a good way to address this issue.  The GCC
>>> documentation (section "System-specific Predefined Macros" [1])
>>> desribes how this should be handled.  The "correct" (TM) way to fix
>>> this is by adding "-ansi" or any "-std" option that requests strict
>>> conformance to the compiler/preprocessor command line.
>>>
>>> [1] 
>>> http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros
>>
>> -ansi at least was considered when the Linux kernel patches for dtc+cpp
>> support were being developed, but it was rejected. While it possibly
> 
> Can you provide references?  I'd like to understand why it was
> rejected - it seems to be the "official" approach to the problem.
> 
>> does solve this specific issue fine, there were other more general
>> problems; IIRC (and I might not) it completely changes the way macro
>> expansion happens, which results in it being pretty useless. Hence, "-x
>> assembler-with-cpp" was chosen over e.g. "-ansi".
> 
> Again, do you have any reference?  "completely changes the way macro
> expansion happens" sounds terribly dangerous, so it would be better to
> know about that exactly...

Sorry, I was thinking about -traditional-cpp, not -ansi. We had
considered -traditional-cpp as a workaround because DT uses property
names that start with #, and this triggered cpp to treat them as macro
names, which went wrong. However, due to -traditional-cpp being quite
different from ISO cpp, we selected -x assembler-with-cpp instead, which
both implements an ISO cpp, but also only handles pre-processing
directives with the # in column 1.

Now, let's discuss -ansi vs. -undef some more.

Since DT is supposed to be a HW description, it shouldn't be using cpp's
built-in macros to compile in different ways; there really isn't a
concept of the "target arch of compilation"; a .dts file should simply
compile the same way everywhere. Different DTs represent different HW;
we don't use a single DT with conditional compilation to represent
different HW. This led Rob Herring (one of the kernel device tree
maintainers) to propose the following rules for cpp usage on device trees:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-October/020831.html

One of which was:

- No gcc built-in define usage

I don't see any disagreement with that bullet point in the thread, and
indeed it makes sense to me for the reasons I outlined above.

Some history on why we needed to not-define, or un-define, some macros
(such as the linux macro we're discussing here) can be found in:

http://linux-kernel.2935.n7.nabble.com/PATCH-V7-kbuild-create-a-rule-to-run-the-pre-processor-on-dts-files-td575632.html

The last few messages there end up mentioning -undef, which we/I ended
up using. It looks like -ansi wasn't mentioned at all when discussing
this issue.

However, I assert that -undef is better, since we end up without any
pre-defined macros, which DT files shouldn't be using anyway. By my
reading of the cpp manual link you send, -ansi simply stops
non-conforming pre-defined macros from being defined, but doesn't stop
them all being defined as -undef does. Hence, I prefer -undef.

Oh, and another of Rob's proposed rules:

- No kernel kconfig option usage

Would also imply that U-Boots config headers shouldn't be accessible
when compiling device trees. The last few kernel patches I sent to
enable dtc+cpp usage were specifically aimed at limiting the set of
headers that DT files can use to those specifically part of the DT
bindings, and not general Linux headers, For example, see the following
Linux kernel commit:

==
kbuild: create an "include chroot" for DT bindings

The recent dtc+cpp support allows header files and C pre-processor
defines/macros to be used when compiling device tree files. These
headers will typically define various constants that are part of the
device tree bindings.

The original patch which set up the dtc+cpp include path only considered
using those headers from device tree files. However, most are also
useful for kernel code which needs to interpret the device tree.

In both the DT files and the kernel, I'd like to include the DT-related
headers in the same way, for example, .
That will simplify any text which discusses the DT header locations.

Creating a  for kernel source to use is as simple as
placing files into include/dt-bindings/.

However, when compiling DT files, the include path should be restricted
so that only the dt-bindings path is available; arbitrary kernel headers
shouldn't be exposed. For this reason, create a specific include
directory for use by dtc+cpp, and symlink dt-bindings from there to the
actual location of include/dt-bindings/. For want of a better location,
place this "include chroot" into the existing dts/ directory.

arch/*/boot/dts/include/dt-bindings -> ../.

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Wolfgang Denk]

Dear Stephen Warren,

In message <51a67ec1.2000...@wwwdotorg.org> you wrote:
>
> To keep this process in check a bit, we could always pick a specific git
> commit or release version of dtc that each U-Boot version (release) will
> be allowed to assume. That will limit the number of times people need to
> update their locally-built dtc to at most once per U-Boot release.
> Hopefully much less often.

I think this is broken by design, in several aspects.  First, U-Boot
is usually not the only user of DTC.  Second, assume you run a "git
bisect" over a U-Boot tree - would you really want to switch DTC in-
flight?

Sorry, instead we should strive to be compatible to a reasonably old,
stable version of DTC, like we do for all other tools as well.  As
mentioned before - just because RHEL 5 ships an ancient version of -
say - "make" we will NOT start building this from the sources ourself.
This cannot be the way to go.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

[Lubomir Popov]

Tested on OMAP4/5 only, but should work on older OMAPs and
derivatives as well.

- Rewritten i2c_read to operate correctly with all types of chips
  (old function could not read consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
  performs write access vs read. The old probe could hang the system
  under certain conditions (e.g. unconfigured pads).
- The read/write/probe functions try to identify unconfigured bus.
- Status functions now read irqstatus_raw as per TRM guidelines
  (except for OMAP243X and OMAP34XX).
- Driver now supports up to I2C5 (OMAP5).

Signed-off-by: Lubomir Popov 
---
V3 changes:
- Removed old functions and conditional compilation. New functions
  are now built unconditionally for all SoCs using this driver. The
  only chip that should break is the OMAP2420 dinosaur.
- Interrupts are enabled for OMAP243X and OMAP34XX only (where we
  don't have an irqstatus_raw register).
V2 changes:
- Probe tries to identify misconfigured pads as well.
- Status is retrieved from irqstatus_raw rather than from stat.
- Some minor style & format changes.

 drivers/i2c/omap24xx_i2c.c | 482 ++---
 1 file changed, 326 insertions(+), 156 deletions(-)
 mode change 100644 => 100755 drivers/i2c/omap24xx_i2c.c

diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
old mode 100644
new mode 100755
index 54e9b15..deac0ec
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,18 @@
  *
  * Adapted for OMAP2420 I2C, r-woodru...@ti.com
  *
+ * Copyright (c) 2013 Lubomir Popov , MM Solutions
+ * New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4/5
+ * only, but should work on older OMAPs and derivatives as well.
+ * - Rewritten i2c_read to operate correctly with all types of chips
+ *   (old function could not read consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
+ *   performs write access vs read. The old probe could hang the system
+ *   under certain conditions (e.g. unconfigured pads).
+ * - The read/write/probe functions try to identify unconfigured bus.
+ * - Status functions now read irqstatus_raw as per TRM guidelines.
+ * - Driver now supports up to I2C5 (OMAP5).
  */

 #include 
@@ -31,8 +43,11 @@ DECLARE_GLOBAL_DATA_PTR;

 #define I2C_TIMEOUT1000

+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT   200
+
 static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
 static void flush_fifo(void);

 /*
@@ -137,10 +152,14 @@ void i2c_init(int speed, int slaveadd)
/* own address */
writew(slaveadd, &i2c_base->oa);
writew(I2C_CON_EN, &i2c_base->con);
-
-   /* have to enable intrrupts or OMAP i2c module doesn't work */
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+   /*
+* Have to enable interrupts for OMAP2/3, these IPs don't have
+* an 'irqstatus_raw' register and we shall have to poll 'stat'
+*/
writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
I2C_IE_NACK_IE | I2C_IE_AL_IE, &i2c_base->ie);
+#endif
udelay(1000);
flush_fifo();
writew(0x, &i2c_base->stat);
@@ -150,88 +169,6 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
 }

-static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
-{
-   int i2c_error = 0;
-   u16 status;
-   int i = 2 - alen;
-   u8 tmpbuf[2] = {(regoffset) >> 8, regoffset & 0xff};
-   u16 w;
-
-   /* wait until bus not busy */
-   if (wait_for_bb())
-   return 1;
-
-   /* one byte only */
-   writew(alen, &i2c_base->cnt);
-   /* set slave address */
-   writew(devaddr, &i2c_base->sa);
-   /* no stop bit needed here */
-   writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, &i2c_base->con);
-
-   /* send register offset */
-   while (1) {
-   status = wait_for_pin();
-   if (status == 0 || status & I2C_STAT_NACK) {
-   i2c_error = 1;
-   goto read_exit;
-   }
-   if (status & I2C_STAT_XRDY) {
-   w = tmpbuf[i++];
-#if !(defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
-   defined(CONFIG_OMAP44XX) || defined(CONFIG_AM33XX) || \
-   defined(CONFIG_OMAP54XX))
-   w |= tmpbuf[i++] << 8;
-#endif
-   writew(w, &i2c_base->data);
-   writew(I2C_STAT_XRDY, &i2c_base->stat);
-   }
-   if (status & I2C_STAT_ARDY) {
-   writew(I2C_STAT_ARDY, &i2c_base->stat);
-   break;
-   }
-   }
-
-   /* set slave address */
-   writew(devaddr, &i2c_ba

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/29/2013 03:31 PM, Wolfgang Denk wrote:
> Dear Stephen,
> 
> In message <51a62f8d.9010...@wwwdotorg.org> you wrote:
>>
>> The Linux kernel chose to solve this by bundling the required dtc source
>> inside the kernel source tree as a tool. This seems by far the simplest
>> way to solve the problem for U-Boot too. If not, it's not exactly hard to:
> 
> Actually it's a horrible approach to fixing tool issues upstream.
> Or rather to NOT fixing issues.  Instead of pushing forward that
> distros distribute useful, recent versions we simply copy the dtc
> source.

I don't understand the hangup about the version of dtc that distros package.

Sure, it'd be nice if distros updated the the (currently) latest version
of dtc and packaged that, so that at some time the desired version was
there, and everything "just worked".

However, that's not going to outright solve the problem for a /long/ time.

What if someone wants to build U-Boot on Ubuntu 10.04 or RHEL 5. It
seems quite reasonable for someone to be using those for development
since they're long-term supported stable releases. Those releases don't
have the (current) latest version of dtc packaged, and it's exceedingly
unlikely anyone could push an update into those distros to update dtc,
since they're probably in bug-fix-only mode right now, and a dtc update
would be to add new features.

So, to cover that issue we must:

a) Get the latest dtc into distros right now. Wait until everyone has
updated. Then, we can use the new features. This could take many many years.

b) Simply require people to install dtc from source, if their distro
doesn't already package the desired version. This will immediately solve
the problem, and is honestly quite simple if you're already building
other things (U-Boot) from source.

I prefer option (b) here. And given that, I assert that whatever version
distros package is largely irrelevant, since there's a trivial
workaround if they don't have the desired version.

Longer-term distros will pick up a new version, and remove the need for
build-from-source, thus streamlining the process.

To keep this process in check a bit, we could always pick a specific git
commit or release version of dtc that each U-Boot version (release) will
be allowed to assume. That will limit the number of times people need to
update their locally-built dtc to at most once per U-Boot release.
Hopefully much less often.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Wolfgang Denk]

Dear Stephen,

In message <51a634b5.5060...@wwwdotorg.org> you wrote:
>
> > I think this is not a good way to address this issue.  The GCC
> > documentation (section "System-specific Predefined Macros" [1])
> > desribes how this should be handled.  The "correct" (TM) way to fix
> > this is by adding "-ansi" or any "-std" option that requests strict
> > conformance to the compiler/preprocessor command line.
> > 
> > [1] 
> > http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros
> 
> -ansi at least was considered when the Linux kernel patches for dtc+cpp
> support were being developed, but it was rejected. While it possibly

Can you provide references?  I'd like to understand why it was
rejected - it seems to be the "official" approach to the problem.

> does solve this specific issue fine, there were other more general
> problems; IIRC (and I might not) it completely changes the way macro
> expansion happens, which results in it being pretty useless. Hence, "-x
> assembler-with-cpp" was chosen over e.g. "-ansi".

Again, do you have any reference?  "completely changes the way macro
expansion happens" sounds terribly dangerous, so it would be better to
know about that exactly...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"You shouldn't make my toaster angry." - Household security explained
in "Johnny Quest"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Wolfgang Denk]

Dear Stephen,

In message <51a62f8d.9010...@wwwdotorg.org> you wrote:
>
> The Linux kernel chose to solve this by bundling the required dtc source
> inside the kernel source tree as a tool. This seems by far the simplest
> way to solve the problem for U-Boot too. If not, it's not exactly hard to:

Actually it's a horrible approach to fixing tool issues upstream.
Or rather to NOT fixing issues.  Instead of pushing forward that
distros distribute useful, recent versions we simply copy the dtc
source.  Tomorrow we include the source tree for "make", and next week
for "binutils" and "gcc".  And in a few months we build a full distro.

It's the same with the Kconfig approach to print only short compile
messages - instead of fixing this once where it belongs (in "make"), a
zillion projects copy the pretty expensive code around, because it is
so much easier.

It's frustrating to watch how good old methods that brought free
software to the state we have today (or we had some time ago already)
more and more get lost and forgotten :-(

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A rolling stone gathers momentum.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Wolfgang Denk]

Dear Simon,

In message  
you wrote:
> 
> > I think this is not a good way to address this issue.  The GCC
> > documentation (section "System-specific Predefined Macros" [1])
> > desribes how this should be handled.  The "correct" (TM) way to fix
> > this is by adding "-ansi" or any "-std" option that requests strict
> > conformance to the compiler/preprocessor command line.
> >
> > [1] 
> > http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros
> 
> Stephen suggested a slightly more extreme version too - I was worried
> that all the typing stuff in U-Boot headers would break in this case,
> but I didn't actually test it, so perhaps it is fine.

Yes, I've seen it.  I think either approach is better that manually
undef-ing specific variables.  From my personal point of view I think
the -undef approach is a bit of overkill, but I would not protest.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
panic: can't find /
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/28/2013 03:08 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
> 
> In message <1369769778-12455-1-git-send-email-...@chromium.org> you wrote:
>>
>> Some device tree files use the word 'linux' which gets replaced with '1' by
>> many version of gcc, including version 4.7. So undefine this.
> 
> I think this is not a good way to address this issue.  The GCC
> documentation (section "System-specific Predefined Macros" [1])
> desribes how this should be handled.  The "correct" (TM) way to fix
> this is by adding "-ansi" or any "-std" option that requests strict
> conformance to the compiler/preprocessor command line.
> 
> [1] 
> http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros

-ansi at least was considered when the Linux kernel patches for dtc+cpp
support were being developed, but it was rejected. While it possibly
does solve this specific issue fine, there were other more general
problems; IIRC (and I might not) it completely changes the way macro
expansion happens, which results in it being pretty useless. Hence, "-x
assembler-with-cpp" was chosen over e.g. "-ansi".
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/29/2013 09:59 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Tue, May 28, 2013 at 1:57 PM, Stephen Warren  wrote:
>> On 05/28/2013 01:36 PM, Simon Glass wrote:
>>> There are a few partially conflicting requirements in compiling the device
>>> tree, since U-Boot relies on whatever is installed on the build machine.
>>>
>>> Some versions of dtc support -i, and this is often better than using 
>>> #include
>>> since you get correct line number information in errors.
>>
>> What issue is there with line numbers when using dtc? Recent dtc
>> supports #line directives from the pre-processing results, and hence
>> reports errors in terms of the source files, just like raw dtc without cpp.
> 
> That's the issue. What does dtc v1.3 do?

v1.3 doesn't include the feature, but it also doesn't support -i either.

>>> Unfortunately this
>>> version must be installed manually in current Linux distributions.
>>
>> Well, then that gets into the problem of some .dts files choosing to use
>> /include/ and rely on -i, but others using #include and not. I don't
>> really think it's a good idea to propagate both versions. Picking one
>> and using it would be far better.
>>
>> I really do think we should simply require a reasonably recent dtc and
>> be done with it.
> 
> I would be happy with that, but it can be an extra barrier to getting
> U-Boot building.

The Linux kernel chose to solve this by bundling the required dtc source
inside the kernel source tree as a tool. This seems by far the simplest
way to solve the problem for U-Boot too. If not, it's not exactly hard to:

git clone
make

... given that one is already building U-Boot from source anyway.


> So do we need using #include at all if we are using -i ?

Well, *.dts are moving to #include (and other cpp constructs) rather
than /include/ in the copies in the Linux kernel, which I think will
eventually make their way into U-Boot for consistency. Equally, if/when
*.dts get separated out into a separate project from the kernel, I think
we'd want the same to happen for U-Boot so that the same *.dts is used.
Then, there won't be a choice.

>>> Some device tree files use the word 'linux' which gets replaced with '1' by
>>> many version of gcc, including version 4.7. So undefine this.
>>
>> Linux chose to use -undef rather than undefining specific/individual
>> defines. It'd be best to be consistent to that .dts files are more
>> likely to be portable between the two.
> 
> Seems a bit extreme, but OK. Are you worried that gcc defines other
> things without the double underscore?

IIRC there were some other issues, yes. "unix" may have been one of
them. The problem was reported (and I think that fix suggested) by
someone else, so I don't remember the full details, although they're in
the mailing list archives I suppose.

>>> diff --git a/dts/Makefile b/dts/Makefile

>>>   
>>> -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
>>>  \
>>>   
>>> -DBOARD_DTS=\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\" \
>>> - -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
>>> + -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
>>> + -I$(OBJTREE)/include2 \
>>
>> Do we really want include or include2 (what's that?) at all? The .dts
>> files really should be standalone, and not interact with the U-Boot
>> headers at all.
> 
> I understood that you were wanting to make use of U-Boot defines. If
> you want to include include/config.h then I think you need these.

I hope I didn't want to:-) The DT should really represent the HW not
anything about the way U-Boot is configured.

>>> + -include $(OBJTREE)/include/config.h
>>> +
>>> +DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
>>
>> Hmm. This really isn't a generated header file. Can this instead be
>> $(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?
> 
> I didn't say header file.
> 
> The nice thing about having everything in include/generated is that it
> doesn't pollute the source for in-tree builds.

Well, it's in a directory that's for generated headers; it has
"/include/" in the path. I don't think we should put it somewhere that C
code could accidentally #include it, irrespective of how (un-)likely
that is to get passed review. Also, for in-tree builds, doesn't every
single other derived file get put into the source tree? I'm not sure why
this file would need to be special?

>>> +$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
>>>   rc=$$( \
>>> - cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \
>>> - { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \
>>> + cat $< | $(CPP) -P $(DTS_CPPFLAGS) - > $(DTS_TMP); \
>>> + { { $(DTC_CMD)  2>&1 ; \
>> ...
>>
>>> + if [ $$rc != 0 ]; then \
>>> + echo "Source file is $(DTS_SRC)"; \
>>> + echo "Compiler: $(DTC_CMD)"; \
>>> + fi; \
>>
>> Isn't that what make V=1 is for

Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master

[Albert ARIBAUD]

Hi Tom,

On Tue, 28 May 2013 14:16:41 -0700, Tom Warren
 wrote:

> Albert,
> 
> Please pull u-boot-tegra/master into ARM/master. Thanks!
> 
> ./MAKEALL for all the Tegra boards is OK, running a ./MAKEALL -a arm now.
> tools/checkpatch.pl is clean.
> 
> The following changes since commit fd725691797bb3192af15a15c2cba7d0b2ee9327:
> 
>   arm: Enable -ffunction-sections / -fdata-sections / --gc-sections
> (2013-05-23 12:09:56 +0200)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-tegra master
> 
> for you to fetch changes up to 60985bba58e7695dac1fddae8cdbb62d8cfd1254:
> 
>   tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build (2013-05-28
> 12:58:44 -0700)
> 
> 
> Allen Martin (1):
>   Tegra: clk: always use find_best_divider() for periph clocks
> 
> Axel Lin (2):
>   ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for
> cpu_init_crit
>   tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build
> 
> Stephen Warren (3):
>   tegra: always build u-boot-nodtb-tegra.bin
>   ARM: tegra: support SKU 1 of Tegra114
>   ARM: tegra: support SKU 7 of Tegra20
> 
> Tom Warren (2):
>   Tegra: T30: Beaver: Fix board/board_name env vars, s/b beaver, not
> cardhu
>   Tegra: Remove unused/non-existent spl linker script reference
> 
>  Makefile| 17 ++-
>  arch/arm/cpu/arm720t/start.S|  4 ++--
>  arch/arm/cpu/tegra-common/ap.c  |  2 ++
>  arch/arm/cpu/tegra-common/clock.c   | 10 -
>  arch/arm/include/asm/arch-tegra/tegra.h |  2 ++
>  board/nvidia/beaver/Makefile| 38
> +
>  boards.cfg  |  2 +-
>  include/configs/tegra-common-post.h |  2 ++
>  include/configs/tegra114-common.h   |  2 --
>  include/configs/tegra20-common.h|  2 --
>  include/configs/tegra30-common.h|  2 --
>  11 files changed, 59 insertions(+), 24 deletions(-)
>  create mode 100644 board/nvidia/beaver/Makefile

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi Wolfgang,

On Tue, May 28, 2013 at 2:08 PM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message <1369769778-12455-1-git-send-email-...@chromium.org> you wrote:
>>
>> Some device tree files use the word 'linux' which gets replaced with '1' by
>> many version of gcc, including version 4.7. So undefine this.
>
> I think this is not a good way to address this issue.  The GCC
> documentation (section "System-specific Predefined Macros" [1])
> desribes how this should be handled.  The "correct" (TM) way to fix
> this is by adding "-ansi" or any "-std" option that requests strict
> conformance to the compiler/preprocessor command line.
>
> [1] 
> http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros

Stephen suggested a slightly more extreme version too - I was worried
that all the typing stuff in U-Boot headers would break in this case,
but I didn't actually test it, so perhaps it is fine.

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

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi Stephen,

On Tue, May 28, 2013 at 1:57 PM, Stephen Warren  wrote:
> On 05/28/2013 01:36 PM, Simon Glass wrote:
>> There are a few partially conflicting requirements in compiling the device
>> tree, since U-Boot relies on whatever is installed on the build machine.
>>
>> Some versions of dtc support -i, and this is often better than using #include
>> since you get correct line number information in errors.
>
> What issue is there with line numbers when using dtc? Recent dtc
> supports #line directives from the pre-processing results, and hence
> reports errors in terms of the source files, just like raw dtc without cpp.

That's the issue. What does dtc v1.3 do?

>
>> Unfortunately this
>> version must be installed manually in current Linux distributions.
>
> Well, then that gets into the problem of some .dts files choosing to use
> /include/ and rely on -i, but others using #include and not. I don't
> really think it's a good idea to propagate both versions. Picking one
> and using it would be far better.
>
> I really do think we should simply require a reasonably recent dtc and
> be done with it.

I would be happy with that, but it can be an extra barrier to getting
U-Boot building. So do we need using #include at all if we are using
-i ?

>
>> Some device tree files use the word 'linux' which gets replaced with '1' by
>> many version of gcc, including version 4.7. So undefine this.
>
> Linux chose to use -undef rather than undefining specific/individual
> defines. It'd be best to be consistent to that .dts files are more
> likely to be portable between the two.

Seems a bit extreme, but OK. Are you worried that gcc defines other
things without the double underscore?

>
>> diff --git a/dts/Makefile b/dts/Makefile
>
>> +# Provide a list of include directories for dtc
>> +DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
>> +
>> +DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
>
> That has arch/ first then board/ ... (continued a few comments below)
>
>> +DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
>
> Is that meant to be upstream?
>
>> +# Check if our dtc includes the -i option
>> +DTS_FLAGS := $(shell if ! dtc -i 2>&1 | grep -q "invalid option"; then \
>> + echo $(DTS_INCS-y); fi)
>> +
>>  # We preprocess the device tree file provide a useful define
>> -DTS_CPPFLAGS := -x assembler-with-cpp \
>> +# Undefine 'linux' since it might be used in device tree files
>> +DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \
>
> I'll repeat my request to use -undef instead.
>
>>   
>> -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
>>  \
>>   
>> -DBOARD_DTS=\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\" \
>> - -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
>> + -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
>> + -I$(OBJTREE)/include2 \
>
> Do we really want include or include2 (what's that?) at all? The .dts
> files really should be standalone, and not interact with the U-Boot
> headers at all.

I understood that you were wanting to make use of U-Boot defines. If
you want to include include/config.h then I think you need these.

>
>> + -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts 
>> \
>
> ... whereas this has board/ first then arch/. It'd be better to be
> consistent.

OK

>
>> + -include $(OBJTREE)/include/config.h
>> +
>> +DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
>
> Hmm. This really isn't a generated header file. Can this instead be
> $(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?

I didn't say header file.

The nice thing about having everything in include/generated is that it
doesn't pollute the source for in-tree builds.

>
>> +DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
>>
>>  all: $(obj).depend $(LIB)
>>
>> @@ -50,13 +68,19 @@ all:  $(obj).depend $(LIB)
>>  # the filename.
>>  DT_BIN   := $(obj)dt.dtb
>>
>> -$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
>> +DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)
>
> It may be better to leave $(DTS_TMP) in the make script below, so it's
> more obvious what file is being compiled; the re-direct to $(DTS_TMP) is
> left in the $(CPP) invocation below, so it'd also be consistent with that.
>
>> +$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
>>   rc=$$( \
>> - cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \
>> - { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \
>> + cat $< | $(CPP) -P $(DTS_CPPFLAGS) - > $(DTS_TMP); \
>> + { { $(DTC_CMD)  2>&1 ; \
> ...
>
>> + if [ $$rc != 0 ]; then \
>> + echo "Source file is $(DTS_SRC)"; \
>> + echo "Compiler: $(DTC_CMD)"; \
>> + fi; \
>
> Isn't that what make V=1 is for?

It produces about 800KB of other spiel though. If the build fails it
is already printing stuff out - so I find this 

Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610

[Benoît Thébaudeau]

Hi Stefano,

On Wednesday, May 29, 2013 8:21:00 AM, Stefano Babic wrote:
> On 29/05/2013 07:29, Wang Huan-B18965 wrote:
> 
> >> Where is this one defined? I don't see it in include/configs/vf610twr.h.
> >>
> > [Alison Wang] CONFIG_IOMUX_SHARE_CONF_REG is defined in
> > arch/arm/include/asm/arch-vf610/imx-regs.h. Because this is not a board
> > configuration, it is related to the SOC.
> > 
> > Please refer to Stefano's comments below which also could be found in the
> > email on May 15th.
> > 
> > Stefano wrote:
> >> +
> >> +/* MUX mode and PAD ctrl are in one register */
> >> +#define CONFIG_IOMUX_SHARE_CONF_REG
> > 
> > NAK. This is not a board configuration, it is related to the SOC. This
> > setup should flow into the related imx-regs.h for this SOC. When you set
> > CONFIG_MVF600, this value should be set automatically.
> > 
> >> Why not use "#ifdef CONFIG_VF610" since this is a platform-dependent
> >> code, and not a board-specific config option?
> > [Alison Wang] I use this CONFIG_IOMUX_SHARE_CONF_REG option, because this
> > part of codes
> > not only could be used on VF610 platform, but also could be used on VF620
> > or other platforms.
> > When it is used on VF620 or others, you could just enable
> > CONFIG_IOMUX_SHARE_CONF_REG
> > in the related imx-regs.h.
> > Otherwise, if "ifdef CONFIG_VF610" is used, you need to add "#if
> > defined(CONFIG_VF610) || defined(CONFIG_VF620)"
> > When this part of codes is also used on VF620. Then when this part of codes
> > is used on VF630 too, this line
> > will be very very long.
> 
> Agree. This is a property of the processor and should be automatically
> set. It should not flow into board config file, and having a family of
> processor we cannot use ifdef CONFIG_VF610.
> 
> IMHO the patch is ok.
> 
> Acked-by: Stefano Babic 

I agree:
Reviewed-by: Benoît Thébaudeau 

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

Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board

[Benoît Thébaudeau]

Hi Alison,

On Wednesday, May 29, 2013 7:52:33 AM, Wang Huan-B18965 wrote:
> Hi, Benoit,
> 
> > > +
> > > +#define CONFIG_CMD_PING
> > > +#define CONFIG_CMD_DHCP
> > > +#define CONFIG_CMD_MII
> > > +#define CONFIG_CMD_NET
> > > +#define CONFIG_FEC_MXC
> > > +#define CONFIG_MII
> > > +#define IMX_FEC_BASE ENET_BASE_ADDR
> > > +#define CONFIG_FEC_XCV_TYPE  RMII
> > > +#define CONFIG_FEC_MXC_PHYADDR  0
> > 
> > Why don't you add support for the 2nd FEC? Do you plan to do it later?
> [Alison Wang] In u-boot, one FEC is enough for user. We do not plan to do it
> later.
> > 
> > > +#define CONFIG_PHYLIB
> > > +#define CONFIG_PHY_MICREL
> > > +
> > > +#define CONFIG_BOOTDELAY 3
> > > +
> > > +#define CONFIG_SYS_TEXT_BASE 0x3f008000
> > > +
> > > +/* Miscellaneous configurable options */
> > > +#define CONFIG_SYS_LONGHELP  /* undef to save memory */
> > > +#define CONFIG_SYS_HUSH_PARSER   /* use "hush" command parser
> > */
> > > +#define CONFIG_SYS_PROMPT_HUSH_PS2   "> "
> > > +#define CONFIG_SYS_PROMPT"Vybrid U-Boot > "
> > > +#undef CONFIG_AUTO_COMPLETE
> > > +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer 
> > > Size */
> > > +#define CONFIG_SYS_PBSIZE\
> > > + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
> > > +#define CONFIG_SYS_MAXARGS   16  /* max number of 
> > > command args
> > */
> > > +#define CONFIG_SYS_BARGSIZE  CONFIG_SYS_CBSIZE
> > > +
> > > +#define CONFIG_CMD_MEMTEST
> > > +#define CONFIG_SYS_MEMTEST_START 0x8001
> > > +#define CONFIG_SYS_MEMTEST_END   0x87C0
> > 
> > Please make sure to have runtime-tested this address range with the
> > mtest command since bad mtest addresses are the reason why
> > CONFIG_CMD_MEMTEST has been removed from the default commands.
> [Alison Wang] Thanks for your reminder, we have tested.

OK, then, for this patch:
Reviewed-by: Benoît Thébaudeau 

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

Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support

[Benoît Thébaudeau]

Hi Alison,

On Wednesday, May 29, 2013 7:37:32 AM, Wang Huan-B18965 wrote:
> Hi, Benoit,
> 
> > > > diff --git a/doc/README.vf610 b/doc/README.vf610 new file mode
> > > > 100644 index 000..38cf5cf
> > > > --- /dev/null
> > > > +++ b/doc/README.vf610
> > > > @@ -0,0 +1,10 @@
> > > > +U-Boot for Freescale Vybrid VF610
> > > > +
> > > > +This file contains information for the port of U-Boot to the
> > > > +Freescale
> > > > Vybrid
> > > > +VF610 SoC.
> > > > +
> > > > +1. CONVENTIONS FOR FUSE ASSIGNMENTS
> > > > +---
> > > > +
> > > > +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in
> > > > +word 2
> > > > and
> > > > the
> > > > +32 lsbs in word 3.
> > >
> > > The hunk below is still missing:
> > >
> > > doc/README.mxc_ocotp:
> > > ---
> > >  on MXC
> > >
> > >  This IP can be found on the following SoCs:
> > > + - Vybrid VF610,
> > >   - i.MX6.
> > >
> > >  Note that this IP is different from albeit similar to the IPs of the
> > > same  name
> > > ---
> > 
> > I have just noticed that this was actually in 6/7. Why are you putting
> > this into a separate patch?
> [Alison Wang] Because patch 2/7 is about VF610 CPU support, and
> doc/README.vf610 is also a document about
> VF610 SoC. Doc/README.mxc_ocotp is the document about a driver (IP OCOTP), so
> this driver document should be
> separated from CPU patch 2/7.

I don't think so: It's part of what comes with the addition of the VF610
platform, so 6/7 could be merged into 2/7. But it does not really matter. It's
probably also fine if you keep what you did.

Stefano, any opinion?

Best regards,
Benoît


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

Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/2013 09:33 AM, Sricharan R wrote:
> On Wednesday 29 May 2013 06:36 PM, Tom Rini wrote:
>> On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote:
>> 
>>> From: Sricharan R 
>>> 
>>> NON SECURE SRAM is 512KB in DRA7xx devices. So fixing it here.
>>> 
>>> Signed-off-by: Sricharan R  --- 
>>> arch/arm/include/asm/arch-omap5/omap.h |7 --- 
>>> include/configs/dra7xx_evm.h   |3 +++ 
>>> include/configs/omap5_uevm.h   |3 +++
>> No, we need to handle this in the include files, not the config
>> files.
>> 
> Ok.. The only concern was headers were shared between OMAP5/DRA and
> this results in #ifdef CONFIG_XX checks. Just thinking how to
> handle this better.

That's fine.  If we end up with large differences we can split the
files, ala am335x and ti814x (and later, ti816x).

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRpgg/AAoJENk4IS6UOR1WwpoP/0dzJxZRFRRStw96ef46hi8m
gtCBN4AXxTrv5+d2wgShOxmFTufTqHYJDi68kVKmrB3brMUjpgbp/ApTyi4a4vRh
Dim9VWHHnlFZOKHwJwfDNr6CTx4mPXmI2qs94pfzHOvFmGtfkhYRVF/wbF1XwgW5
86Qep+YW1mr62t3kact+Cg6Pln3Krbb3RjX3waUSZeKzOlifaSI3Dntvp2uLgrA2
YQCIVVYd3TE8L7utgHF48v8x7aRuAxcd5ZtZvtXoVAxXv3zFyyibGyBFFXxnMmLz
0dFwUm9mE1+MYATAjcxlB+OpD5bJDp30JhtF0s42rvrQGyBxy1mdLAQBxR0DxoPa
1GvhQgWKGJKhwXr9TSDT3N1DTCt0nPEzjs7iekz2NLHjhoYMPL/yfj0rliyfaw5o
O2S3I1d1Yy/V0gyLJgAey1SqC4G9n9XQyjsxAeSdosdDHSKUM3w6bkIS+UbTL8OZ
gq1MteO/fddvSGQIR5+YQ6R7boH3BenSOxJRiKNMWVXlDiqZGgMRSEqT/HGnrBgh
WBM0Va5c3HJjce4WXc+gWpJR+QREB6cHuc7lRGjI+VAKFioFDdaDXQSc2TJ6Q74W
QRwl0xCMgykvXekHG9t+KXrSBFh1cDiJXeyI9dD3UnvE09Hzu1DwPCZf/XfhcT+4
ic2Z/9fUSgPfHFqZqOnq
=/EmW
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot OMAP issues

[Lubomir Popov]

Hi Tom,

On 29/05/13 16:24, Tom Rini wrote:
> On 05/29/2013 02:34 AM, Lubomir Popov wrote:
>> Hi Tom,
>>
>> On 29.05.2013 01:55, Tom Rini wrote:
>>> On 05/27/2013 02:44 PM, Lubomir Popov wrote:
>>>
>>> P.S. I have an updated version of the I2C driver patch, with some
>>> minor
>>> improvements (mainly on identification of unconfigured bus). Should I
>>> submit it, what are you plans in respect to I2C?
>> Yes, please submit the i2c driver changes, I shall take them in some
>> form or another soon.
> OK, can even try to do this now from here.
 Submitted - http://patchwork.ozlabs.org/patch/246204/
 Looking at it again, I tend to dislike this solution more and more.
 Ugly ifdef-ed code. Couldn't we reconsider again adding this as a new
 driver, built for those SoCs that are confirmed to work (OMAP4 and 5
 for sure)?
>>> Lets take another swag at this.  Update the functions for everyone and
>>> I'll get some omap3 testing done.
>> OK, but you shall have to either entirely remove the ifdefs and the old
>> functions, or edit the
>> #if defined(CONFIG_OMAP)... conditions to include the SoC types you
>> are testing on.
> 
> Yeah.  If you don't repost the patch with just always using the new
> functions, I'll do some local yanking out.  I kinda hope to pencil that
> in as my task for tomorrow.  Thanks :)
> 
OK, I shall do it now. Does it matter if I base on u-boot-ti, or on mainline?
Guess not...

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

Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address

[Sricharan R]

On Wednesday 29 May 2013 06:36 PM, Tom Rini wrote:
> On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote:
>
>> From: Sricharan R 
>>
>> NON SECURE SRAM is 512KB in DRA7xx devices.
>> So fixing it here.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/include/asm/arch-omap5/omap.h |7 ---
>>  include/configs/dra7xx_evm.h   |3 +++
>>  include/configs/omap5_uevm.h   |3 +++
> No, we need to handle this in the include files, not the config files.
>
   Ok.. The only concern was headers were shared between
   OMAP5/DRA and this results in #ifdef CONFIG_XX checks.
   Just thinking how to handle this better.

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

Re: [U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks

[Sricharan R]

On Wednesday 29 May 2013 06:10 PM, Tom Rini wrote:
> On Wed, May 29, 2013 at 03:39:54PM +0530, Lokesh Vutla wrote:
>
>> From: Sricharan R 
>>
>> SGX clocks should be enabled only for OMAP5 ES1.0.
>> So this can be removed.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/cpu/armv7/omap5/hw_data.c |6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>> index 604fa42..842cf27 100644
>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>> @@ -383,12 +383,6 @@ void enable_basic_clocks(void)
>>   clk_modules_explicit_en_essential,
>>   1);
>>  
>> -/* Select 384Mhz for GPU as its the POR for ES1.0 */
>> -setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
>> -CLKSEL_GPU_HYD_GCLK_MASK);
>> -setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
>> -CLKSEL_GPU_CORE_GCLK_MASK);
>> -
>>  /* Enable SCRM OPT clocks for PER and CORE dpll */
>>  setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
>>  OPTFCLKEN_SCRM_PER_MASK);
> Wait, will everyone with ES1.0 be updating to ES2.0 and be OK with this?
> Lubomir's board is ES1.0, currently.  Thanks!
   Even if so, these clocks should/need not be enabled in boot loader.
   It should not have been enabled in, but earlier we had the habit
   enabling unnessecary things..
  
Regards,
 Sricharan

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

Re: [U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's

[Tom Rini]

On Wed, May 29, 2013 at 04:32:35PM +0530, Lokesh Vutla wrote:

> This series update support for DRA7xx family Socs and the data for
> DRA752 ES1.0 soc.
> This is on top of my recent Misc cleanup series:
> http://u-boot.10912.n7.nabble.com/PATCH-0-3-ARM-OMAP4-Misc-Cleanup-tt155877.html
> 
> Tested on DRA752 ES1.0, OMAP5432 ES2.0,
> MAKEALL for all armv7 board has been verified.

Aside from a few comments, everything else looks good.  Oh, and please
test with MAKEALL -s omap as well as -c armv7, 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 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Tom Rini]

On Wed, May 29, 2013 at 04:32:44PM +0530, Lokesh Vutla wrote:
> From: Balaji T K 
> 
> add dra mmc pbias support and ldo1 power on
> 
> Signed-off-by: Balaji T K 
> Signed-off-by: Lokesh Vutla 
[snip]
> + udelay(150); /* wait 10 us */
> + value |= SDCARD_PWRDNZ;
> + writel(value, (*ctrl)->control_pbias);
> + udelay(150); /* wait 10 us */

That's not 10us.

> + val = 0x2b; /* (3 -.9)*20 +1 */

Consistent spacing in the math please (and leading 0).

> + if (palmas_i2c_write_u8(0x58, LDO1_CTRL, val)) {

No magic values please.

Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address

[Tom Rini]

On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote:

> From: Sricharan R 
> 
> NON SECURE SRAM is 512KB in DRA7xx devices.
> So fixing it here.
> 
> Signed-off-by: Sricharan R 
> ---
>  arch/arm/include/asm/arch-omap5/omap.h |7 ---
>  include/configs/dra7xx_evm.h   |3 +++
>  include/configs/omap5_uevm.h   |3 +++

No, we need to handle this in the include files, not the config files.

-- 
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 07/12] ARM: DRA7xx: Correct the SYS_CLK to 20MHZ

[Tom Rini]

On Wed, May 29, 2013 at 04:32:42PM +0530, Lokesh Vutla wrote:

> From: Sricharan R 
> 
> The sys_clk on the dra evm board is 20MHZ.
> Changing the configuration for the same.
> 
> Signed-off-by: Sricharan R 
> ---
>  include/configs/dra7xx_evm.h   |4 
>  include/configs/omap5_common.h |1 -
>  include/configs/omap5_uevm.h   |3 +++
>  3 files changed, 7 insertions(+), 1 deletion(-)

OK, lets start fixing some of this madness while we're in here.  V_OSCK
(setting aside am335x) is only used for V_SCLK.  V_SCLK is only used for
TIMER_CLOCK in arch/arm/cpu/armv7/omap-common/timer.c.  We need to move
this value (or value pair) into  and rename
omap*/clocks.h to clock.h (it's the outlier vs the rest of ARM).

-- 
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 v4 0/4] Factorize ARM relocate_code instances

[Fabio Estevam]

Hi Albert,

On Tue, May 28, 2013 at 10:28 AM, Albert ARIBAUD
 wrote:

> Did you manage this test? If you did and it succeeded, then I'll merge
> the series into u-boot-arm.

Unfortunately I did not manage to find some spare time to test this, sorry.

Please go ahead and apply them.

Hopefully I will be able to test next week and then I will report in
case of any issue.

Thanks,

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

Re: [U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks

[Tom Rini]

On Wed, May 29, 2013 at 03:39:54PM +0530, Lokesh Vutla wrote:

> From: Sricharan R 
> 
> SGX clocks should be enabled only for OMAP5 ES1.0.
> So this can be removed.
> 
> Signed-off-by: Sricharan R 
> ---
>  arch/arm/cpu/armv7/omap5/hw_data.c |6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index 604fa42..842cf27 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -383,12 +383,6 @@ void enable_basic_clocks(void)
>clk_modules_explicit_en_essential,
>1);
>  
> - /* Select 384Mhz for GPU as its the POR for ES1.0 */
> - setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
> - CLKSEL_GPU_HYD_GCLK_MASK);
> - setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
> - CLKSEL_GPU_CORE_GCLK_MASK);
> -
>   /* Enable SCRM OPT clocks for PER and CORE dpll */
>   setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
>   OPTFCLKEN_SCRM_PER_MASK);

Wait, will everyone with ES1.0 be updating to ES2.0 and be OK with this?
Lubomir's board is ES1.0, currently.  Thanks!

-- 
Tom


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

Re: [U-Boot] [RFC PATCH 3/7] Tidy up Makefiles to use COBJS consistently

[Tom Rini]

On Sun, May 12, 2013 at 07:25:36PM -0700, Simon Glass wrote:
> Some Makefiles doen't define COBJS, but just use COBJS-y directly. This
> messes with our Kconfig script which uses COBJS to decide which objects
> are needed.
> 
> Also, for directories where COBJS produces an empty list, COBJS- must be
> defined and non-empty, otherwise Kconfig will not create the empty
> built-in.o file and the link will fail. So adjust things such that
> COBJS- is defined when needed.
> 
> Finally, Kconfig needs to know about subdirectories with the obj-y
> variable, so add these as needed.
> 
> All of the above changes should have no effect on the existing U-Boot
> build system.

Except for the obj-y for directories stuff, the other bits are cleanups
for what we have today yes?  If so, lets get them separated out and
merged in soon rather than later.  One less patch to carry.

-- 
Tom


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

Re: [U-Boot] [RFC PATCH 5/7] Adjust Kconfig scripts for use by U-Boot

[Tom Rini]

On Wed, May 29, 2013 at 09:47:34AM +0900, Masahiro Yamada wrote:
> Hello, Simon.
> 
> Please let me ask some more questions.
> 
> By applying these series of commits,
> U-Boot's config file scheme and Kconfig coexist.
> 
> For example, scripts/Makefile.build includes
> both auto.conf generated by Kconfig
> and autoconf.mk derived from U-boot's config.
> 
> -include include/config/auto.conf
> -include $(objtree)/include/config/autoconf.mk
> 
> I think the redundancy and dirtiness do not matter 
> if they are temporary.
> 
> What I'd like to make clear is our goal.
> It is intended to move all U-Boot's config files
> to Kconfig over long time and
> after that, delete U-Boot's config system.
> Is this right?

Yes, long term.

> 
> If the answer is yes, there are some macros
> I don't know how to port to Kconfig.
> 
> For example,
> CONFIG_SYS_BAUDRATE_TABLE is defined like follows.
> 
> #define CONFIG_SYS_BAUDRATE_TABLE {9600, 19200, 38400, 57600, 115200}
> 
> To my knowledge this macro can not be described by Kconfig.

We would probably want to change it to something like:
- Do you want the standard baud rate table?
  Yes: 9600/19200/38400/57600/115200
  No: Prompt for string value of comma sep list of rates

And in the right header:
#ifdef CONFIG_SYS_STD_BAUD_RATE
#define BAUDRATTE_TABLE { 9600,  }
#else
#define BAUDRATE_TABLE { CONFIG_SYS_PROMPTED_VALUE }
#endif

> And also, some config files still include macros without CONFIG_ prefix.
> For example, LINUX_BOOT_PARAM_ADDR, PHYS_SDRAM_1, PHYS_SDRAM_2, etc.

These don't belong in the config file, and need to be either in the
board or  or similar construct instead.

-- 
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] dfu: dfu and UBI Volumes

[Tom Rini]

On Wed, May 29, 2013 at 06:35:27AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> Am 28.05.2013 23:16, schrieb Tom Rini:
> > On Tue, May 28, 2013 at 11:01:09PM +0200, Wolfgang Denk wrote:
> >> Dear Tom,
> >>
> >> In message <20130528172309.GF5829@bill-the-cat> you wrote:
> >>>
>  Of course this can't yet apply to writing files on file systems since the
>  current API in U-Boot misses the append feature, but this could be 
>  applied to
>  program raw memory partitions, including UBI images.
> >>>
> >>> Correct.  We can write a whole UBI image, today, of NAND size,
> >>> regardless of DDR size.  But modifying UBI volumes (so UBIFS or your
> >>
> >> I don't think so.  To write a UBI volume on an existing UBI device,
> >> you would use the "ubi write" command.  This translates into a call of
> >> ubi_volume_write(char *volume, void *buf, size_t size)  which means
> >> the size must be known before you start writing; as far as I can tell
> >> ubi_volume_write() does not support incremental write operations of
> >> individual "parts" of a volume.
> > 
> > OK.  A very quick read of ubi_volume_write leads into the guts of the
> > write being in drivers/mtd/ubi/upd.c and it feels like you could
> > actually do the volume write in chunks with ubi_start_update() and
> > ubi_more_update_data() (and maybe some other housekeeping bits).  It
> > might take a bit more work since it looks like looks like both functions
> > rely on knowing the size at the start, but that's just to make sure the
> > size will fit in the volume.
> 
> Yes, I think so too ... seems some work, but not unsolveable ...
> 
> Hmm.. is it possible to get the filesize over dfu on startup? (I hope
> so, as it makes no sense to transfer a file, if it does not fit in the
> partition ... )

There is not, but that's OK.  Even if you think you had the room for the
whole image you could find a new bad block and not fit, so it's just
behaving like when we do a raw NAND write, get the data chunk, make sure
we think we still have room, write if we do, error if we don't.

-- 
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] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec onwards

[Jagan Teki]

Any help on this, was this a useful fix.

Thanks,
Jagan.

On Mon, May 27, 2013 at 10:49 AM, Jagannadha Sutradharudu Teki
 wrote:
> Request for an update on this.
>
> Thanks,
> Jagan.
>
>> -Original Message-
>> From: Jagannadha Sutradharudu Teki [mailto:jagannadha.sutradharudu-
>> t...@xilinx.com]
>> Sent: 21 May 2013 15:02
>> To: u-boot@lists.denx.de
>> Cc: mon...@monstr.eu; Andy Fleming; Jagannadha Sutradharudu Teki
>> Subject: [U-BOOT] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec 
>> onwards
>>
>> CAP register don't have any information for 8-bit buswidth support on 2.0 
>> sdhci
>> spec, only from 3.0 onwards bit[18] got this information.
>>
>> Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using
>> mmc_set_bus_width even if controller doesn't support.
>> Below change has code information.
>> "mmc: Properly determine maximum supported bus width"
>> (sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac)
>>
>> Bug log: > ---
>> zynq-uboot> mmcinfo
>> Error detected in status(0x208100)!
>> Device: zynq_sdhci
>> Manufacturer ID: fe
>> .
>>
>> So enable 8-bit support only for 3.0 spec using CAP and for below 3.0 assign
>> mmc->host_caps = MMC_MODE_8BIT on respective platform driver if host have
>> a support.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki 
>> ---
>>  drivers/mmc/sdhci.c |6 --
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 1eaea04..c5631bf
>> 100644
>> --- a/drivers/mmc/sdhci.c
>> +++ b/drivers/mmc/sdhci.c
>> @@ -486,8 +486,10 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk,
>> u32 min_clk)
>>   mmc->voltages |= host->voltages;
>>
>>   mmc->host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz |
>> MMC_MODE_4BIT;
>> - if (caps & SDHCI_CAN_DO_8BIT)
>> - mmc->host_caps |= MMC_MODE_8BIT;
>> + if ((host->version & SDHCI_SPEC_VER_MASK) >= SDHCI_SPEC_300) {
>> + if (caps & SDHCI_CAN_DO_8BIT)
>> + mmc->host_caps |= MMC_MODE_8BIT;
>> + }
>>   if (host->host_caps)
>>   mmc->host_caps |= host->host_caps;
>>
>> --
>> 1.7.4
>>
>
>
>
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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

[U-Boot] [PATCH 12/12] ARM: DRA7xx: EMIF: Change settings required for EVM board

[Lokesh Vutla]

From: Sricharan R 

DRA7 EVM board has the below configuration. Adding the
settings for the same here.

   2Gb_1_35V_DDR3L part * 2 on EMIF1
   2Gb_1_35V_DDR3L part * 4 on EMIF2

Signed-off-by: Sricharan R 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap-common/emif-common.c |   26 +++-
 arch/arm/cpu/armv7/omap5/hw_data.c   |   21 +++-
 arch/arm/cpu/armv7/omap5/hwinit.c|   19 +--
 arch/arm/cpu/armv7/omap5/prcm-regs.c |1 +
 arch/arm/cpu/armv7/omap5/sdram.c |  170 --
 arch/arm/include/asm/arch-omap5/omap.h   |1 +
 arch/arm/include/asm/emif.h  |   12 +-
 arch/arm/include/asm/omap_common.h   |1 +
 8 files changed, 220 insertions(+), 31 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c 
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 11e830a..f925e82 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -209,7 +209,8 @@ void emif_update_timings(u32 base, const struct emif_regs 
*regs)
writel(regs->temp_alert_config, &emif->emif_temp_alert_config);
writel(regs->emif_ddr_phy_ctlr_1, &emif->emif_ddr_phy_ctrl_1_shdw);
 
-   if (omap_revision() >= OMAP5430_ES1_0) {
+   if ((omap_revision() >= OMAP5430_ES1_0) ||
+   (omap_revision() == DRA752_ES1_0)) {
writel(EMIF_L3_CONFIG_VAL_SYS_10_MPU_5_LL_0,
&emif->emif_l3_config);
} else if (omap_revision() >= OMAP4460_ES1_0) {
@@ -263,6 +264,18 @@ static void ddr3_leveling(u32 base, const struct emif_regs 
*regs)
__udelay(130);
 }
 
+static void ddr3_sw_leveling(u32 base, const struct emif_regs *regs)
+{
+   struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
+
+   writel(regs->emif_ddr_phy_ctlr_1, &emif->emif_ddr_phy_ctrl_1);
+   writel(regs->emif_ddr_phy_ctlr_1, &emif->emif_ddr_phy_ctrl_1_shdw);
+   config_data_eye_leveling_samples(base);
+
+   writel(regs->emif_rd_wr_lvl_ctl, &emif->emif_rd_wr_lvl_ctl);
+   writel(regs->sdram_config, &emif->emif_sdram_config);
+}
+
 static void ddr3_init(u32 base, const struct emif_regs *regs)
 {
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
@@ -273,6 +286,7 @@ static void ddr3_init(u32 base, const struct emif_regs 
*regs)
 * defined, contents of mode Registers must be fully initialized.
 * H/W takes care of this initialization
 */
+   writel(regs->sdram_config2, &emif->emif_lpddr2_nvm_config);
writel(regs->sdram_config_init, &emif->emif_sdram_config);
 
writel(regs->emif_ddr_phy_ctlr_1_init, &emif->emif_ddr_phy_ctrl_1);
@@ -290,7 +304,10 @@ static void ddr3_init(u32 base, const struct emif_regs 
*regs)
/* enable leveling */
writel(regs->emif_rd_wr_lvl_rmp_ctl, &emif->emif_rd_wr_lvl_rmp_ctl);
 
-   ddr3_leveling(base, regs);
+   if (omap_revision() == DRA752_ES1_0)
+   ddr3_sw_leveling(base, regs);
+   else
+   ddr3_leveling(base, regs);
 }
 
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
@@ -1078,7 +1095,10 @@ static void do_sdram_init(u32 base)
if (warm_reset() && (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3)) {
set_lpmode_selfrefresh(base);
emif_reset_phy(base);
-   ddr3_leveling(base, regs);
+   if (omap_revision() == DRA752_ES1_0)
+   ddr3_sw_leveling(base, regs);
+   else
+   ddr3_leveling(base, regs);
}
 
/* Write to the shadow registers */
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 8303390..9374c6a 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -602,6 +602,17 @@ const struct ctrl_ioregs ioregs_omap5432_es2 = {
.ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
 };
 
+const struct ctrl_ioregs ioregs_dra7xx_es1 = {
+   .ctrl_ddrch = 0x40404040,
+   .ctrl_lpddr2ch = 0x40404040,
+   .ctrl_ddr3ch = 0x80808080,
+   .ctrl_ddrio_0 = 0xbae8c631,
+   .ctrl_ddrio_1 = 0xb46318d8,
+   .ctrl_ddrio_2 = 0x8421,
+   .ctrl_emif_sdram_config_ext = 0xb2c0,
+   .ctrl_ddr_ctrl_ext_0 = 0xA200,
+};
+
 void hw_data_init(void)
 {
u32 omap_rev = omap_revision();
@@ -644,14 +655,16 @@ void get_ioregs(const struct ctrl_ioregs **regs)
case OMAP5430_ES1_0:
case OMAP5430_ES2_0:
*regs = &ioregs_omap5430;
-   break;
+   break;
case OMAP5432_ES1_0:
*regs = &ioregs_omap5432_es1;
-   break;
+   break;
case OMAP5432_ES2_0:
-   case DRA752_ES1_0:
*regs = &ioregs_omap5432_es2;
-   break;
+   break;
+   case DRA752_ES1_0:
+   *regs = &ioregs_dra7xx_es1;
+   break;

[U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address

[Lokesh Vutla]

From: Sricharan R 

NON SECURE SRAM is 512KB in DRA7xx devices.
So fixing it here.

Signed-off-by: Sricharan R 
---
 arch/arm/include/asm/arch-omap5/omap.h |7 ---
 include/configs/dra7xx_evm.h   |3 +++
 include/configs/omap5_uevm.h   |3 +++
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index df8222a..15d429f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -159,13 +159,6 @@ struct s32ktimer {
 #define EFUSE_4 0x45145100
 #endif /* __ASSEMBLY__ */
 
-/*
- * Non-secure SRAM Addresses
- * Non-secure RAM starts at 0x4030 for GP devices. But we keep SRAM_BASE
- * at 0x40304000(EMU base) so that our code works for both EMU and GP
- */
-#define NON_SECURE_SRAM_START  0x4030
-#define NON_SECURE_SRAM_END0x4032  /* Not inclusive */
 /* base address for indirect vectors (internal boot mode) */
 #define SRAM_ROM_VECT_BASE 0x4031F000
 
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index b0b0bda..fc35f2f 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -42,4 +42,7 @@
 /* Clock Defines */
 #define V_OSCK 2000/* Clock output from T2 */
 
+#define NON_SECURE_SRAM_START  0x4030
+#define NON_SECURE_SRAM_END0x4038  /* Not inclusive */
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 4f2d425..96c5955 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -61,5 +61,8 @@
 /* Clock Defines */
 #define V_OSCK 1920/* Clock output from T2 */
 
+#define NON_SECURE_SRAM_START  0x4030
+#define NON_SECURE_SRAM_END0x4032  /* Not inclusive */
+
 #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC   16296
 #endif /* __CONFIG_OMAP5_EVM_H */
-- 
1.7.9.5

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

[U-Boot] [PATCH 11/12] ARM: DRA7xx: clocks: Update PLL values

[Lokesh Vutla]

Update PLL values.
SYS_CLKSEL value for 20MHz is changed to 2. In other platforms
SYS_CLKSEL value 2 represents reserved. But in sys_clk array
ind 1 is used for 13Mhz. Since other platforms are not using
13Mhz, reusing index 1 for 20MHz.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Sricharan R 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   16 ++---
 arch/arm/cpu/armv7/omap5/hw_data.c |   87 +++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/arch-omap4/clocks.h   |2 +-
 arch/arm/include/asm/arch-omap5/clocks.h   |8 ++-
 arch/arm/include/asm/omap_common.h |3 +-
 include/configs/dra7xx_evm.h   |1 +
 7 files changed, 72 insertions(+), 46 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 928327a..88d9392 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -50,13 +50,12 @@
 
 const u32 sys_clk_array[8] = {
1200,  /* 12 MHz */
-   1300,  /* 13 MHz */
+   2000,   /* 20 MHz */
1680,  /* 16.8 MHz */
1920,  /* 19.2 MHz */
2600,  /* 26 MHz */
2700,  /* 27 MHz */
3840,  /* 38.4 MHz */
-   2000,   /* 20 MHz */
 };
 
 static inline u32 __get_sys_clk_index(void)
@@ -75,13 +74,6 @@ static inline u32 __get_sys_clk_index(void)
/* SYS_CLKSEL - 1 to match the dpll param array indices */
ind = (readl((*prcm)->cm_sys_clksel) &
CM_SYS_CLKSEL_SYS_CLKSEL_MASK) - 1;
-   /*
-* SYS_CLKSEL value for 20MHz is 0. This is introduced newly
-* in DRA7XX socs. SYS_CLKSEL -1 will be greater than
-* NUM_SYS_CLK. So considering the last 3 bits as the index
-* for the dpll param array.
-*/
-   ind &= CM_SYS_CLKSEL_SYS_CLKSEL_MASK;
}
return ind;
 }
@@ -441,6 +433,12 @@ static void setup_non_essential_dplls(void)
params = get_abe_dpll_params(*dplls_data);
 #ifdef CONFIG_SYS_OMAP_ABE_SYSCK
abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_SYSCLK;
+
+   if (omap_revision() == DRA752_ES1_0)
+   /* Select the sys clk for dpll_abe */
+   clrsetbits_le32((*prcm)->cm_abe_pll_sys_clksel,
+   CM_CLKSEL_ABE_PLL_SYS_CLKSEL_MASK,
+   CM_ABE_PLL_SYS_CLKSEL_SYSCLK2);
 #else
abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_32KCLK;
/*
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 53aea93..8303390 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -100,14 +100,13 @@ static const struct dpll_params 
mpu_dpll_params_499mhz[NUM_SYS_CLKS] = {
 };
 
 static const struct dpll_params mpu_dpll_params_1ghz[NUM_SYS_CLKS] = {
-   {250, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {119, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {625, 11, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
-   {500, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
+   {250, 2, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz   */
+   {500, 9, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 20 MHz   */
+   {119, 1, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
+   {625, 11, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
+   {500, 12, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 26 MHz   */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {625, 23, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 38.4 MHz */
-   {50, 0, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}  /* 20 MHz   */
+   {625, 23, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 38.4 MHz */
 };
 
 static const struct dpll_params
@@ -133,15 +132,14 @@ static const struct dpll_params
 };
 
 static const struct dpll_params
-   core_dpll_params_2128mhz_ddr532_dra7xx[NUM_SYS_CLKS] = {
-   {266, 2, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {443, 6, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 16.8 MHz */
-   {277, 4, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 19.2 MHz */
-   {368, 8, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 26 MHz   */
+   core_dpll_params_2128mhz_dra7xx[NUM_SYS_CLKS] = {
+   {266, 2, 2, 1, -1, 4, 62, 5, -1, 5, 4, 6},  /* 12 MHz   */
+   {

[U-Boot] [PATCH 07/12] ARM: DRA7xx: Correct the SYS_CLK to 20MHZ

[Lokesh Vutla]

From: Sricharan R 

The sys_clk on the dra evm board is 20MHZ.
Changing the configuration for the same.

Signed-off-by: Sricharan R 
---
 include/configs/dra7xx_evm.h   |4 
 include/configs/omap5_common.h |1 -
 include/configs/omap5_uevm.h   |3 +++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index b142049..b0b0bda 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -38,4 +38,8 @@
 #define CONFIG_CONS_INDEX  1
 #define CONFIG_SYS_NS16550_COM1UART1_BASE
 #define CONFIG_BAUDRATE115200
+
+/* Clock Defines */
+#define V_OSCK 2000/* Clock output from T2 */
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index d57c0da..9fef21c 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -46,7 +46,6 @@
 #define CONFIG_DISPLAY_BOARDINFO
 
 /* Clock Defines */
-#define V_OSCK 1920/* Clock output from T2 */
 #define V_SCLK V_OSCK
 
 #define CONFIG_MISC_INIT_R
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index ba81e30..4f2d425 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -58,5 +58,8 @@
 
 #define CONFIG_SYS_PROMPT  "OMAP5430 EVM # "
 
+/* Clock Defines */
+#define V_OSCK 1920/* Clock output from T2 */
+
 #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC   16296
 #endif /* __CONFIG_OMAP5_EVM_H */
-- 
1.7.9.5

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

[U-Boot] [PATCH 04/12] ARM: OMAP5: DRA7xx: support class 0 optimized voltages

[Lokesh Vutla]

From: Nishanth Menon 

DRA752 now uses AVS Class 0 voltages which are voltages in efuse.

This means that we can now use the optimized voltages which are
stored as mV values in efuse and program PMIC accordingly.

This allows us to go with higher OPP as needed in the system without
the need for implementing complex AVS logic.

Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   58 +++-
 arch/arm/cpu/armv7/omap5/hw_data.c |   10 
 arch/arm/include/asm/arch-omap5/clocks.h   |   30 
 arch/arm/include/asm/omap_common.h |   11 +
 4 files changed, 97 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 1861df4..928327a 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -521,6 +521,38 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
gpio_direction_output(pmic->gpio, 1);
 }
 
+static u32 optimize_vcore_voltage(struct volts const *v)
+{
+   u32 val;
+   if (!v->value)
+   return 0;
+   if (!v->efuse.reg)
+   return v->value;
+
+   switch (v->efuse.reg_bits) {
+   case 16:
+   val = readw(v->efuse.reg);
+   break;
+   case 32:
+   val = readl(v->efuse.reg);
+   break;
+   default:
+   printf("Error: efuse 0x%08x bits=%d unknown\n",
+  v->efuse.reg, v->efuse.reg_bits);
+   return v->value;
+   }
+
+   if (!val) {
+   printf("Error: efuse 0x%08x bits=%d val=0, using %d\n",
+  v->efuse.reg, v->efuse.reg_bits, v->value);
+   return v->value;
+   }
+
+   debug("%s:efuse 0x%08x bits=%d Vnom=%d, using efuse value %d\n",
+ __func__, v->efuse.reg, v->efuse.reg_bits, v->value, val);
+   return val;
+}
+
 /*
  * Setup the voltages for vdd_mpu, vdd_core, and vdd_iva
  * We set the maximum voltages allowed here because Smart-Reflex is not
@@ -529,23 +561,25 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
  */
 void scale_vcores(struct vcores_data const *vcores)
 {
-   do_scale_vcore(vcores->core.addr, vcores->core.value,
- vcores->core.pmic);
+   u32 val;
+
+   val = optimize_vcore_voltage(&vcores->core);
+   do_scale_vcore(vcores->core.addr, val, vcores->core.pmic);
 
-   do_scale_vcore(vcores->mpu.addr, vcores->mpu.value,
- vcores->mpu.pmic);
+   val = optimize_vcore_voltage(&vcores->mpu);
+   do_scale_vcore(vcores->mpu.addr, val, vcores->mpu.pmic);
 
-   do_scale_vcore(vcores->mm.addr, vcores->mm.value,
- vcores->mm.pmic);
+   val = optimize_vcore_voltage(&vcores->mm);
+   do_scale_vcore(vcores->mm.addr, val, vcores->mm.pmic);
 
-   do_scale_vcore(vcores->gpu.addr, vcores->gpu.value,
-  vcores->gpu.pmic);
+   val = optimize_vcore_voltage(&vcores->gpu);
+   do_scale_vcore(vcores->gpu.addr, val, vcores->gpu.pmic);
 
-   do_scale_vcore(vcores->eve.addr, vcores->eve.value,
-  vcores->eve.pmic);
+   val = optimize_vcore_voltage(&vcores->eve);
+   do_scale_vcore(vcores->eve.addr, val, vcores->eve.pmic);
 
-   do_scale_vcore(vcores->iva.addr, vcores->iva.value,
-  vcores->iva.pmic);
+   val = optimize_vcore_voltage(&vcores->iva);
+   do_scale_vcore(vcores->iva.addr, val, vcores->iva.pmic);
 
 if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
/* Configure LDO SRAM "magic" bits */
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index e9d34c1..53aea93 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -338,22 +338,32 @@ struct vcores_data omap5430_volts_es2 = {
 
 struct vcores_data dra752_volts = {
.mpu.value  = VDD_MPU_DRA752,
+   .mpu.efuse.reg  = STD_FUSE_OPP_VMIN_MPU_NOM,
+   .mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr   = TPS659038_REG_ADDR_SMPS12_MPU,
.mpu.pmic   = &tps659038,
 
.eve.value  = VDD_EVE_DRA752,
+   .eve.efuse.reg  = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
+   .eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr   = TPS659038_REG_ADDR_SMPS45_EVE,
.eve.pmic   = &tps659038,
 
.gpu.value  = VDD_GPU_DRA752,
+   .gpu.efuse.reg  = STD_FUSE_OPP_VMIN_GPU_NOM,
+   .gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr   = TPS659038_REG_ADDR_SMPS6_GPU,
.gpu.pmic   = &tps659038,
 
.core.value = VDD_CORE_DRA752,
+   .core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
+   .core.e

[U-Boot] [PATCH 10/12] ARM: DRA7xx: Update pinmux data

[Lokesh Vutla]

Updating pinmux data as specified in the latest DM

Signed-off-by: Lokesh Vutla 
Signed-off-by: Balaji T K 
---
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h |7 +++--
 board/ti/dra7xx/mux_data.h   |   38 --
 2 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h 
b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
index 55e9de6..5f2b0f9 100644
--- a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
+++ b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
@@ -28,11 +28,14 @@
 
 #include 
 
+#define FSC(1 << 19)
+#define SSC(0 << 19)
+
 #define IEN(1 << 18)
 #define IDIS   (0 << 18)
 
-#define PTU(3 << 16)
-#define PTD(1 << 16)
+#define PTU(1 << 17)
+#define PTD(0 << 17)
 #define PEN(1 << 16)
 #define PDIS   (0 << 16)
 
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 04c95fd..338a241 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -29,19 +29,29 @@
 #include 
 
 const struct pad_conf_entry core_padconf_array_essential[] = {
-   {MMC1_CLK, (PTU | IEN | M0)},   /* MMC1_CLK */
-   {MMC1_CMD, (PTU | IEN | M0)},   /* MMC1_CMD */
-   {MMC1_DAT0, (PTU | IEN | M0)},  /* MMC1_DAT0 */
-   {MMC1_DAT1, (PTU | IEN | M0)},  /* MMC1_DAT1 */
-   {MMC1_DAT2, (PTU | IEN | M0)},  /* MMC1_DAT2 */
-   {MMC1_DAT3, (PTU | IEN | M0)},  /* MMC1_DAT3 */
-   {MMC1_SDCD, (PTU | IEN | M0)},  /* MMC1_SDCD */
-   {MMC1_SDWP, (PTU | IEN | M0)},  /* MMC1_SDWP */
-   {UART1_RXD, (PTU | IEN | M0)},  /* UART1_RXD */
-   {UART1_TXD, (M0)},  /* UART1_TXD */
-   {UART1_CTSN, (PTU | IEN | M0)}, /* UART1_CTSN */
-   {UART1_RTSN, (M0)}, /* UART1_RTSN */
-   {I2C1_SDA, (PTU | IEN | M0)},   /* I2C1_SDA */
-   {I2C1_SCL, (PTU | IEN | M0)},   /* I2C1_SCL */
+   {MMC1_CLK, (IEN | PTU | PDIS | M0)},/* MMC1_CLK */
+   {MMC1_CMD, (IEN | PTU | PDIS | M0)},/* MMC1_CMD */
+   {MMC1_DAT0, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT0 */
+   {MMC1_DAT1, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT1 */
+   {MMC1_DAT2, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT2 */
+   {MMC1_DAT3, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT3 */
+   {MMC1_SDCD, (FSC | IEN | PTU | PDIS | M0)}, /* MMC1_SDCD */
+   {MMC1_SDWP, (FSC | IEN | PTD | PEN | M14)}, /* MMC1_SDWP */
+   {GPMC_A19, (IEN | PTU | PDIS | M1)},/* mmc2_dat4 */
+   {GPMC_A20, (IEN | PTU | PDIS | M1)},/* mmc2_dat5 */
+   {GPMC_A21, (IEN | PTU | PDIS | M1)},/* mmc2_dat6 */
+   {GPMC_A22, (IEN | PTU | PDIS | M1)},/* mmc2_dat7 */
+   {GPMC_A23, (IEN | PTU | PDIS | M1)},/* mmc2_clk */
+   {GPMC_A24, (IEN | PTU | PDIS | M1)},/* mmc2_dat0 */
+   {GPMC_A25, (IEN | PTU | PDIS | M1)},/* mmc2_dat1 */
+   {GPMC_A26, (IEN | PTU | PDIS | M1)},/* mmc2_dat2 */
+   {GPMC_A27, (IEN | PTU | PDIS | M1)},/* mmc2_dat3 */
+   {GPMC_CS1, (IEN | PTU | PDIS | M1)},/* mmm2_cmd */
+   {UART1_RXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_RXD */
+   {UART1_TXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_TXD */
+   {UART1_CTSN, (IEN | PTU | PDIS | M3)},  /* UART1_CTSN */
+   {UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
+   {I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
+   {I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
 };
 #endif /* _MUX_DATA_DRA7XX_H_ */
-- 
1.7.9.5

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

[U-Boot] [PATCH 01/12] ARM: DRA7xx: Add control id code for DRA7xx

[Lokesh Vutla]

The registers that are used for device identification
are changed from OMAP5 to DRA7xx.
Using the correct registers for DRA7xx.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/clocks.h |   11 +++
 arch/arm/include/asm/arch-omap5/omap.h   |3 ---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/clocks.h 
b/arch/arm/include/asm/arch-omap5/clocks.h
index 6673a02..ca75f63 100644
--- a/arch/arm/include/asm/arch-omap5/clocks.h
+++ b/arch/arm/include/asm/arch-omap5/clocks.h
@@ -239,4 +239,15 @@
  * into microsec and passing the value.
  */
 #define CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC31219
+
+/* CONTROL ID CODE */
+#define CONTROL_CORE_ID_CODE   0x4A002204
+#define CONTROL_WKUP_ID_CODE   0x4AE0C204
+
+#ifdef CONFIG_DRA7XX
+#define CONTROL_ID_CODECONTROL_WKUP_ID_CODE
+#else
+#define CONTROL_ID_CODECONTROL_CORE_ID_CODE
+#endif
+
 #endif /* _CLOCKS_OMAP5_H_ */
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 6dfedf4..df8222a 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -44,9 +44,6 @@
 #define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 #define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 
-/* CONTROL_ID_CODE */
-#define CONTROL_ID_CODE0x4A002204
-
 /* To be verified */
 #define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F
 #define OMAP5430_CONTROL_ID_CODE_ES2_0  0x1B94202F
-- 
1.7.9.5

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

[U-Boot] [PATCH 02/12] ARM: DRA7xx: power Add support for tps659038 PMIC

[Lokesh Vutla]

TPS659038 is the power IC used in DRA7XX boards.
Adding support for this and also adding pmic data
for DRA7XX boards.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   23 ++
 arch/arm/cpu/armv7/omap5/hw_data.c |   38 +++-
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/clocks.h   |   15 ++
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/omap_common.h |3 ++
 6 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 0daf98c..c51c359 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -30,6 +30,7 @@
  * MA 02111-1307 USA
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -487,6 +488,9 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
u32 offset = volt_mv;
int ret = 0;
 
+   if (!volt_mv)
+   return;
+
pmic->pmic_bus_init();
/* See if we can first get the GPIO if needed */
if (pmic->gpio_en)
@@ -534,6 +538,15 @@ void scale_vcores(struct vcores_data const *vcores)
do_scale_vcore(vcores->mm.addr, vcores->mm.value,
  vcores->mm.pmic);
 
+   do_scale_vcore(vcores->gpu.addr, vcores->gpu.value,
+  vcores->gpu.pmic);
+
+   do_scale_vcore(vcores->eve.addr, vcores->eve.value,
+  vcores->eve.pmic);
+
+   do_scale_vcore(vcores->iva.addr, vcores->iva.value,
+  vcores->iva.pmic);
+
 if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
/* Configure LDO SRAM "magic" bits */
writel(2, (*prcm)->prm_sldo_core_setup);
@@ -723,3 +736,13 @@ void prcm_init(void)
if (OMAP_INIT_CONTEXT_SPL != omap_hw_init_context())
enable_basic_uboot_clocks();
 }
+
+void gpi2c_init(void)
+{
+   static int gpi2c = 1;
+
+   if (gpi2c) {
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+   gpi2c = 0;
+   }
+}
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 74e473d..e9d34c1 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -26,6 +26,7 @@
  * MA 02111-1307 USA
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -294,6 +295,19 @@ struct pmic_data palmas = {
.pmic_write = omap_vc_bypass_send_value,
 };
 
+struct pmic_data tps659038 = {
+   .base_offset = PALMAS_SMPS_BASE_VOLT_UV,
+   .step = 1, /* 10 mV represented in uV */
+   /*
+* Offset codes 1-6 all give the base voltage in Palmas
+* Offset code 0 switches OFF the SMPS
+*/
+   .start_code = 6,
+   .i2c_slave_addr = TPS659038_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = gpi2c_init,
+   .pmic_write = palmas_i2c_write_u8,
+};
+
 struct vcores_data omap5430_volts = {
.mpu.value = VDD_MPU,
.mpu.addr = SMPS_REG_ADDR_12_MPU,
@@ -322,6 +336,28 @@ struct vcores_data omap5430_volts_es2 = {
.mm.pmic = &palmas,
 };
 
+struct vcores_data dra752_volts = {
+   .mpu.value  = VDD_MPU_DRA752,
+   .mpu.addr   = TPS659038_REG_ADDR_SMPS12_MPU,
+   .mpu.pmic   = &tps659038,
+
+   .eve.value  = VDD_EVE_DRA752,
+   .eve.addr   = TPS659038_REG_ADDR_SMPS45_EVE,
+   .eve.pmic   = &tps659038,
+
+   .gpu.value  = VDD_GPU_DRA752,
+   .gpu.addr   = TPS659038_REG_ADDR_SMPS6_GPU,
+   .gpu.pmic   = &tps659038,
+
+   .core.value = VDD_CORE_DRA752,
+   .core.addr  = TPS659038_REG_ADDR_SMPS7_CORE,
+   .core.pmic  = &tps659038,
+
+   .iva.value  = VDD_IVA_DRA752,
+   .iva.addr   = TPS659038_REG_ADDR_SMPS8_IVA,
+   .iva.pmic   = &tps659038,
+};
+
 /*
  * Enable essential clock domains, modules and
  * do some additional special settings needed
@@ -562,7 +598,7 @@ void hw_data_init(void)
case DRA752_ES1_0:
*prcm = &dra7xx_prcm;
*dplls_data = &dra7xx_dplls;
-   *omap_vcores = &omap5430_volts_es2;
+   *omap_vcores = &dra752_volts;
*ctrl = &dra7xx_ctrl;
break;
 
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 37d6c69..438cb96 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -57,6 +57,7 @@ u32 cortex_rev(void);
 void init_omap_revision(void);
 void do_io_settings(void);
 void sri2c_init(void);
+void gpi2c_init(void);
 int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 reg_data);
 u32 warm_reset(void);
 void force_emif_self_refresh(void);
diff --git a/arch/arm/include/asm/arch-omap5/clocks.h 
b/arch/arm/include/asm/a

[U-Boot] [PATCH 05/12] ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's

[Lokesh Vutla]

Slew rate compensation cells are not present for DRA7xx
Soc's. So return from function srcomp_enable() if soc is not
OMAP54xx.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap5/hwinit.c  |3 +++
 arch/arm/include/asm/omap_common.h |8 
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index e192fea..784aa11 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -201,6 +201,9 @@ void srcomp_enable(void)
u32 sysclk_ind  = get_sys_clk_index();
u32 omap_rev= omap_revision();
 
+   if (!is_omap54xx())
+   return;
+
mul_factor = srcomp_parameters[sysclk_ind].multiply_factor;
div_factor = srcomp_parameters[sysclk_ind].divide_factor;
 
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 1435674..7007177 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -575,6 +575,14 @@ static inline u32 omap_revision(void)
extern u32 *const omap_si_rev;
return *omap_si_rev;
 }
+
+#define OMAP54xx   0x5400
+
+static inline u8 is_omap54xx(void)
+{
+   extern u32 *const omap_si_rev;
+   return ((*omap_si_rev & 0xFF00) == OMAP54xx);
+}
 #endif
 
 /*
-- 
1.7.9.5

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

[U-Boot] [PATCH 06/12] ARM: DRA7xx: Change the Debug UART to UART1

[Lokesh Vutla]

From: Sricharan R 

Serial UART is connected to UART1. So add the change
for the same.

Signed-off-by: Sricharan R 
---
 include/configs/dra7xx_evm.h   |3 +++
 include/configs/omap5_common.h |4 
 include/configs/omap5_uevm.h   |4 
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 28a306b..b142049 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -35,4 +35,7 @@
 #define CONFIG_DRA7XX  /* in a TI DRA7XX core */
 #define CONFIG_SYS_PROMPT  "DRA752 EVM # "
 
+#define CONFIG_CONS_INDEX  1
+#define CONFIG_SYS_NS16550_COM1UART1_BASE
+#define CONFIG_BAUDRATE115200
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index deb5e9f..d57c0da 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -81,10 +81,6 @@
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
-#define CONFIG_CONS_INDEX  3
-#define CONFIG_SYS_NS16550_COM3UART3_BASE
-
-#define CONFIG_BAUDRATE115200
 
 /* CPU */
 #define CONFIG_ARCH_CPU_INIT
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index c791789..ba81e30 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -35,6 +35,10 @@
 
 #include 
 
+#define CONFIG_CONS_INDEX  3
+#define CONFIG_SYS_NS16550_COM3UART3_BASE
+#define CONFIG_BAUDRATE115200
+
 /* TWL6035 */
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_PALMAS_POWER
-- 
1.7.9.5

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

[U-Boot] [PATCH 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lokesh Vutla]

From: Balaji T K 

add dra mmc pbias support and ldo1 power on

Signed-off-by: Balaji T K 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/omap.h |3 ++-
 drivers/mmc/omap_hsmmc.c   |   26 ++
 drivers/power/palmas.c |   25 -
 include/configs/omap5_common.h |4 
 include/configs/omap5_uevm.h   |5 -
 include/palmas.h   |5 -
 6 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 15d429f..63378fb 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -96,9 +96,10 @@
 /* CONTROL_EFUSE_2 */
 #define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1   0x00ffc000
 
+#define SDCARD_BIAS_PWRDNZ (1 << 27)
 #define SDCARD_PWRDNZ  (1 << 26)
 #define SDCARD_BIAS_HIZ_MODE   (1 << 25)
-#define SDCARD_BIAS_PWRDNZ (1 << 22)
+#define SDCARD_BIAS_PWRDNZ2(1 << 22)
 #define SDCARD_PBIASLITE_VMODE (1 << 21)
 
 #ifndef __ASSEMBLY__
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index afdfa88..60807df 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -113,23 +113,25 @@ static void omap5_pbias_config(struct mmc *mmc)
u32 value = 0;
 
value = readl((*ctrl)->control_pbias);
-   value &= ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
-   value |= SDCARD_BIAS_HIZ_MODE;
+   value &= ~SDCARD_PWRDNZ;
+   writel(value, (*ctrl)->control_pbias);
+   udelay(10); /* wait 10 us */
+   value &= ~SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)->control_pbias);
 
-   palmas_mmc1_poweron_ldo();
+#if defined(CONFIG_DRA7XX)
+   palmas_mmc1_poweron_ldo1();
+#else
+   palmas_mmc1_poweron_ldo9();
+#endif
 
value = readl((*ctrl)->control_pbias);
-   value &= ~SDCARD_BIAS_HIZ_MODE;
-   value |= SDCARD_PBIASLITE_VMODE | SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ;
+   value |= SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)->control_pbias);
-
-   value = readl((*ctrl)->control_pbias);
-   if (value & (1 << 23)) {
-   value &= ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
-   value |= SDCARD_BIAS_HIZ_MODE;
-   writel(value, (*ctrl)->control_pbias);
-   }
+   udelay(150); /* wait 10 us */
+   value |= SDCARD_PWRDNZ;
+   writel(value, (*ctrl)->control_pbias);
+   udelay(150); /* wait 10 us */
 }
 #endif
 
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..84ec881 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
return;
 }
 
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
 {
u8 val = 0;
 
@@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
 
return 0;
 }
+
+int palmas_mmc1_poweron_ldo1(void)
+{
+   u8 val = 0;
+
+   /* set LDO9 TWL6035 to 3V */
+   val = 0x2b; /* (3 -.9)*20 +1 */
+
+   if (palmas_i2c_write_u8(0x58, LDO1_VOLTAGE, val)) {
+   printf("twl6035: could not set LDO1 voltage\n");
+   return 1;
+   }
+
+   /* TURN ON LDO9 */
+   val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+
+   if (palmas_i2c_write_u8(0x58, LDO1_CTRL, val)) {
+   printf("twl6035: could not turn on LDO1\n");
+   return 1;
+   }
+
+   return 0;
+}
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 9fef21c..f2c4c70 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -241,6 +241,10 @@
 #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
 #endif
 
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PALMAS_POWER
+#endif
+
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SPL_FRAMEWORK
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 96c5955..69754c6 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -39,11 +39,6 @@
 #define CONFIG_SYS_NS16550_COM3UART3_BASE
 #define CONFIG_BAUDRATE115200
 
-/* TWL6035 */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_PALMAS_POWER
-#endif
-
 /* MMC ENV related defines */
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 1   /* SLOT2: eMMC(1) */
diff --git a/include/palmas.h b/include/palmas.h
index 3b18589..18a25ff 100644
--- a/include/palmas.h
+++ b/include/palmas.h
@@ -30,6 +30,8 @@
 #define PALMAS_CHIP_ADDR   0x48
 
 /* 0x1XY translates to page 1, register address 0xXY */
+#define LDO1_CTRL  0x50
+#define LDO1_VOLTAGE   0x51
 #define LDO9_CTRL  0x60
 #define LDO9_VOLTAGE   0x61
 
@@ -53,6 +55,7 @@ static inline int 

[U-Boot] [PATCH 03/12] ARM: DRA7xx: clocks: Fixing i2c_init for PMIC

[Lokesh Vutla]

In DRA7xx Soc's voltage scaling is done using GPI2C.
So i2c_init should happen before scaling. I2C driver
uses __udelay which needs timer to be initialized.
So moving timer_init just before voltage scaling.
Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |1 +
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index c51c359..1861df4 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -721,6 +721,7 @@ void prcm_init(void)
case OMAP_INIT_CONTEXT_UBOOT_FROM_NOR:
case OMAP_INIT_CONTEXT_UBOOT_AFTER_CH:
enable_basic_clocks();
+   timer_init();
scale_vcores(*omap_vcores);
setup_dplls();
 #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 1645120..5602b0e 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -202,8 +202,6 @@ void s_init(void)
 #endif
prcm_init();
 #ifdef CONFIG_SPL_BUILD
-   timer_init();
-
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
 #endif
-- 
1.7.9.5

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

[U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's

[Lokesh Vutla]

This series update support for DRA7xx family Socs and the data for
DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-0-3-ARM-OMAP4-Misc-Cleanup-tt155877.html

Tested on DRA752 ES1.0, OMAP5432 ES2.0,
MAKEALL for all armv7 board has been verified.

Balaji T K (1):
  mmc: omap_hsmmc: add mmc1 pbias, ldo1

Lokesh Vutla (6):
  ARM: DRA7xx: Add control id code for DRA7xx
  ARM: DRA7xx: power Add support for tps659038 PMIC
  ARM: DRA7xx: clocks: Fixing i2c_init for PMIC
  ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's
  ARM: DRA7xx: Update pinmux data
  ARM: DRA7xx: clocks: Update PLL values

Nishanth Menon (1):
  ARM: OMAP5: DRA7xx: support class 0 optimized voltages

Sricharan R (4):
  ARM: DRA7xx: Change the Debug UART to UART1
  ARM: DRA7xx: Correct the SYS_CLK to 20MHZ
  ARM: DRA7xx: Correct SRAM END address
  ARM: DRA7xx: EMIF: Change settings required for EVM board

 arch/arm/cpu/armv7/omap-common/clocks-common.c |   86 +---
 arch/arm/cpu/armv7/omap-common/emif-common.c   |   26 +++-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 -
 arch/arm/cpu/armv7/omap5/hw_data.c |  156 --
 arch/arm/cpu/armv7/omap5/hwinit.c  |   22 ++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |2 +
 arch/arm/cpu/armv7/omap5/sdram.c   |  170 ++--
 arch/arm/include/asm/arch-omap4/clocks.h   |2 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/clocks.h   |   64 -
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h   |7 +-
 arch/arm/include/asm/arch-omap5/omap.h |   14 +-
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/emif.h|   12 +-
 arch/arm/include/asm/omap_common.h |   26 +++-
 board/ti/dra7xx/mux_data.h |   38 --
 drivers/mmc/omap_hsmmc.c   |   26 ++--
 drivers/power/palmas.c |   25 +++-
 include/configs/dra7xx_evm.h   |   11 ++
 include/configs/omap5_common.h |9 +-
 include/configs/omap5_uevm.h   |   13 +-
 include/palmas.h   |5 +-
 22 files changed, 582 insertions(+), 136 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [PATCH 3/3] ARM: OMAP4+: pmic: Make generic bus init and write functions

[Lokesh Vutla]

Voltage scaling can be done in two ways:
-> Using SR I2C
-> Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |6 ++
 arch/arm/cpu/armv7/omap-common/vc.c|   14 +-
 arch/arm/cpu/armv7/omap4/hw_data.c |   11 ++-
 arch/arm/cpu/armv7/omap5/hw_data.c |3 +++
 arch/arm/include/asm/arch-omap4/sys_proto.h|2 +-
 arch/arm/include/asm/arch-omap5/sys_proto.h|2 +-
 arch/arm/include/asm/omap_common.h |3 +++
 7 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 99910cd..0daf98c 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -487,6 +487,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
u32 offset = volt_mv;
int ret = 0;
 
+   pmic->pmic_bus_init();
/* See if we can first get the GPIO if needed */
if (pmic->gpio_en)
ret = gpio_request(pmic->gpio, "PMIC_GPIO");
@@ -509,8 +510,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
debug("do_scale_vcore: volt - %d offset_code - 0x%x\n", volt_mv,
offset_code);
 
-   if (omap_vc_bypass_send_value(SMPS_I2C_SLAVE_ADDR,
-   vcore_reg, offset_code))
+   if (pmic->pmic_write(pmic->i2c_slave_addr, vcore_reg, offset_code))
printf("Scaling voltage failed for 0x%x\n", vcore_reg);
 
if (pmic->gpio_en)
@@ -525,8 +525,6 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
  */
 void scale_vcores(struct vcores_data const *vcores)
 {
-   omap_vc_init(PRM_VC_I2C_CHANNEL_FREQ_KHZ);
-
do_scale_vcore(vcores->core.addr, vcores->core.value,
  vcores->core.pmic);
 
diff --git a/arch/arm/cpu/armv7/omap-common/vc.c 
b/arch/arm/cpu/armv7/omap-common/vc.c
index e6e5f78..911191d 100644
--- a/arch/arm/cpu/armv7/omap-common/vc.c
+++ b/arch/arm/cpu/armv7/omap-common/vc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Define Master code if there are multiple masters on the I2C_SR bus.
@@ -57,7 +58,7 @@
  * omap_vc_init() - Initialization for Voltage controller
  * @speed_khz: I2C buspeed in KHz
  */
-void omap_vc_init(u16 speed_khz)
+static void omap_vc_init(u16 speed_khz)
 {
u32 val;
u32 sys_clk_khz, cycles_hi, cycles_low;
@@ -137,3 +138,14 @@ int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 
reg_data)
/* All good.. */
return 0;
 }
+
+void sri2c_init(void)
+{
+   static int sri2c = 1;
+
+   if (sri2c) {
+   omap_vc_init(PRM_VC_I2C_CHANNEL_FREQ_KHZ);
+   sri2c = 0;
+   }
+   return;
+}
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c 
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 06a2fc8..02322cc 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -219,6 +219,9 @@ struct pmic_data twl6030_4430es1 = {
.step = 12660, /* 12.66 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct pmic_data twl6030 = {
@@ -226,6 +229,9 @@ struct pmic_data twl6030 = {
.step = 12660, /* 12.66 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct pmic_data tps62361 = {
@@ -233,7 +239,10 @@ struct pmic_data tps62361 = {
.step = 1, /* 10 mV represented in uV */
.start_code = 0,
.gpio = TPS62361_VSEL0_GPIO,
-   .gpio_en = 1
+   .gpio_en = 1,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct vcores_data omap4430_volts_es1 = {
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 842cf27..74e473d 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -289,6 +289,9 @@ struct pmic_data palmas = {
 * Offset code 0 switches OFF the SMPS
 */
.start_code = 6,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct vcores_data omap5430_volts = {
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 039a1f2..37d6c69 100644
--- a/arch/arm/include/asm/arch-omap4/s

[U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks

[Lokesh Vutla]

From: Sricharan R 

SGX clocks should be enabled only for OMAP5 ES1.0.
So this can be removed.

Signed-off-by: Sricharan R 
---
 arch/arm/cpu/armv7/omap5/hw_data.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 604fa42..842cf27 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -383,12 +383,6 @@ void enable_basic_clocks(void)
 clk_modules_explicit_en_essential,
 1);
 
-   /* Select 384Mhz for GPU as its the POR for ES1.0 */
-   setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
-   CLKSEL_GPU_HYD_GCLK_MASK);
-   setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
-   CLKSEL_GPU_CORE_GCLK_MASK);
-
/* Enable SCRM OPT clocks for PER and CORE dpll */
setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
OPTFCLKEN_SCRM_PER_MASK);
-- 
1.7.9.5

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

[U-Boot] [PATCH 0/3] ARM: OMAP4+: Misc Cleanup

[Lokesh Vutla]

Misc cleanup.
And also adding a Generic bus init and write functions
for PMIC.
This series is applied on top of u-boot-ti:
git://git.denx.de/u-boot-ti.git

Lokesh Vutla (2):
  ARM: OMAP4+: Cleanup header files
  ARM: OMAP4+: pmic: Make generic bus init and write functions

Sricharan R (1):
  ARM: OMAP5: clocks: Do not enable sgx clocks

 arch/arm/cpu/armv7/omap-common/clocks-common.c |6 ++---
 arch/arm/cpu/armv7/omap-common/vc.c|   14 ++-
 arch/arm/cpu/armv7/omap4/hw_data.c |   11 -
 arch/arm/cpu/armv7/omap4/prcm-regs.c   |3 +++
 arch/arm/cpu/armv7/omap5/hw_data.c |9 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |2 ++
 arch/arm/include/asm/arch-omap4/clocks.h   |   28 -
 arch/arm/include/asm/arch-omap4/cpu.h  |   12 -
 arch/arm/include/asm/arch-omap4/omap.h |   14 ---
 arch/arm/include/asm/arch-omap4/sys_proto.h|2 +-
 arch/arm/include/asm/arch-omap5/clocks.h   |   22 -
 arch/arm/include/asm/arch-omap5/cpu.h  |   12 -
 arch/arm/include/asm/arch-omap5/omap.h |   31 +---
 arch/arm/include/asm/arch-omap5/sys_proto.h|2 +-
 arch/arm/include/asm/omap_common.h |7 +++---
 board/ti/omap5_uevm/evm.c  |   12 ++---
 board/ti/panda/panda.c |   20 +--
 board/ti/sdp4430/sdp.c |   16 +++-
 drivers/usb/musb/omap3.c   |4 ++-
 19 files changed, 73 insertions(+), 154 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [PATCH 1/3] ARM: OMAP4+: Cleanup header files

[Lokesh Vutla]

After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap4/prcm-regs.c |3 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c |2 ++
 arch/arm/include/asm/arch-omap4/clocks.h |   28 ---
 arch/arm/include/asm/arch-omap4/cpu.h|   12 
 arch/arm/include/asm/arch-omap4/omap.h   |   14 --
 arch/arm/include/asm/arch-omap5/clocks.h |   22 -
 arch/arm/include/asm/arch-omap5/cpu.h|   12 
 arch/arm/include/asm/arch-omap5/omap.h   |   31 +-
 arch/arm/include/asm/omap_common.h   |4 +---
 board/ti/omap5_uevm/evm.c|   12 
 board/ti/panda/panda.c   |   20 +++
 board/ti/sdp4430/sdp.c   |   16 +--
 drivers/usb/musb/omap3.c |4 +++-
 13 files changed, 40 insertions(+), 140 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/prcm-regs.c 
b/arch/arm/cpu/armv7/omap4/prcm-regs.c
index 7225a30..7e71ca0 100644
--- a/arch/arm/cpu/armv7/omap4/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap4/prcm-regs.c
@@ -301,6 +301,8 @@ struct omap_sys_ctrl_regs const omap4_ctrl = {
.control_ldosram_iva_voltage_ctrl   = 0x4A002320,
.control_ldosram_mpu_voltage_ctrl   = 0x4A002324,
.control_ldosram_core_voltage_ctrl  = 0x4A002328,
+   .control_usbotghs_ctrl  = 0x4A00233C,
+   .control_padconf_core_base  = 0x4A10,
.control_pbiaslite  = 0x4A100600,
.control_lpddr2io1_0= 0x4A100638,
.control_lpddr2io1_1= 0x4A10063C,
@@ -312,4 +314,5 @@ struct omap_sys_ctrl_regs const omap4_ctrl = {
.control_lpddr2io2_3= 0x4A100654,
.control_efuse_1= 0x4A100700,
.control_efuse_2= 0x4A100704,
+   .control_padconf_wkup_base  = 0x4A31E000,
 };
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..db779f2 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -311,6 +311,7 @@ struct prcm_regs const omap5_es1_prcm = {
 
 struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
+   .control_padconf_core_base  = 0x4A002800,
.control_paconf_global  = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
.control_smart1io_padconf_0 = 0x4A002DA8,
@@ -358,6 +359,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_port_emif2_sdram_config= 0x4AE0C118,
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
+   .control_padconf_wkup_base  = 0x4AE0C800,
.control_smart1nopmio_padconf_0 = 0x4AE0CDA0,
.control_smart1nopmio_padconf_1 = 0x4AE0CDA4,
.control_padconf_mode   = 0x4AE0CDA8,
diff --git a/arch/arm/include/asm/arch-omap4/clocks.h 
b/arch/arm/include/asm/arch-omap4/clocks.h
index ed7a1c8..f544edf 100644
--- a/arch/arm/include/asm/arch-omap4/clocks.h
+++ b/arch/arm/include/asm/arch-omap4/clocks.h
@@ -34,25 +34,6 @@
  */
 #define LDELAY 100
 
-#define CM_CLKMODE_DPLL_CORE   0x4A004120
-#define CM_CLKMODE_DPLL_PER0x4A008140
-#define CM_CLKMODE_DPLL_MPU0x4A004160
-#define CM_CLKSEL_CORE 0x4A004100
-
-/* DPLL register offsets */
-#define CM_CLKMODE_DPLL0
-#define CM_IDLEST_DPLL 0x4
-#define CM_AUTOIDLE_DPLL   0x8
-#define CM_CLKSEL_DPLL 0xC
-#define CM_DIV_M2_DPLL 0x10
-#define CM_DIV_M3_DPLL 0x14
-#define CM_DIV_M4_DPLL 0x18
-#define CM_DIV_M5_DPLL 0x1C
-#define CM_DIV_M6_DPLL 0x20
-#define CM_DIV_M7_DPLL 0x24
-
-#define DPLL_CLKOUT_DIV_MASK   0x1F /* post-divider mask */
-
 /* CM_DLL_CTRL */
 #define CM_DLL_CTRL_OVERRIDE_SHIFT 0
 #define CM_DLL_CTRL_OVERRIDE_MASK  (1 << 0)
@@ -94,8 +75,6 @@
 #define CM_CLKSEL_DCC_EN_SHIFT 22
 #define CM_CLKSEL_DCC_EN_MASK  (1 << 22)
 
-#define OMAP4_DPLL_MAX_N   127
-
 /* CM_SYS_CLKSEL */
 #define CM_SYS_CLKSEL_SYS_CLKSEL_MASK  7
 
@@ -181,9 +160,7 @@
 #define MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK   (1 << 25)
 
 /* Clock frequencies */
-#define OMAP_SYS_CLK_FREQ_38_4_MHZ 3840
 #define OMAP_SYS_CLK_IND_38_4_MHZ  6
-#define OMAP_32K_CLK_FREQ  32768
 
 /* PRM_VC_VAL_BYPASS */
 #define PRM_VC_I2C_CHANNEL_FREQ_KHZ400
@@ -234,11 +211,6 @@
 
 #define ALTCLKSRC_MODE_ACTIVE  1
 
-/* Defines for DPLL setup */
-#define DPLL_LOCKED_FREQ_TOLERA